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.