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...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
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
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!
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?
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
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 ;)
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!