One theory I have is that JavaScript's originally low entry barrier as an untyped scripting language that works very close to the front end, allowed many programmers who might have found other programming languages too challenging (especially those without a comp sci degree), to be productive. This in itself is a good thing. It democratized programming to some extent. But at the same time, it populated the community with a large number (majority?) of programmers who were not well grounded in computer science or engineering practices. I worked with C++ for ten years before getting into JavaScript, and over the years I have seen some old concepts and solutions being excitedly reinvented in the JavaScript world, often suboptimally.

Except it seems to be the opposite. Over engineered solutions using React and god knows what else for things that can be done in a few lines of JS or CSS and don't need React...

We need to be honest about this. JavaScript created loads of jobs, helped people buy houses and raise families. That's real impact, and I respect that. But I can't help wondering: did we choose it because it was the best tool, or just the least terrible one that was easy enough to learn?

Back then, choosing JavaScript felt like choosing simplicity. You didn't need to be a computer scientist to build something with js. But maybe that simplicity was was a long-term trap. It's like we all joined a party because the entrance was free, but no one told us each drink would cost a week's salary. Why bother, we're not the ones paying the bill right?

JavaScript employment always felt like a spoons versus shovels type story.

https://www.aei.org/carpe-diem/milton-friedman-shovels-vs-sp...

If you cannot do the job without things like React, Angular, or jquery you may not be qualified to write that code. On a bigger level if you cannot create an original application from scratch you aren’t a senior developer and if you don’t measure things you aren’t an engineer.

Nearly every other professional line of work has solved for this with some combination of licensing and/or broker/agent model. Developers tend to be scared shitless of industrial baselines of qualification assessments.

Again, I am saying all this as someone who wrote JavaScript for employment for 15 years and still love writing in the language.

Would it be a good thing if a million unemployed devs were employed to just dig a big hole? Or, worse, cut down forests with axes?

Job creation for the sake of it isn't a good thing. What matters is whether it creates actual value, and does so efficiently.

The thrust of this, and many similar articles, is that it JS frameworks were largely a very inefficient, ineffective solution to a nonexistent problem.

The fact that they're ALL now SSR-first - without the robust and comprehensive functionality of longstanding ssr frameworks, cms etc - proves this.

Agree, been working with Js (frontend only) for a few years now and never had real issues. I wouldn't chose it for my backends though...

What's wrong with TypeScript for backends? Specifically backends where the load is moderate or happening in the database anyway?

I learned Javascript was made for making the web interactive. I choose to use it this way. There's nothing wrong with using it for backends too, I just prefer using other langs for that domain as it just doesn't feel right to build my backend in Js/Ts.

For small and moderate projects I dont see issues, but I always build with scaling in mind and I'd like to keep the bill for that small.

TypeScript is a wildly unpleasant language. If I'm going to be waiting around for a compiler anyway, why not use an easier nominally typed language? I mean, dotnet is right there... and it's got features out of the wazoo. No need to download external libraries when your bloated backend framework ties your shoes for you.

Or if I'm really into structural typing, Go is right there. I'll tell you, it compiles a lot faster. And a lot less type Olympics, too. Easier to read. Less bug-prone. TS isn't a bad language. But it's certainly not the best.

Indeed, might as well use Go if you're going to use TypeScript.

Or ruby on rails, laravel, elixir or even WordPress, if you want things that are batteries included (which js frameworks or go still most definitely are not)

Why not learn from past failures? Then everybody gets a great user experience, not only those of us who know how to set up a pi-hole. Everybody wins! Apart from the framework-industrial complex, that is.

Well, paraphrasing Hegel, we can learn from past failures that the industry as a whole does not learn from past failures. It's just the Eternal September situation, and all we can do is tend our own gardens.