console.log([1, 2, 3].at(-1)) transpiles to 44k

A single modern JavaScript feature—`Array.prototype.at(-1)`—can balloon from a tiny snippet into tens of kilobytes of ES5-era helper code when legacy support is handled through transpilation plus polyfills. The core point is less about `at()` itself and more about the real-world cost of targeting old browsers: legacy compatibility often turns into “download it everywhere, use it nowhere,” especially when build defaults and library packaging don’t line up.

The discussion starts with a concrete size shock. Logging `[1, 2, 3].at(-1)` becomes roughly 44 KB of minified ES5 output after transpilation and polyfill injection. The example is used to show why: Babel/Core-js-style support requires large bundles of runtime machinery (descriptors, symbols, regex-related helpers, and other edge-case coverage) even when the original code doesn’t need those complexities. That cost is not just theoretical—supporting legacy browsers can force developers to ship far more code than the feature actually requires.

From there, the focus shifts to whether this bloat helps anyone. Using HTTP Archive-style measurements across the most popular sites, the analysis finds that a large majority of websites still serve untranspiled ES6+ syntax in production, while many also include ES5 helper libraries in the same bundles. Even more striking: many sites that ship ES5 helper code still fail to work in IE11. In other words, users on the one browser that needs the legacy helpers are often not getting a working experience, while everyone else pays the download cost.

The root causes are traced to three layers that interact badly: (1) default configurations in popular bundlers/build tools, (2) how widely used libraries publish their builds (often with ES5 helper dependencies and/or ES6+ code paths), and (3) the common practice of excluding `node_modules` from transpilation. That exclusion speeds builds and avoids needless work, but it also means library code may slip through untranspiled—producing ES6+ syntax in production—while the site still carries ES5 helpers for other reasons.

The recommendations follow logically. ES5 should no longer be treated as a default compilation target for modern production. Build tools and libraries should avoid hard-coding a fixed legacy browser policy; instead, they should let website developers choose targets based on their actual audience. Library authors, in particular, are urged to publish standard, modern JavaScript and avoid deciding legacy compatibility for every consumer—because library authors lack visibility into each importing site’s deployment constraints and build pipeline.

The practical takeaway is a shift in responsibility: cross-browser support should be a website build decision, not something silently imposed by library packaging defaults. Baseline-style feature targeting is presented as a more future-proof approach than clinging to ES5, since it updates with browser support rather than freezing the ecosystem in an older compatibility era.