Introduction
Hello there, dear reader!
So, you’re at that spot, you’re beginning a new project and now, you have to choose which technology to go for. Do you go for the old and more reliable ones? Or you try out the new hot product on the market to see if it holds up to expectation?
Well, it’s part of the engineering process to discover how to handle these situations, and, different engineers are going to have different takes on this — you’re probably even familiar with a bunch of opinions from different creators on which tech choices to use.
The truth is that you have to discover what works best for you (and more specifically for the project), and, for me, there’s a 3-step process for you to choose things in a more assertive way:
- Evaluate the project requirements
- Evaluate the learning curve & tech characteristics
- Evaluate costs
In this article, we’re going to go through examples of all scenarios, and, in the end, you’ll probably be able to choose by yourself and discover your own process in the middle of all that.
Evaluating the project requirements
While in my degree studies, I had a great professor who once said:
The problem chooses the tooling, not you.
Are you creating a simple portfolio for yourself? A dog-pig identifier algorithm? A huge SaaS that will have to handle a ton of requests at the same time?
All those cases impact heavily on the tooling you’ll choose. You can build a simple portfolio out of anything you want, even check out a bunch of cool stuff and random libraries, just for fun. That might not be necessarily compatible with the huge SaaS scenario though — so, here’s the first step catch.
Before thinking too hard about what are the awesome stuff being released (being that new frameworks or just new releases of old frameworks), try to think in terms of exclusion by requirement: Is there any particular project requirement that might exclude a technology choice? If so, why? And please, try not to fall for imaginary problems made by fans of certain technologies — You’ll probably hear it all: X doesn’t scale, Y is better than Z, A is ugly (and to be fair, we all have our favorites). Your job here is to step aside, get your rational goggles on, and think rationally about your decision.
Here are a few examples of solid tech choices that might suit some case for you:
Front-end
I love front-end and one of the things that excites me the most is the amount of things being released into it. You might think that’s a burden and a problem, but, my take here is that whenever people create a new solution to a different problem, they push the bar further — making everyone along the way have to run to catch up. Here are a few front-end technologies worth exploring:
- SvelteKit: Offers a compiler-based approach for building fast, efficient web apps
- Qwik: Focuses on near-instant load times through resumability
- React (and other meta-frameworks like Next.js): Known for its component-based architecture and virtual DOM
- Angular: Offers a complete solution with two-way data binding
- Vue (and other meta-frameworks like Nuxt): Praised for its simplicity and gentle learning curve
- htmx: Allows for dynamic content without heavy JavaScript frameworks
- jQuery: Still relevant for quick DOM manipulations and AJAX calls (and for checking out some legacy systems)
Back-end/Full-stack
On the back-end, there is a ton of great stuff being made, every iteration being more performant and even more focused on developer experience. Let’s check out a few projects worth checking out:
- Ruby on Rails: Emphasizes convention over configuration
- Laravel: PHP for Artisans
- Spring Boot (Java): Provides a robust ecosystem for enterprise applications
- Node.js: Allows JavaScript on the server-side
- Deno (v2): A secure runtime for JavaScript and TypeScript
- Encore: An open-source backend development platform that simplifies the entire backend development process, from API design to deployment.
- Hono: A small, simple, and ultrafast web framework for Deno, Bun, and Node.js
The important thing here is that: these projects exist for you to try out new things and fall in love. New solutions to old problems appear all the time, so, what you’re trying to catch is what they offer you — if you’re convinced some tech gives you enormous value, which generally comes in the format of performance and DX, you might consider learning it a little more deeper to solve the problem at hand.
Evaluate the learning curve & tech characteristics
The learning curve is a really important point to measure as well. How well do you or others on your team know certain technology? Are they familiar or have they just heard of it?
Short-term productivity
You have to take that into account because it will directly impact your productivity, and, by a consequence, your deadlines. If you have a really tight deadline, it might not be the perfect time to test an entirely new tool you’re not sure will solve your problem, so, ask yourself: Is the learning curve of this tool a big impact on our dates? Do we already have knowledge in close spectrums?
Questions like these might make you exclude a few other technologies based on time itself — you might have to pick up new stuff later, on a smaller project, and that’s okay. Remember that learning usually has a slow start and mastery takes time to get, but, it might pay off in scale and easiness of maintenance.
Community Support
Another important consideration when evaluating the learning curve is the availability of resources and community support for the technology you're considering. Established technologies often have extensive documentation, tutorials, and a large community of developers to turn to for help. Newer technologies, while potentially offering exciting features, may have more limited resources, which can impact the learning process and troubleshooting — it might be amazing at first until you have to code a full calendar by yourself.
Thinking long-term
Lastly, consider also the long-term implications of your technology choice. My take on this is that you have to really be aware of stuff that has not released a stable version — things can change a lot and the last thing you want is having to write an entire project again just because all APIs changed.
Considering the costs
Another important aspect of the decision-making process is considering the costs. There is a lot of tooling out there that, although they might seem awesome, the infrastructure to host them easily might make you lose your mind.
Try not to think here only in terms of monetary value too. If with one technology choice you might spend hours/days working on setting up the infra and with other is just commands, well, your (or your engineer’s) time is valuable and, every second you spend working on things that is not the product, is time flying by.
For me, this is an awesome aspect of Encore, the sponsor of this article:
One of its standout features for me is the simplified infrastructure setup. Want to deploy things super quickly using their platform and paying something for it? The option is there. Want to self-host your docker images on your cheap 5$ VPS? There are docs on that too.
Easiness of deployment and separation of costs/concerns with clients are really important features (Encore sets up AWS/GCP infrastructure in your own — or your client's — account, for example), and, unfortunately, not every tech choice out there works on that, so, stay aware.
A good rule of thumb on this is before coding and starting the project with a tech choice, give a quick overview of the deployment section (if it looks hard as hell, that might be a red flag).
So yes, spare a thought on deployment and infrastructure costs and they might spare you a few pennies/dollars every month or so ;)
Conclusion
Hey! You got to the end!
Well, I hope that you now find choosing the right tech stack a more exciting journey, and not an impossible task! Remember — it's all about finding what works best for you and your project. By evaluating your project requirements, considering the learning curve, and weighing the costs, you're well on your way to making an informed decision (which is the whole point here).
Don't be afraid to explore new technologies, there’s a BUNCH of cool stuff being released every day for you to check out, but also don't underestimate the power of established tools listening to those same tech gurus that are not shipping software. If it delivers a good solution, matches you or your team's skills, and doesn’t cost you more than you can pay, you’re probably on the right path.
So, roll up your sleeves, dive into the documentation, and start experimenting! Who knows?
You might just find your new favorite tool or framework along the way.
Top comments (26)
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.
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 ;)
Yeah definitely will check it out thanks for sharing
You're totally welcome! ;)
Including jQuery in 2024/25 is kinda.. strange
Nothing about Bun/ElysiaJS
Nothing about Astro
SolidJS not mentioned but Qwik
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
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?
Spot-on you are.
The same goes for the "so-hated-PHP" more than half the globe's apps are still using it at some level, not to mention the "slow-moving" enterprises out there. And for financial institutions, like banking some blatantly refuse to drop their COBOL-based "bean counters" labouring away on the basement mainframes, LOL.
All the tools, like you said, were created for some or other reason. It might be compared with the extremely diverse ecosystem we so ignorantly "step on" every day. The myriad of organisms involved in maintaining (or attempting to) balance is staggering. Software is still in its nappies compared to its diversity. Yeah, we can set a screw into a chunk of lumber with a hammer, for sure, and quickly too!
Is it the best way to go about it? Well...
At the end of the day, tungsten is tungsten, and yeah, fancy, nano-tech graphene looks oh so enticing, but it won't outwork a tungsten carbide tip and costs orders of magnitude more to get the same job done.
I fail to understand why good, solid tech, no matter how "ancient" or "juvenile" it may be is always played off against each other... Oh, wait.... It's a new, novel way of making "new", "novel" money!!! LOL
Thanks for taking the time to write and share, Lucas . It is a valuable lesson to both teach and learn.
Fully agreed and well written comment @andre_adpc!
Envisioning everything as a complex ecosystem of tools and technologies is the key to watch it from a rational perspective, and, by doing so, we grow together with it -- which for me, is the most amazing part of it all.
Thanks for the comment and the compliments ;)
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 round of development, no one cared to refactor it later. Not saying it is bad, but again things are going forward with web dev
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 ;)
To speak about jQuery dev.to/logrocket/why-jquery-4-is-a...
There are too many options these days :)
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 ;)
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.
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!
Infinite options: I used Hono for the first time in a project. Its pretty cool and lightweight.
Hey @andrewbaisden! So glad to hear that you're trying out new things and checking them for yourself! I still have to try Hono, BTW, it looks really cool :)
Thanks for the comment and see you around ;)
Missing Django - The web framework for perfectionists with deadlines to the list. Along with AI/ML/Data Analysis, Python is ideal also for web development.
Hey @lucabotti! Just to recap, the post idea is to just talk about the decision-making process rather than tools/tech by themselves, but you're right! Never quite used Django myself (I've been working with Ruby on Rails and React for the last 3 years basically) but I've heard a lot of it and it sure is reliable!
Thanks for the comment and I might update the article to reflect this process > tool more (or simply add Django to the list too).
Thanks and see ya ;)
Pictures - art !
Great article.
Thanks a lot, @anna_grabar! Glad that you enjoyed it 🚀
Helpful
Thanks! Glad that I could provide some helpful info ;)
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.
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!
Tech Gurus that are not shipping software
This is the most reliable advice for me
Thank you
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more