JavaScript Bloat in 2024

Original Article ↗ Hacker News Discussion ↗

Modern websites routinely ship multiple megabytes of JavaScript—even for relatively simple pages—with examples ranging from ~1–3 MB on the leaner side to 10–60 MB for services like Gmail, Figma and Jira. Commenters argue this bloat stems from heavy frameworks, poor code-splitting, third‑party tracking and organizational incentives, and note that compression and caching don’t fix CPU, memory and battery costs, especially on low‑end devices or slow connections. Some see large bundles as acceptable for rich web applications if navigation is fast after the initial load, while others point to lightweight sites and zero-dependency approaches as proof that far more efficient designs are possible.

Headline size comparisons & surprises

  • Commenters highlight huge JS payloads: Gmail and Figma ~20 MB, YouTube ~12 MB JS + 2.5 MB CSS, Jira ~58 MB, some landing pages at multiple MB “just to show text and images.”
  • Porn sites (e.g., Pornhub) are repeatedly cited as comparatively lean (≈1–1.4 MB) despite being media-heavy.
  • Several devs report their own complex apps at 1–4 MB and feel baffled that much larger companies ship 10–50 MB.

Compression, parsing, and device constraints

  • Debate over looking at compressed vs uncompressed sizes: compression reduces transfer but not parse/execute cost.
  • Older and low-end Android devices are emphasized as suffering most from large bundles and heavy DOM work.
  • Some argue size alone is a crude proxy; profiling shows DOM rendering, layout, inefficient reactivity, and waterfalls often dominate.

Sources of bloat: SPAs, frameworks, and tracking

  • Many blame SPA frameworks and over-engineered architectures for turning simple sites into apps.
  • Others say a lot of bytes are analytics, tag managers, AB-testing, and customer-support widgets run by marketing, sometimes injected without dev oversight.
  • Third‑party tracking scripts can themselves be multi‑MB and often load from external CDNs.

User experience: fast for some, unusable for others

  • Mixed reports: some find YouTube, GitHub, Discord, etc. “snappy”; others see noticeable lag and freezes, especially on mid/old hardware or mobile.
  • People on constrained connections (rural, roaming, 2 Mbps, or low data caps such as 15 GB/month) describe many modern sites as borderline unusable without blockers.
  • Offline/poor‑connectivity UX of apps like Spotify and Gmail is heavily criticized.

Debate: are large bundles actually a problem?

  • One side: “Less JS = better” is a useful heuristic; 10–50 MB for basic UIs is clear waste and harms median users.
  • Other side: cost is acceptable on “normal” connections; better to optimize overall UX (caching, fast in‑app navigation) than chase bundle size metrics.
  • Some argue we should fix caching/PWA and platform issues rather than obsess over kilobytes.

Methodology critiques and nuances

  • Multiple comments point out measurement issues in the article:
    • Looking only at cold loads and uncompressed sizes.
    • Disabled cache exaggerating repeat downloads (e.g., React docs sandboxes).
    • Some “static-looking” pages are actually front-doors to multi‑tool webapps (e.g., Outlook, Translate).
  • Others counter that even with these caveats, order‑of‑magnitude differences and real‑world sluggishness show a genuine bloat problem.

Alternatives, tools, and practices

  • Suggested mitigations: code‑splitting, lazy loading, virtual lists, avoiding unnecessary DOM nodes, and bundle analysis tools (e.g., Webpack/Rollup analyzers).
  • Some advocate zero‑dependency or minimal‑dependency approaches, HTMX/PJAX‑style navigation, or newer “resumable” frameworks (e.g., Qwik).
  • Strong recurring theme: organizational incentives (marketing, speed of development) favor piling on JS; performance has few champions.