Blog
The best tech stack for web development in 2023
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
- Changing your tech stack for the sake of it
- From PHP to React
- From NodeJS to Golang
- Conclusion
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 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