43081j's latest post dissects JavaScript bloat into three root causes that most teams are still ignoring — and with a 393-point HN thread backing it up, clearly the frustration is shared.
The three pillars: unnecessary polyfills, unchecked transitive dependencies, and over-transpilation. None of these are new complaints individually, but the post's strength is showing how they compound. Your Babel config targeting ES5 generates polyfills for features that 97% of your users' browsers already support. Those polyfills pull in core-js, which pulls in its own dependency tree. And your bundler dutifully packages all of it because no one told it not to.
The numbers are damning. A typical React project ships hundreds of kilobytes of code that exists solely to support browsers that represent a fraction of real-world traffic. The irony is thick: teams obsess over shaving milliseconds off API response times while shipping megabytes of JavaScript that never needed to exist.
The polyfill problem is the most fixable. Modern baseline browser support (ES2020+) eliminates the need for the vast majority of polyfills shipping today. If your browserslist config still includes IE11 or targets anything below ES2017, you're paying a tax for users who almost certainly don't exist in your analytics. Check your actual traffic data before your build config.
Transitive dependencies are harder. One top-level import can cascade into dozens of packages, each with their own opinions about what to bundle. Tools like bundlephobia help at selection time, but the real fix is cultural: treat bundle size as a first-class metric in code review, the same way you'd flag an N+1 query.
Over-transpilation is the sneakiest pillar. TypeScript and modern syntax get compiled down further than necessary because tooling defaults are conservative. The output often includes helper functions duplicated across modules — runtime overhead that exists because the build pipeline was configured once and never revisited.
The actionable takeaway: audit your browserslist, inspect your actual bundle output (not just the source), and question every transpilation target. The JavaScript ecosystem has matured enough that the defaults from 2020 are actively harmful in 2026. Your users on modern browsers are paying for compatibility with ghosts.
Well-written article, manages not to sound rant-y while describing the problem well.I feel like part of the blame for the situation is that JavaScript has always lacked a standard library which contains the "atomic architecture" style packages. (A standard library wouldn't solve every
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 t
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 everywhe
Everyone trash talking the JS ecosystem without contributing the slightest to the conversation would benefit a lot if they read https://www.artmann.co/articles/30-years-of-br-tags in order to understand the evolution of the language and its tooling.Nobody argues what we currently
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
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 h