How important is it to have a consistent technological stack? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 1 year ago.

Improve this question

I'm trying to make a browser MMO game as a hobby project.

Currently, the server-side code is written in ASP.NET Core (this was not my choice; the game started as an academic project and the prof imposed C#), while browser-facing client-side code is written in (almost) vanilla JS¹.

While writing JS code I was sadly paying almost no attention to code quality and I soon found myself unable to work with my own client-side code. Adding simplest features or fixing simplest bugs was taking disproportional amounts of time and - when finally done - was making the whole code even more messy.

Now I know that in such cases the general piece of advice is to first make a working prototype and only then think about rewriting, but I allowed myself an exception for JS code, figuring out that I dug myself in such a deep hole that it would likely take less time to rewrite JS code from scratch than to try to work with it.

Still, I don't rewrite the whole JS code from scratch. Instead, whenever a need arises to make some adjustments to existing code, I try to cut a relatively large piece of code that contains the parts in need of adjustments, I rewrite this piece from scratch, append this work to the new, rewritten code, then put some bindings between the new and old code. This way, I hope, the new code will eventually take over the whole bulk of old code, so that only new code will exist. While this is a lot of work (each time I rewrite significantly more than strictly necessary to make X work), I think it is worth it because I hope that the new code, while imperfect, will at least prove to be manageable - and this is more than can be said about the old code.

OK, I'm done with the (longish) introduction, onto the actual question.

Since I am notoriously able to devote far less time to this hobby project than I'd like to, I did not manage to finish rewriting client-side code before ASP.NET Core 3.0 came out, and Blazor with it. Blazor is the new ASP.Net way to write client-side code.

Now I feel that my situation is kind of... awkward. I feel like it had been justifiable for me to use JS before Blazor came out, but once Blazor came, I should be using Blazor... I feel like my efforts to rewrite JS code in JS became obsolete even before I could finish this task!

Am I correct that it is important to use a consistent technological stack? Or is it fallacious of me?

Because, according to this thinking, I basically have 2 choices:

• Decide to continue using ASP and C# - then consistency demands to rewrite client-side code in Blazor;
• Decide to continue using JS - but then consistency demands that I no longer use ASP and C# for server-side development, instead I should rewrite server side code to Node.JS.

Both options require some very significant effort, perhaps more than they're worth it.

Well, there is a third option: Write any new client-side code in Blazor, while leaving old code intact until need arises to modify it.

But even now the bindings between old JS code and new JS code are, I feel, awkward and ugly: both bulks are significantly different architecturally, still there is much overlap with their responsibilities, so they have to call each other. The parts where new code must call or be called by old code are written in a way that is somewhat contrary with the whole design of new code, especially since both new and old code is - by design - written in such a way that hints this is a consistent module to manage the entirety of the website - but this is not true for neither old nor new code at the moment. But - I was willing to tolerate this situation for then, since - as I said - I hoped that new code would eventually capture and replace the entirety of old code.

Now to ask to port JS code to Blazor step-by-step is to ask that not two, but THREE such bulks of code should coexist, sharing their responsibilities, calling each other in counter-intuitive places, etc...

I feel between a rock and a hard place.

Or... Am I wrong that I want the technological stack to be concise? Maybe there's really nothing wrong in having server-side code in ASP .Net Core and C#, while having client-side code in vanilla JS?

¹ _{(that is: I use no framework like Angular, React, Vue, etc - not even JQuery). Reasons are: (1) I wanted to avoid being overwhelmed by the quantity of libraries, frameworks, etc to learn; (2) I thought that it would anyway be a sound idea to first learn JS and only then learn frameworks}

Answer 1

First, let me summarize what you are asking here (the core question does not seem to be so broad as the question's title pretends). You are not asking about all kinds of projects, but specifially about an unfinished hobby project, and you are specificially asking

• "should I stay with JS for the client side, and switch to Node.JS on the server", or

• "should I switch to Blazor (C#) for the client side and keep Asp.Net Core", or

• "should I stay with the technologies client JS / server Asp.Net Core, though it feels inconsistent?

As you probably have noted from the comments, your "bad feelings" about mixing vanilla JS with Asp.NET Core are not shared by others. So none of the three tech stack alternatives is really unreasonable. But since this is a hobby project of yours, the real question you need to ask yourself in this situation is,

What do I want to learn from it?

If you want to learn different kinds of tech stacks and which pros and cons they have, you should definitely try each of them out, and your existing code may contain enough opportunities for developing and comparing small prototypes especially in the two stacks you haven't tried yet.

If however, your main goal is to develop the MMO to a point where it is a useful, feature-rich piece of software, I would be very reluctant to switch the tech stack in the middle of the project whenever a new, shiny new technology comes to the market - even if the current stack does not look 100% consistent. Especially for web development, new technologies tend to appear in such a frequency that you would risk to lose control and run into a neverending loop of unfinished rewrites. Note also, new shiny technologies have a high tendency of vanishing from the market as quickly as they came. So if you want to have a reliable platform, it is often better to give a new technology two or three years to get mature before you even think about switching to it.

Even if you decide to switch to a new stack combination, the recommendation I gave as an answer to this the older question "A large part of my code has a major design flaw. Finish it off or fix it now?" (which you already linked to above) still holds: whatever you do, find a way to finish the current project (with the current tech stack) - in a working state, probably with a heavily reduced set of features.

So you could take this as an opportunity to learn how to set intermediate goals, and how to evaluate different tech stacks, and also as an opportunity for learning to keep calm and not always jumping on the latest bleeding-edge technology wagon.