Even for those that deal with JS everyday, most don't actually understand the intricacies of CommonJS & ESM.
See https://github.com/sindresorhus/meta/discussions/15 for just ONE example of this mess.
I don't know why it's become this ideological war where people are 'testing the waters' on production-used libraries. It's not the approach I would have taken.
ESM _is_ the future, but not the present, and I wish people would stop foisting it on packages before its ready.
I'm still tempted some days.
It's beyond painful. It's infuriating.
https://jakearchibald.com/2021/export-default-thing-vs-thing...
In my opinion they should have dropped the whole "live reference imports" which is a completely new concept to the language.
Personally I would have liked inline modules definitions à la Rust.
They drew a lot of inspiration from the Ruby ecosystem and its gems. It was even a lot of the same people contributing. Somehow, they ended up with a much worse tooling story, though. I think a lot of it stems from the browser/server divide they had to contend with and the worse common library.
So then we end up with a mix of old and new and the promise of "moving to a bright new world" that just won't happen. As another poster said, since we know that package management is a pain, we should be able to solve all of these issues when we create a new language eco-system, not rush to get the exciting part released with "hello world" and wait for the problems to roll in later.
Interestingly, nuget as a philosophy isn't terrible but there are extreme performance issues and crazy things like not tying a package to a specific feed so if you install it, it asks all of the feeds if it has a copy, most of which will 404. Updates usually take an age but once they are installed, it usually runs OK :-)
In an ideal world, sure. In the world of software dev tools, not always. We've regressed from Delphi and Visual Basic that allowed anyone with some data to pop up an application quickly to use that data, to the current state, which every popular language in industry (and even some unpopular ones like Rust or Haskell) make it well-nigh impossible to do very simple things.
We've gone from empowered computer users writing programs to solve their own problems to helpless computer users who cannot write programs to solve their own problems.
Sure, you may point to Excel and derivatives, but those existed back in the 90s too, and VB/Delphi existed as an intermediate point between problems that are simple enough to solve in a spreadsheet and problems that need less than a tech expert.
Maybe this is why salaries are sky-rocketing: we've collectively made everything so much harder to get into that fewer people are able to solve their own problems.
Sure it's not the same as it was with Delphi or VB that would install (and in case of VB also build into exe) everything you might ever need, but e.g. it's still a lot simpler than VC++ used to be back then - just figuring out all headers you need to include to compile an empty app was a horror - so it was definitely not like everything was "simple stuff" friendly back then. And doing web dev in those early days was far more complicated to setup...
Nowadays IME once you figure out how to setup the tool chain - and there's a plenty of boilerplates and starter kits for that - you more or less just rinse and repeat that every nest time. Sure sometimes package managers go berserk on you, but otherwise my experience is that - once you've figured it out - it all just magically works... but it does take some initial effort and time to figure it out properly.
And if it's really simple stuff that I need to finish quickly, I just skip the whole package managers/ build tools deal, and write a script, include and link what I need manually and run it from CLI/browser just like it's 1998 :P