The Three Pillars Propping Up JavaScript's Bloat Problem

43081j — who's spent years filing PRs to remove unnecessary dependencies from popular packages — is back with a taxonomy of why your node_modules folder weighs more than your application logic. The post identifies three pillars that sustain JavaScript bloat, and at 410 points on HN, it clearly struck a nerve.

The argument isn't new in isolation, but the framing is useful: bloat persists not because of one bad habit, but because multiple reinforcing patterns make it the path of least resistance.

The first pillar is micro-packages — the left-pad legacy. Packages that wrap a single native API or implement something achievable in a few lines of code. The JS ecosystem uniquely incentivizes this: npm makes publishing frictionless, and transitive dependencies compound fast. A package with 3 dependencies that each have 3 dependencies gives you 12 packages for one feature. The cost isn't just disk space — it's supply chain attack surface, version resolution complexity, and install time in CI.

The second pillar is polyfills and compatibility shims that have outlived their usefulness. Packages originally written to paper over browser or Node.js gaps that no longer exist. The ecosystem carries enormous dead weight here because removing a polyfill requires someone to verify the baseline has caught up, update the code, and publish a breaking change. Most maintainers understandably have better things to do. 43081j has personally filed hundreds of PRs addressing exactly this — removing dependencies on packages like `has`, `is-callable`, or `object.assign` where native equivalents have been stable for years.

The third pillar is the culture of wrapping built-in APIs in "nicer" abstractions. Think packages that wrap `fs.readFile` or `path.join` with marginally different ergonomics. Each wrapper is a new dependency, a new maintainer to trust, and a new thing that can break — all to avoid reading MDN for five minutes.

The practical takeaway for teams: audit your dependency tree with tools like `depcheck` or `npm ls --all`. Look for packages that duplicate platform capabilities you already have access to. When evaluating a new dependency, check its own dependency count — a utility with 15 transitive deps is a red flag, not a feature.

The broader lesson is structural. npm's flat dependency model and the cultural norm of "there's a package for that" created a system where bloat is the default and minimalism requires active effort. That's not a problem any single blog post solves, but naming the patterns is a prerequisite to changing them. At minimum, it's ammunition for your next PR review where someone wants to add a 4-line package.