> the ecosystem around Javascript is so densely layered and frequently changing that maintenance of any project over any significant period of time is going to be a nightmare
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.
Oh, but you want to leverage the latest and greatest that the ecosystem has to offer... well, that's your problem, not the ecosystem's and this is true no matter which ecosystem you're referring to. JS developers are just spoiled rotten because JS is so easy to refactor relative to every other part of the system. When the NoSQL hype train came barreling through the developer community a few years back, most of us didn't rush out to rebuild our applications on a NoSQL back-end because the database is too critical to mess around with.
If you want the latest and greatest you have to pay for it, but don't imply that there is something wrong with the ecosystem for giving you more options. Choosing the best tool is part of the job, and if you get hypnotized by every shiny new toy that debuts on the front page of HN, that's a professional flaw that only you can fix.
>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.
> 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.
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.
Oh, but you want to leverage the latest and greatest that the ecosystem has to offer... well, that's your problem, not the ecosystem's and this is true no matter which ecosystem you're referring to. JS developers are just spoiled rotten because JS is so easy to refactor relative to every other part of the system. When the NoSQL hype train came barreling through the developer community a few years back, most of us didn't rush out to rebuild our applications on a NoSQL back-end because the database is too critical to mess around with.
If you want the latest and greatest you have to pay for it, but don't imply that there is something wrong with the ecosystem for giving you more options. Choosing the best tool is part of the job, and if you get hypnotized by every shiny new toy that debuts on the front page of HN, that's a professional flaw that only you can fix.