DEV Community

Cover image for Choosing the Right Tech Stack: A Developer's Decision-Making Guide

Choosing the Right Tech Stack: A Developer's Decision-Making Guide

Lucas Lima do Nascimento on October 28, 2024

Introduction Hello there, dear reader! So, you’re at that spot, you’re beginning a new project and now, you have to choose which tec...
Collapse
 
programmerraja profile image
Boopathi

This is a fantastic guide! I especially appreciate the emphasis on evaluating project requirements before jumping into specific technologies. It's so easy to get caught up in the hype of the latest tools.

Collapse
 
llxd profile image
Lucas Lima do Nascimento • Edited

Thanks a lot for the comment, @programmerraja! And I agree, it's truly easy to get caught up in the hype (and ending up creating projects that will be eternal pains).

A great resource if you'd like to learn a little bit further is the boring technology manifesto!

Give it a look and tell me what you think ;)

Collapse
 
programmerraja profile image
Boopathi

Yeah definitely will check it out thanks for sharing

Collapse
 
anmolbaranwal profile image
Anmol Baranwal

There are too many options these days :)

Collapse
 
llxd profile image
Lucas Lima do Nascimento

Hey @anmolbaranwal!

And yes, I do agree that there are many options (too many to keep track of) out there and that might or might not be a problem.

A great website to check to compare how the feeling of a bunch of stacks feel like is this one: TodoMVC. They create the same app, over and over again using different stacks, for you to check the differences quickly haha

Thanks for the comment ;)

Collapse
 
charles_roth_8c0df94d211a profile image
Charles Roth

Also consider how rock-solid the application has to be, how long it will last, how much it will change over time, and how many other people will need to work on it.

I just left a project with >1M lines of code, 20 developers, and scores of millions of users. (Retired, left with good wishes, etc.) Back-end? Java. Far fewer runtime errors than (say) Python or PHP. 75% unit-test coverage. Front-end? Tapestry... although I'd replace that with Angular if I could.

OTOH, a small, 3-part-time volunteer project for politics? A mix of python/flask, and PHP/Smarty/Twig. Different contexts, different tools.

Collapse
 
llxd profile image
Lucas Lima do Nascimento

Really awesome comment @charles_roth_8c0df94d211a (and glad to see that you retired! 🚀). Thanks!

Totally agreed in terms of considering more things (although I think it's somewhat really hard to try to predict the longevity of an application), but totally agree -- different context, different tooling!

Collapse
 
eshimischi profile image
eshimischi

Including jQuery in 2024/25 is kinda.. strange
Nothing about Bun/ElysiaJS
Nothing about Astro
SolidJS not mentioned but Qwik

Collapse
 
llxd profile image
Lucas Lima do Nascimento

Hey @eshimischi, thanks for the comment.

The major point being made is to evaluate other things besides the technology per se, so, yes, there are great pieces of tech missing in my example list, but they're just that, examples -- there are a ton of solid tools out there. The whole idea is: tech is just a tool in your belt, not a competition of which is better than the other.

In terms of

Including jQuery in 2024/25 is kinda.. strange

I honestly don't think so. Although jQuery is old, there are use-cases for it, and, besides that, it's still used largely by most of the web most visited websites (~75% to be precise). Can you mention why do you think it's strange?

JQuery usage

Collapse
 
eshimischi profile image
eshimischi

No blame. About jQuery, the more we carry any legacy lib or framework together with us, more it will never die. 90% of that 77% used cases i think is jQuery added during first a round of development, no one cared to refactor it later. Not saying it is bad, but again things are going forward with web dev

Thread Thread
 
llxd profile image
Lucas Lima do Nascimento

Hey @eshimischi, thanks for sharing your thoughts!

I get where you’re coming from. Regarding the 90% part, I doubt that’s entirely accurate, but let’s go with it for the sake of argument. The reality is that legacy systems are a huge part of development, and they aren’t always refactored simply because they’re still effective (or the refactor would take a time that business doesn't necessarily have to allocate on that, and, although we love the code, without the business, no one would use it). jQuery, for instance, may be old, but it's still functional and widespread for a reason—it has powered countless sites for years, and in many cases, it just works.

And I'm not the only one with that line of thought. The jQuery team actually is working on the v4 for a ton of time and they're probably releasing it in the near-coming future. If their perception about their tool was that it was dead (or at least dying) they wouldn't spend time on it.

Modern frameworks definitely bring powerful new features and flexibility, but it's important to remember that they’re the newcomers on the timeline. That doesn’t mean jQuery or other established tools are outdated in every context; it just shows the evolution of web dev (and we, as engineers, should always look at that with our rational lenses on -- without favoristims -- they're only tools, after all). Both "legacy" and modern tools have their place, depending on the situation and project needs.

Thanks and see you around ;)

Collapse
 
anna_grabar profile image
Anna Grabar

Pictures - art !
Great article.

Collapse
 
llxd profile image
Lucas Lima do Nascimento

Thanks a lot, @anna_grabar! Glad that you enjoyed it 🚀

Collapse
 
claritiv profile image
Claritiv

Helpful

Collapse
 
llxd profile image
Lucas Lima do Nascimento

Thanks! Glad that I could provide some helpful info ;)

Collapse
 
rcls profile image
OssiDev

Sometimes you can also just use a language, like Go, without any framework to achieve the same results on the back-end. All solutions don't have to involve frameworks.

Collapse
 
llxd profile image
Lucas Lima do Nascimento

Really important point!

Indeed, frameworks are not needed for developing great solutions, but, to be fair, for me, it seems kind of rare the case where using a framework (or a micro-framework in the cases the project is really small) will do more harm than good, but, my vision might be biased by the JS ecosystem, which is the one I'm more of a part.

How does that works on the Go ecosystem?

Thanks for the comment, @rcls!

Some comments have been hidden by the post's author - find out more