A lot of js devs came straight to js without any previous language experience. Hence we are seeing lots of ideas and frameworks thrown out there. The worst example is the proliferation of single function libraries, yes, create a js lib for a single function.
It will settle down. Mostly as the devs grow a bit older and wiser, and as the end users start to rebel a bit harder - already non-tech people are publically lamenting js-heavy sites, wondering why so slow to load and run.
I don't get the hatred for small JS libs. It's the unix philosophy brought to the web. Have each part do one thing and do it well, then combine them.
I've used "one function" libs before, and i'll continue to. The most recent example is a small lib that added Array.prototype.reduce to browsers that don't have it. It's 31 lines total (un-compressed, un-minified, un-anything)
Installing that small, well tested, and standards compliant function using a single npm command is significantly better than trying to do it correctly myself (which would most likely take an hour or so just to look over it's exact functional requirements, and it would most likely have subtle bugs), half-ass it and write my own "not quite reduce but close-ish" that i now need to use everywhere and need to train new hires on because "I didn't want to install a 31 line lib, so now you have this non-standard system that's buggy in it's own strange ways", or copy-and-paste the code from somewhere muddying the legal status of my codebase.
It's dumb, because most of those little shim libraries are things that would be part of the language's core library in a less shitty language.
Then when you have all these little libraries, you've got to go down the bundling path (and navigate the bewildering array of almost but not quite the same tools), because making 47 HTTP GETs to grab < 1KB JS files is slow. Theoretically, some of those might be cached, but the churn-rate means that virtually no one will have the exact version of a library that you require pre-cached in their browser.
There's nothing wrong with "going down the bundling path". Virtually every compiled language does this via a linker. Java's jars are another example. You have at least 3-4 different tools for doing this in Python.
In short: "bundling" is just JS catching up to how software was deployed for ages. Source maps are equivalent to leaving debugging symbols in the binary, only without performance costs.
I think part of this is the built in functions/frameworks for Javascript are so small.
Coding in Ruby, C# or whatever is about learning the standard library as much as the syntax.
So much of the churn is caused by the constant rewriting of basic functionality (e.g. date handling), if we had a bigger and standardised standard library, we wouldn't need half of the packages
It will settle down. Mostly as the devs grow a bit older and wiser, and as the end users start to rebel a bit harder - already non-tech people are publically lamenting js-heavy sites, wondering why so slow to load and run.
Lean js is happy js.