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.
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.
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.
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.
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 you are mistaking the language with the browser.
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