Choosing the right tools is one of the most important decisions that you’ll have to make when you start a new JavaScript project. In this four-article series, I’ll give you my tips and tactics so you can choose the best libraries for your JS project.
Click here to read the other articles in this series: Part 1, Part 3, Part 4.
Are New Libraries Better Than Old, “Obsolete” Ones?
The JavaScript ecosystem moves extremely fast. And we, JS devs, always have the temptation or the pressure to always choose the most recent libraries over older ones. We are hooked to the hype. But that’s not always the best solution.
As developers, we all know that no QA process can spot all the bugs in a piece of software. There will always be bugs that reach production. But over time, these bugs are discovered and the team eventually fixes them.
New libraries, precisely because they are new, have little time running in production. And it means that many of these bugs are still there. Of course, older libraries have bugs too, but younger libraries are generally more bug-prone.
Also, with older, established libraries, it’s easy to find help if you run into problems. For example, if you build a SPA with React and you find a problem, you’ll find literally tons of free information online, and it will be way easier to find possible solutions. The same situation will be harder if you use Svelte, for example.
However, this doesn’t always mean that older libraries are always better. Mootools is way older than React, but nobody would use Mootools now. Innovation exists, and it’s essential. But choosing always the new and shiny is a mistake too.
In the next article of this series, I’ll talk about how to evaluate libraries according to their documentation. Click here to read it.