See the entire conversation

The JS community is in pretty deep denial today. CPUs won't get faster soon enough to keep the current levels of JS emissions from totally suffocating the mobile web, at which point we'll be the next generation of Cobol programmers -- essential, but not the future.
The JS-as-CO2 comparison is tragically appropriate.
26 replies and sub-replies as of Oct 03 2019

We can't afford this:… 347KiB of *compressed* JS, at the median, is a *disaster*. It's the 2℃ warming of the web ecosystem. Use of the web is in free-fall on mobile, and the web is a non-entity in the lives of folks just coming online now.
State of JavaScript
(no description)
The cumulative effects of JS dependence, as with climate change, are showing up now. And the folks who are least well off are hit hardest. Your JS payload is a _regressive tax_ on content.
The current web development workflow paints us into this corner though. I’m old enough to remember when one of the *benefits* of web development was that you didn’t need to use a compiler. People had “F5 is my compiler” tshirts.
But then and now, people need to use other people’s code, and the workflows and tools we have to enable those ecosystems dictate the kinds of technology and tradeoffs we can make. Currently, bundling is the only option, and that really paints us into a corner.
I'll say it: NPM was a mistake.
That’s sort of a foolish statement. It’s exactly what was needed and did that job tremendously well. It’s like saying Buffer was a mistake, or the module system was a mistake, when it only exists because the language didn’t provide what we needed.
But none of this is an argument for sticking with these things forever. As JS/Browser standards have brought us better native features we need to phase out a lot of the old patterns we developed as a stopgap.
Oh, I'm not defending TC39 and the sh*tshow that was Modules, only saying that NPM made over-use of 3p code attractive and bundling a requirement and if the choice is between that outcome and one where costs are more direct and the web more healthy, I'd pick the latter every time
I could be wrong but I still feel like this is a problem that could be relatively trivially solved and is ripe for progress. Enabling npm (or your favorite package manager) and Node.js only use code that's actually *used* instead of bundling is absolutely possible, no?
This of course requires (heh) you to rethink certain fundamental aspects of both Node.js and npm at present, but I don't think that's such a wild approach nor necessarily a breaking change.
How would the cost be more direct in any other system?
No one believes “the web is a non-entity for people coming online” until it’s visible relative to their own product. (Same happened/ing w/ mobile for those whose profit is still mostly desktop-dependent). Wish I knew how to shift it…(the climate change analogy is quite apt)
At that size it's network bandwidth that's the issue not CPU. And there's plenty of room for growth in global network coverage/speeds
mobile web is a tragedy on mobile even on broadband. CPU and other local overhead is a bigger deal than most recognise.
Sure but at least commodity hardware is getting cheaper which raises the threshold. But yeah low end mobile CPU is tragic 😔
native people have been grappling with the death of single-thread workload performance gains and teaching themselves to write threaded code + building/adopting new frameworks for parallel meanwhile, electron and 5 layers of browser frameworks
native dev has bleeding edge stuff like rust designed to mechanically make parallel code guaranteed-safe and meanwhile we've got threads in JS now without any of the safety guarantees
wasm has threads (in some environments). JS has communicating sequential processes, which are much safer by default (with higher communication overhead).
Ship less code. Use lighter libraries that bet on the platform and avoid re-creating it in user-land (Lit, Svelte, Preact, Skate, Vue, etc.) and tools that automate code-splitting and budget setting.
IE support? Internationalization with timezones? Is there any article covering tools and approaches to lower the footprint?
Differential serving and polyfills like the webcomponents loader that feature detect before loading code. The module/nomodule pattern is an easy and server-agnostic way to distinguish ES2017+ users from legacy (mostly IE) users.
I'm really hoping that the new Edge will finally end IE. All the other stuff should be part of the platform. And indeed, the platform could and should be doing more to reduce the amount of JS that needs to be downloaded and parsed per site. Much of it is essentially identical
It's unfortunate that double-keyed cache, which is what all browsers are implementing, will increase download sizes even more. I wish there was some sort of centralized resource repository from common, vetted downloads, that are also pre-parsed. (I know foreign fetch is DOA)
does Angular fit into this? never used it
I’ll have some fun stuff to show you early next year, might be an opportunity to turn this around.