> But we've reached a point where modern web applications are pulling in dozens of dependencies in both production and development toolchains, and increasingly those dependencies are themselves built on top of other dependencies.
Um, take ANY non-trivial application, written in any language, and then follow the chain of its dependencies all the way down to the kernel, and shriek in horror. JS is not unique here, the only unique part is perhaps how obvious npm makes it just how much stuff your code depends on.
Sort of kind of. I deal as a consultant for large corporations where down-time is a no-no. Think secondary market-makers, institutional investors, healthcare insurers. Not quite rocket control systems or firmware for dialysis machines but five-nines is a given.
Bugs happen everywhere. That's an axiom. You can decrease the risk of it with formally verifying the system (see: SPARK for Ada), but they'll occur. The difference is the what in response to those bugs. ASP.NET on Oracle 11g might cost a few hundred thousand a year in support contracts alone, but when the bugs occur there is an insurance policy (literally-- at that level, there's an SLA and everything), professional liability insurance, and legal recourse. Those ecosystems have had 1: time to mature so those previous bugs that customers have identified and reported have been resolved, and 2: the option to pay (a lot of money, I'll admit) to have any new bugs resolved almost immediately. I was working with a large healthcare provider and some how a bug made it through 3 rounds of QA into production. Within 6 hours 3 engineers who worked on that specific component had flown across the country, landed, got in my car and was driven to our office, while another team was simultaneously Remote Desktop'ing to see if they could resolve it in the process. Microsoft still offers LTS for a 13 year old operating system.
I'm not ragging on node.js - its endemic of any new technology with a lot of fervor. In fact, it very much reminds me of the CL community in the late 1990s where everyone was writing a ton of solutions, submitting their packages which worked very well for their own purposes, but broke the second you tried to do something it wasn't meant to. It would break and you'd be on a mailing list back-and-forth'ing for two or three weeks.
A large amount of code is in use which hasn't had to stand the test of time (which flushes out a) the poorly designed solutions and b) the bugs in "good" solutions). To make matters worse, and no one knows which is going to be around in 5 years (i.e. what is "good"?) so it's all a gamble where no one quite what to put their money on (should I pick Knockout? Angular? oh wait now it's all about isomorphic code..should I use Redux or Flux?).
FWIW we use Angular where I work, without any JavaScript build tooling (only for SASS), and it's actually fine. So taking proven solutions that have been around for a couple of years in the front end world is not a bad idea, if you want to just Get Things Done.
At my last place we used React with all the latest hotness, and had ongoing issues with complexity and devs having to keep up with all the new tech.
I agree with pretty much everything you said - and thanks for sharing your perspective. Node.js is still very young and the enterprise ecosystem has a long way to go, but it's getting there (e.g. IBM's acquisition of StrongLoop, the EnterpriseJS initiative - https://enterprisejs.io) I've done a bit of work with Erlang, which is all about the 9s (though it doesn't have the enterprise ecosystem on par with Java or .NET around it) but for a lot of software, Erlang is an overkill, as would be formal verification for example. A lot of software is just fine being built with Node or other young tech trading stability for productivity and time-to-market.
Um, take ANY non-trivial application, written in any language, and then follow the chain of its dependencies all the way down to the kernel, and shriek in horror. JS is not unique here, the only unique part is perhaps how obvious npm makes it just how much stuff your code depends on.