A single npm install. That’s all it takes to drag several megabytes of code into a project — most of it unnecessary, some of it absurd. The JavaScript dependency chain has become a kind of quiet crisis in software development, one that most engineers recognize but few have systematically diagnosed. A recent technical analysis by developer James Garbutt, published on his blog, attempts exactly that diagnosis, identifying what he calls the “three pillars of JavaScript bloat” — and his argument is sharper than most industry commentary on the subject.
Garbutt’s thesis is straightforward: the JavaScript world has a weight problem, and it stems from three recurring patterns — unnecessary polyfills, gratuitous dependencies, and duplicated or overlapping packages. These aren’t edge cases. They’re structural. They’re baked into the culture and tooling of modern JavaScript development in ways that make them self-reinforcing.
Start with polyfills. A polyfill, for those outside the front-end world, is a piece of code that replicates functionality not natively available in older browsers or runtime environments. There was a time when polyfills were genuinely necessary. Internet Explorer’s long, stubborn reign meant developers couldn’t rely on modern APIs being present. But that era is over. IE is dead. Every major browser engine now supports the vast majority of ECMAScript features from ES2015 through ES2023. And yet polyfills persist — not because developers are choosing them deliberately, but because they’re buried inside dependency trees, installed automatically, silently inflating bundle sizes.
Garbutt points to examples where packages still ship polyfills for features like Object.assign, Promise, and Symbol — all of which have been natively supported across environments for years. The cost isn’t trivial. These polyfills add kilobytes of dead code per package, and in a dependency tree with hundreds of packages, the cumulative effect is significant. Some projects carry polyfill code measured in hundreds of kilobytes, all of it completely inert on any modern runtime.
The problem is compounded by the way npm packages are structured. A library author might have added a polyfill dependency in 2017 for legitimate reasons. That library gets pulled into another library, which gets pulled into a framework plugin, which gets pulled into your application. Nobody along the chain re-evaluates whether the polyfill is still needed. Nobody removes it. The dependency just sits there, version after version, release after release, like sedimentary rock.
This is the invisible tax. You pay it in bundle size, in build time, in CI minutes, in cold start latency for serverless functions. You pay it and you don’t even know you’re paying it.
The second pillar Garbutt identifies is what he calls gratuitous dependencies — packages that exist to provide functionality so minimal that inlining the code would be trivial. The canonical example here is the infamous is-odd package, which checks whether a number is odd. One line of code. Published as a standalone npm package. Downloaded millions of times. But is-odd is a punchline; the real problem is the hundreds of less absurd but still unnecessary micro-packages that litter the npm registry.
Garbutt highlights packages that wrap a single native method, add a thin abstraction over something that’s already a one-liner, or exist primarily because their author published them as a convenience and other authors started depending on them reflexively. The dependency graph becomes a web of tiny packages, each adding overhead: metadata, README files, license files, package.json, and the actual code — sometimes just a few bytes of logic wrapped in kilobytes of packaging.
There’s a cultural dimension here too. The JavaScript community, more than most programming communities, has historically favored small, composable modules. That philosophy, popularized in the Node.js era, produced genuinely useful patterns. But it also produced an incentive structure where publishing packages — even trivially small ones — became a form of social currency. The npm download counter became a vanity metric. And once a micro-package gains traction, removing it from the dependency graph becomes nearly impossible because other packages depend on it.
The third pillar is duplication — multiple packages in a single dependency tree that do essentially the same thing. Garbutt describes scenarios where a project ends up with two or three different implementations of the same utility, each pulled in by a different transitive dependency. Two different deep-clone libraries. Three different URL parsers. Four different implementations of a debounce function. Each dependency author chose their preferred utility package, and the consuming application inherits all of them.
This isn’t a hypothetical. Run npm ls on any moderately complex JavaScript project and you’ll find redundancy everywhere. The Node.js runtime and modern browsers now provide native implementations for many of these utilities — structuredClone for deep cloning, the URL constructor for parsing, AbortController for cancellation. But adoption of native alternatives is slow, partly because library authors are cautious about dropping support for older environments and partly because inertia is powerful.
The aggregate effect of these three pillars is staggering. Garbutt’s analysis suggests that a meaningful fraction of the code in a typical JavaScript application’s node_modules directory is dead weight — polyfills for features that don’t need polyfilling, micro-packages that could be replaced with inline code, and duplicate implementations of identical functionality. It’s not uncommon for node_modules to exceed 500 megabytes in a large project. Some of that is unavoidable. A lot of it isn’t.
The consequences ripple outward. Larger bundles mean slower page loads for end users, particularly on mobile devices and in emerging markets where bandwidth is constrained. Slower builds mean slower developer feedback loops. Bigger deployment artifacts mean higher infrastructure costs. And the sheer complexity of deep dependency trees creates security surface area — every package is a potential vector for supply chain attacks, as the industry learned painfully from incidents like the event-stream compromise in 2018 and the colors and faker sabotage in 2022.
This isn’t a new conversation, exactly. The JavaScript community has been talking about dependency bloat for years. The left-pad incident in 2016, when the removal of an 11-line package from npm broke thousands of builds worldwide, was a wake-up call. But awareness hasn’t translated into systemic change. If anything, the problem has gotten worse as the JavaScript tooling stack has grown more complex — bundlers, transpilers, linters, test runners, each with their own dependency trees, each pulling in overlapping sets of utility packages.
Recent discussions on X and developer forums suggest growing frustration. Engineers report spending hours auditing dependency trees, trying to understand why their bundle sizes have ballooned. Some have adopted tools like Bundlephobia to evaluate package sizes before installing them. Others have turned to newer, leaner alternatives — Bun instead of Node.js, esbuild instead of webpack, native browser APIs instead of utility libraries.
But individual vigilance only goes so far when the problem is structural. A developer can choose lean dependencies for their own code, but they can’t control what their dependencies depend on. And the npm resolution algorithm, while sophisticated, doesn’t optimize for minimal duplication — it optimizes for compatibility, which often means installing multiple versions of the same package to satisfy different version constraints in different parts of the tree.
Garbutt’s proposed solutions are pragmatic rather than radical. He argues that library authors should audit their dependencies regularly, drop polyfills for features that are universally supported, and prefer native APIs over utility packages wherever possible. He also advocates for better tooling — static analysis tools that can flag unnecessary polyfills, bundle analyzers that surface duplication, and package managers that make it easier to deduplicate dependency trees.
Some of this tooling already exists in nascent form. The npm dedupe command attempts to flatten dependency trees to reduce duplication. Bundlers like Rollup and esbuild perform tree-shaking to eliminate dead code. But these tools operate at the symptom level. They can trim the fat from a bloated dependency tree, but they can’t prevent the bloat from accumulating in the first place.
The deeper issue is incentive alignment. Package authors are incentivized to maximize compatibility, which means keeping polyfills and supporting old environments long past the point of necessity. They’re incentivized to depend on existing packages rather than reimplement functionality, even when the existing package is itself bloated. And they face no real penalty for adding dependencies — npm makes it so frictionless that the cost is essentially invisible until someone downstream decides to audit.
There are signs of movement. The Deno runtime, created by Node.js originator Ryan Dahl, was designed partly as a response to these problems — it uses URL-based imports instead of a centralized package registry, and it ships with a standard library that reduces the need for third-party utility packages. Bun, another JavaScript runtime gaining traction, emphasizes performance and minimal overhead. And within the Node.js world, there’s growing momentum behind the idea of a richer standard library that would obviate many common utility packages.
The Web Platform itself has also been absorbing functionality that previously required libraries. The fetch API replaced XMLHttpRequest wrappers. structuredClone replaced deep-clone libraries. The Temporal API, still making its way through the standards process, aims to replace moment.js and its successors for date handling. Each native API adoption theoretically removes a category of third-party dependency. In practice, the old libraries linger.
So where does this leave the average JavaScript developer? Stuck, mostly, between the desire for lean, fast applications and the reality of a dependency culture that makes bloat the default. Garbutt’s framework — polyfills, gratuitous dependencies, duplication — is useful precisely because it gives developers a vocabulary for diagnosing specific problems rather than just vaguely complaining about node_modules being too big.
The fix won’t come from a single tool or a single runtime. It’ll come from a shift in norms — library authors treating dependency count as a cost rather than a convenience, package consumers auditing before installing, and the broader community recognizing that every unnecessary kilobyte of JavaScript is a tax levied on every user of every application that includes it. The web doesn’t have to be this heavy. But right now, it is.
WebProNews is an iEntry Publication