JavaScript-heavy approaches are not compatible with long-term performance goals

‘Less JavaScript, more speed’—devs cheer a server-side comeback while flame wars erupt

TLDR: An engineer argues that sending less code to your browser and doing more on the server keeps sites fast. Commenters split between “finally, obviously” and “not all tools are heavy,” with side debates about whether the web was built for apps at all—important because it affects everyday site speed and usability.

A performance engineer says the quiet part out loud: shipping tons of JavaScript slows your site down long-term. His fix? Do more work on the server before the page reaches your browser. Cue the comment section lighting up like a datacenter. One dev deadpans, “In other news: water is wet,” while another quips, “My how the tables have turned!” as server-first rendering—drawing the page on the server for a faster first view—suddenly feels trendy again.

But it’s not all applause. A counter-squad protests that not all tools are guilty. Fans of lighter frameworks like Svelte and Solid argue their downloads are small and snappy, pushing back on lumping everything in with heavyweights like classic React/Redux. The author’s spicy aside—“React is a framework”—adds fuel to a long-running “library vs framework” identity crisis, and the comments go full soap opera.

Then the plot twist: a veteran chimes in that the web’s core building blocks were built for documents, not apps, claiming that’s why browsers struggle with app-like sites. Another voice complains web components barely got a mention. Translation for non-tech readers: people are arguing whether we’re packing too much code into your browser, whether newer tools fix it, and whether the web was ever meant to be an app mall. The result? Drama, memes, and a rare moment of agreement: nobody wants slow sites.

Key Points

  • The author asserts that JS-heavy client-side approaches often conflict with long-term performance goals.
  • JS-heavy is defined as shipping large JavaScript payloads that run on the browser’s critical path, common in SPAs and present in some MPAs.
  • The author works on web performance at Automattic’s PerfOps team, handling monitoring infrastructure and cross-stack performance fixes.
  • Observed recurring issues include slow loading, runtime performance problems, bundle size growth, and React-specific expensive re-renders.
  • The article argues React functions as a framework via inversion of control and challenges claims that modern framework-heavy stacks inherently lead to better outcomes.

Hottest takes

“My how the tables have turned!” — kylecazar
“In other news: water is wet.” — tommek4077
“Frameworks like Svelte, Solid, Vue etc have smaller bundle sizes” — slopinthebag
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.