4 ms·
>I hear this sentiment often, but don't really see any truth in it. Nobody is forcing you to update your code to be in line with the latest JS trends. If it ain
by ozziegt 11y ago
>I hear this sentiment often, but don't really see any truth in it. Nobody is forcing you to update your code to be in line with the latest JS trends. If it ain't broken, don't fix it, and if it is broken, it was always broken and that fact has nothing to do with how rapidly the JS ecosystem is evolving.
This is a really shortsighted viewpoint. Cue 1 year later where all your libraries have fallen behind and you want to integrate a new library which has dependancies on newer version of your outdated libraries.
- vectorpush 11y ago> Cue 1 year later where all your libraries have fallen behind and you want to integrate a new library which has dependancies on newer version of your outdated libraries. As I already stated, that's your problem, not the ecosystem's. If everything has been working fine for a year, but now you want to introduce a new library into the code, it's up to you to rationalize the necessity of that addition with the technical burden of updating your dependencies. Nobody is forcing you to use this new library and the only reason you can even consider this library as a potential addition to your application is precisely because the fast moving ecosystem has managed to provide you with a must-have library that you didn't need a year prior. That is simply the fundamental nature of dependencies and will be true no matter which ecosystem you're working with, hence the ubiquity of package managers like npm, rubygems, composer etc. Either way, just because something exists, doesn't mean you have to use it.