A brief look at the three main causes of bloat in our JavaScript dependency trees, and how we can start to address them.

Hacker News is a community-driven platform for sharing and discussing technology news, startups, and programming-related topics. Through user submissions and comments, Hacker News offers insights into emerging technology trends, industry developments, and entrepreneurial ventures. Readers can participate in discussions, share their insights, and stay informed about the latest advancements in technology and innovation.

Hacker News

JavaScript dependency trees have grown bloated over time due to three main causes: (1) packages built for very old engines (ES3/IE6) or cross-realm safety that most developers no longer need, (2) atomic architecture where trivial one-liners like `Array.isArray(val) ? val : [val]` became their own npm packages with single consumers and supply chain risks, and (3) ponyfills for features now natively supported everywhere that were never removed. Tools like knip, the e18e CLI, npmgraph, and the module-replacements project can help identify and eliminate this bloat. The author argues the small group needing legacy compatibility should maintain their own special stack, while the majority should benefit from modern, lightweight dependencies.

The Three Pillars of JavaScript Bloat

1. Older runtime support (with safety and realms)

3. “Ponyfills” that overstayed their welcome