And yet, we didn't have these issues for the first 20 years that JS was around. It was only when all these things started being created around JS (babel, webpack, node, npm, typescript, etc.) that all the complexity and insanity was introduced. In what I still consider to be the good old days, any JS code would just be in an external JS file and you would just link to it. No transpiling needed. No build process needed. No module repository needed.
I used to work for a company that developed a JS widget people could stick on their site with ease (and not just little sites either, this was on microsoft.com, nfl.com, starbucks.com...)
As such I got to deal with getting our code to play nicely with the dozens of other scripts that inevitably existed on these sites as well. Being a third-party on a site with not just first-party code but also other random third-party code was truly a hostile environment.
Nobody was doing anything correctly like loading scripts in a way so that they'd never interfere. Some script would load the version of jQuery it wanted, which would shadow the version some other script wanted to use, and stuff would break (but only sometimes, because it depends on timing).
This was before anyone was using webpack. Bundlers thankfully solved this issue (unless you really go out of your way). I'm sorry to say what you consider the good old days were in fact quite bad. If you're making a personal website for yourself? Sure, all this seems like overkill. As soon as you introduce anything third-party? You need lots of tricks to be bulletproof. So from my perspective, things are much improved.
Its almost like Javascript begat a developer eco-system which then required further tooling and ancillary applications in order to keep it all in order.
What a pity this was done within the browser-as-OS context rather than OS-as-OS, as a thing... What you described is just like the good ol' days of DOS were: you could write some code, sometimes, that would work on everyones machine - but then of course there were special cases and developers had to take into consideration other members of the ecosystem - standards had to be proposed, formulated, and met - competing players needed to play nice together, and so on.
The trouble with Javascript today is that precisely NONE of the lessons learned in any of the other places where PRECISELY these issues were experienced, have been applied - even less, paid any attention. And, especially not, by any of the so-called 'new school' of developers who think such disasters as the left-pad fiasco are Just Fine™.
The cognitive load of Javascript today is equivalent to that of, lets say .. assembly on DOS in the 80's. "Anyone" can do it, and no doubt there will be great advances in applications for the user - but don't come screaming when the big ball of mess starts costing you more than if you'd just written it properly in the first place. That means, packaging and abstracting things properly. It means putting the modules in a place where the world will find them over time. It means having release planning procedures that work, and aren't in the hands of a mindless entity. This was how it was on DOS, and then Windows, and now the Web .. less so on Linux, because Linux has always had great solutions to the kinds of problems Javascript is now manifesting.
I blame the OS vendors, personally: Apple, Microsoft, et al. If they hadn't had such a hard-on for removing basic compilation capabilities from a default OS install, we wouldn't have all been corralled into the web, and thus relieved to 'finally' have a dev tool for the common man available to us, in Javascript.
The cognitive load is the same. The ecosystem is a disaster, however. I'd rather just be writing plain ol' Linux apps, producing binary-file based installers, personally .. the tipping point for the effort to invest in Web development is there. I just need users willing to run real operating systems, and who realise that the web isn't just about the browser. I feel that is a more worthy investment of the intellectual capital of developers, today.
Of course, none of this matters to the billion-dollar Javascript churn industry. The customers don't need to know how bad it is: as long as they feel they're getting the user base they need/deserve for having paid so much/little for a bit of Javascript hackery ...
