The Wig punched himself through a couple of African backwaters and felt like a shark cruising a swimming pool thick with caviar. Not that any one of those tasty tiny eggs amounted to much, but you could just open wide and scoop, and it was easy and filling and it added up. The Wig worked the Africans for a week, incidentally bringing about the collapse of at least three governments and causing untold human suffering. At the end of his week, fat with the cream of several million laughably tiny bank accounts, he retired. As he was going out, the locusts were coming in; other people had gotten the African idea.

• Count Zero - William Gibson

They just need the data. It’s available, all they need to do is open wide and scoop.

On your point about junior devs working on backend. I think part of that is that asynchronous programming is just hard. You have to have a brain for it. Some stuff you can get away with (front-end, for example, if you miss an event after an animation it’s not the end of the world), but for serious back-end systems you have to know how to handle async no matter what language you’re in.

I’m not sure what you mean by unstable ecosystem. I can presume you mean it’s easy to gain tech debt since there’s such velocity in the node/JS/TS ecosystem (and I agree not all of it is good).

I haven’t found it to be an issue. My job is a contract system engineer guiding companies in fixing tech debt, so I am very attuned to it.

Specifically I’d say the tooling in the last year or two has gotten much better at stabilizing an environment for node/deno development in particular. Tools like fnm, projen, and esbuild mixed with installing tools per-project (using npx to run them) instead of globally for development allows flow project to project on the same machine without having conflicts of tooling versions. Combine that with Docker for deployment and something built today should last 4-5 years with little maintenance and not having to make any changes except for security patches.

Not that there’s not hiccups. The whole CJS/ESM nightmare is still going (but near an end I feel).

I also feel like 4-5 years without maintenance is not something you really want. In the rare case you do, then I’d say JS is likely not for you. I’m not sure what language is. C or C++ most likely. Those have been around forever, and will never go away. Modern C++ has a lot of great features to handle memory management automatically, functional programming capabilities, compile-time metaprogramming, and OS abstraction, so that’s what I’d recommend for something that needs to last forever with minimal changes. (Thinking like a COBOL replacement.) After all, that’s what node and the JavaScript engines are written in.

My biggest issue with Java in particular is the predatory enterprise ecosystem. I spend a lot of time helping companies get away from that for cost reduction and lock-in issues.

One more point for node: it’s hands-down the most optimized interpreted engine in the world. This can be determined simply by the size of the companies that work on it and that absolutely depend on it being it’s best for their bottom line. Google, Apple, Facebook, and Microsoft among them. Billions spent on that optimization. Just sayin.

I’ll throw my 2¢ in on TypeScript → JavaScript. The typings accelerate development significantly (if the developer doesn’t fight them and make everything any), and you can write to modem JS when you have older runtimes.

But more you can do full stack from cloud infra (Infrastructure-As-Code with something like AWS-CDK or CDKtf) to deploy and orchestrate front-end to back-end.