Marco Heine_

Blog

The best tech stack for web development in 2023

Edit this Post Opens in new tab

Developers love to argue about tech. They love to defend their tech stack to the blood. They tell each other that language XYZ is superior and only inexperienced developers would choose insert random tech stack here to achieve a specific wanted outcome.

Often times these discussions lead to nothing because both sides are not interested in the opinions of others and only want to present their arguments and convince others why they should throw everything overboard and follow their advice.

It’s solemnly an ego thing because developers get attached so much to their tech stack. It feels so stupid, like arguing about which nation is better, with the slight difference that you can’t choose your nationality.

Table of Contents

Your tech stack doesn’t matter

I want to be honest with you from the beginning. This blog post is inspired by this video: How to OVER Engineer a Website // What is a Tech Stack? by Fireship  Opens in new tab.

If you came here for advice on what tech to use for web development in 2023, I’m sorry you won’t get that. I tricked you.

I won’t tell you to use Next.js with a serverless database for your CRUD App. I won’t make the decision for you to pick a specific JavaScript Framework. I won’t tell you to use Redux, Recoil, Mobx, or Xstate for state management in React. I won’t tell you if you need to use TypeScript or JSDoc for type safety or if you can skip it totally.

I want to make one particular point in this blog post. The tech you use doesn’t matter. What matters is that you satisfy the needs of your users. Your users don’t care what tech you use, but they do care if your website or application works as intended and if they can achieve the task or find the information they came for.

In addition, it matters that you choose and work with technology you’re comfortable with. Being comfortable means, at least for me, that you know your way around, you’re experienced with it, you are fast, you can find solutions quickly, fix bugs, and you know your stuff.

You don’t need to jump the hype train every year or month. Instead, stick with what you love to use. By following this guideline, you’ll be able to do what your job is.

Changing your tech stack for the sake of it

I’ve had a few experiences in my web developer career where we, as a team, or often our team leaders, decided to approach a significant tech stack change. If you’re working in a larger team, technology choices are more complex and different than working alone.

People have different experiences, skills, and preferences, and you need to collect all of that and choose the best matching tech stack based on that. Not an easy task.

Sometimes this is inevitable. Sometimes you have no choice. For example, when part of your technology is no longer safe, support for it ends, or better alternatives exist.

I’ve had a few situations in my career where we approached significant tech stack changes. I want to highlight two of them here. These were kind of “Changing your tech stack for the sake of it” situations.

What do I mean by that? Some new tech comes around, and everyone starts jumping on it and tells you you need to switch to that immediately because it’s cool, shiny, and new.

There wasn’t enough evidence yet that this technology proved to be better 100%, and of course, there wasn’t enough experience among the developers.

From PHP to React

A few years ago, I worked in a team responsible for one particular part of a big website. This part contained a lot of “legacy” code. It was written a few years back with mainly PHP. When a new, big part was added to the website, which a different team was responsible for, the decision was made to build that with React.

This decision was great, React was established and widely adopted, and the developers were experienced with it. Based on that decision, another decision was made to rebuild our part of the website with React. Management wanted a re-brush, a different look for it, so it was clear that we would have to work on it anyway.

But besides that, there were no complaints or arguments for refactoring. The performance was great. The only downsides were a bit outdated look and a lot of legacy, poorly structured PHP code. We were more than happy about the decision to rebuild it with React. We were all experienced React developers and wanted to get rid of PHP at that point. We wanted to use what everyone was using at that time. So it felt great to do the refactoring. Remove the old, in with the new!

Why I’m talking about this? In the beginning, I said it doesn’t matter what tech you use, right? So this change shouldn’t be a big deal. However, shortly after, and also a few years later, I reflected on that tech stack change, and I’m still not convinced that it was a great idea.

Performance was worse after the rebuild due to our mistakes when working with React. It took a long time to do something like that just for a different look. We could have worked on fixing bugs or building user features instead.

I’m not sure there is a right or wrong here. I want to highlight that it doesn’t matter what technology you use if you focus on building for your users. Changing your tech stack should be a decision you’ve thought about for a long time and have a long list of reasonable arguments for it. Our users don’t notice if we’re using PHP or React. But they do see when the page takes longer to load.

From NodeJS to Golang

On another former job, the decision was made to switch from NodeJS to Go on the backend. The tech stack for most projects before at that company for the backend was NodeJs, and we had a lot of experienced developers in it.

Nobody knew Go, and we needed to kick-start a new and critical project immediately. The arguments for the switch were that Go was getting traction, and there was some first evidence that it was faster and better-suitable for projects that needed to scale.

So the decision was made for us. Everybody on the team needed to learn Go from scratch. We had one or two persons who had some experience with it but not in a production environment.

This was tough because we had a deadline and needed to figure out first every basic stuff of a new backend language. This was the definition of learning by doing.

In the end, it worked out, we had a lot of fun working with Go, and we learned a lot and enjoyed it. But I wouldn’t say that this was a good decision. Everything we needed to accomplish in the new project, we could have also done with NodeJS, and it wasn’t much more than a CRUD App, so no scaling was needed right away.

The decision to switch from NodeJS to Go was made company-wide, so it wasn’t solely a tech stack change to play with the new toys. But I also wouldn’t say that it was necessary. We needed more time to build stuff because we had to learn everything first.

We had to do a lot of refactorings all the time because best practices changed, and we didn’t always do things right. In conclusion, it felt like a tech stack change for the sake of it. Go seemed to be faster and better for scalable projects, but we didn’t need that, and NodeJS is still a very capable backend language suited for almost every bigger backend. But, once again, our users didn't notice anything about that. They just want to get their data.

Conclusion

The tech you choose doesn’t matter. There is not best tech stack for web development in 2023. Your users don’t care about it. Choose the tech you’re comfortable with, experienced in and have a lot of fun using it.

Choose the tech with whom you can build features and fix bugs fast, satisfy your users needs and keep things running. Don’t switch to tech because it’s the new shiny thing and most importantly: don’t trust the hype.

I hope you enjoyed this post and learned something new. If you have any questions, feel free to reach out to me on Twitter Opens in new tab or via Email Opens in new tab.

If you want to support me, you can buy me a coffee. I would be very happy about it!

☕️ Buy me a coffee ☕️

I wish you a wonderful day! Marco