The Three Pillars of JavaScript Bloat

turtleyacht

It would be interesting to extend this project where opt-in folks submit a "telemetry of diffs," to track how certain dependencies needed to be extended, adapted, or patched; those special cases would be incorporated as future features and new regression tests. Someday, packages may just be "utility-shaped holes" in which are filled in and published on the fly. Package adoption could come from 80/20 agents [1] exploring these edges (security notwithstanding). However, as long as new packages inherit dependencies according to a human author's whims, that "voting" cycle has not yet been replaced. [1] https://news.ycombinator.com/item?id=47472694

skydhash

Fantastic write up! And we're seeing rust happily going down the same path, especially with the micro packages.

sheept

I wonder this means there could be a faster npm install tool that pulls from a registry of small utility packages that can be replaced with modern JS features, to skip installing them.

burntoutgray

I have a single pillar, admittedly for in-house PWAs: Upgrade to the current version of Chrome then if your problem persists, we'll look into it.

zdc1

A lot of this basically reads to me like hidden tech debt: people aren't updating their compilation targets to ESx, people aren't updating their packages, package authors aren't updating their implementations, etc. Ancient browser support is a thing, but ES5 has been supported everywhere for like 13 years now (as per https://caniuse.com/es5 ).

sipsi

i suggess jpeg.news dot com

SachitRafa

The cross-realm argument for packages like is-string is the one I find hardest to dismiss, but even there the math doesn't add up. The number of projects actually passing values across realms is tiny, and those projects should be the ones pulling in cross-realm-safe utilities, not every downstream consumer of every package that ever considered it. The deeper problem with Pillar 2 is that atomic packages made sense as a philosophical argument but broke down the moment npm made it trivially easy to publish. The incentive was "publish everything, let consumers pick what they need" but the reality is consumers never audit their trees,they just install and forget. So the cost that was supposed to be opt-in became opt-out by default. The ponyfill problem feels most tractable to me. A simple automated check "does every LTS version of Node support this natively?" could catch most of these. The e18e CLI is a good start but it still requires someone to run it intentionally. I wonder if something like a Renovate-style bot that opens PRs to remove outdated ponyfills would move the needle faster than waiting for maintainers to notice.

andai

Great article, but I think these are all marginal. The main cause of bloat is not polyfills or atomic packages. The cause of bloat is bloat! I love this quote by Antoine de Saint-Exupéry (author of the Little Prince): "Perfection is achieved, not when there is nothing left to add, but nothing to take away." Most software is not written like that. It's not asking "how can we make this more elegant?" It's asking "what's the easiest way to add more stuff?" The answer is `npm i more-stuff`.

auxiliarymoose

I really think writing dependency-free JavaScript is the way to go nowadays. The standard library in JS/CSS is great. So are static analysis (TypeScript can check JSDoc), imports (ES modules), UI (web components), etc. People keep telling me the approach I am taking won't scale or will be hard to maintain, yet my experience has been that things stay simple and easy to change in a way I haven't experienced in dependency-heavy projects.

est

More like a nodejs bloat rather than JS bloat. For personal objects I always prompt the AI to write JS directly, never introduce nodejs stack unless absolutely have to. Turns out you don't always need Nodejs/Reactto make a functional SPA.

il-b

The elephants in the room are react and webpack.

rtpg

I think on the first point, we have to start calling out authors of packages which (IMO) have built out these deptrees to their own subpackages basically entirely for the purpose of getting high download counts on their github account Like seriously... at 50 million downloads maybe you should vendor some shit in. Packages like this which have _7 lines of code_ should not exist! The metadata of the lockfile is bigger than the minified version of this code! At one point in the past like 5% of create-react-app's dep list was all from one author who had built out their own little depgraph in a library they controlled. That person also included download counts on their Github page. They have since "fixed" the main entrypoint to the rats nest though, thankfully. https://www.npmjs.com/package/has-symbols https://www.npmjs.com/package/is-string https://github.com/ljharb

stephenr

The primary cause of JS bloat is assuming you need JS or that customers want whatever you're using it to provide. For $client we've taken a very minimal approach to JavaScript, particularly on customer facing pages. An upcoming feature finally replaces the last jquery (+ plugin) dependent component on the sales page, with a custom implementation. That change shaved off ~100K (jquery plus a plugin removed) and for most projects now that probably seems like nothing. The sales page after the change is now just 160K of JS. The combination of not relying on JS for everything and preferring use-case-specific implementations where we do, means we aren't loading 5 libraries and using 1% of each. I'm aware that telling most js community "developers" to "write your own code" is tantamount to telling fish to "just breathe air".

skrtskrt

the fact that you can just redefine Map in a script is mind boggling

krmbzds

JavaScript bloat is downstream of low FED interest rates.

IAmLiterallyAB

For the old version support. Why not do some compile time #ifdef SUPPORT_ES3? That way library writers can support it and if the user doesn't need it they can disable it at compile time and all the legacy code will be removed