For more than a decade, the web development industry has been locked in an escalating arms race of JavaScript complexity. Single-page applications, sprawling client-side frameworks, and ever-larger bundles of code shipped to users’ browsers have become the default architecture for modern websites. But a growing chorus of engineers, performance researchers, and standards advocates is now arguing that this trajectory is fundamentally unsustainable — and that the industry must reckon with the consequences before the damage becomes irreversible.
A recent essay by Sara Soueidan, a prominent web standards advocate and front-end engineer, crystallizes this argument with unusual clarity. In her post titled “JS-Heavy Approaches Are Not Compatible With Long-Term Performance Goals,” published on her personal blog, Soueidan lays out a detailed case that JavaScript-heavy architectures are structurally at odds with the performance targets that both web standards bodies and major platform companies have been setting for the future of the web.
The Core Tension Between JavaScript Weight and User Experience
The central thesis is deceptively simple: every kilobyte of JavaScript sent to a user’s device carries a cost that HTML and CSS do not. Unlike static markup and stylesheets, JavaScript must be downloaded, parsed, compiled, and executed — a chain of operations that taxes the CPU in ways that scale poorly across the vast diversity of devices accessing the modern web. A high-end MacBook Pro can chew through a megabyte of JavaScript in milliseconds. A mid-range Android phone sold in Lagos, São Paulo, or Jakarta — the devices that represent the actual growth frontier of the internet — may struggle with the same payload for several seconds, during which the page is effectively frozen.
This is not a new observation. Google’s own Web Vitals initiative, which launched in 2020 and has been continuously refined since, explicitly identifies excessive JavaScript as a primary antagonist of metrics like Interaction to Next Paint (INP), Largest Contentful Paint (LCP), and Total Blocking Time (TBT). The Chrome team has published extensive research showing that JavaScript execution time is the single largest contributor to poor INP scores across the web. As Soueidan’s essay argues, the industry has acknowledged the problem in principle while continuing to build in ways that exacerbate it in practice.
Frameworks as Architecture, Not Just Tools
What makes Soueidan’s argument particularly pointed is its focus on architectural lock-in. When a development team chooses React, Angular, or a similar client-side framework as the foundation for a project, they are not simply selecting a tool — they are committing to an architectural paradigm that places JavaScript at the center of every user interaction. The framework itself becomes a baseline cost: before a single line of application-specific code runs, the browser must load and initialize the framework runtime. For React, this baseline has historically hovered around 40-45 kilobytes gzipped; for Angular, it can be substantially more.
The essay argues that this baseline cost creates a structural floor beneath which performance cannot drop, regardless of how carefully individual features are optimized. Teams can code-split, lazy-load, and tree-shake with great discipline, but they cannot escape the fundamental overhead of the paradigm they have chosen. This is analogous to a building’s foundation: once poured, it constrains everything built above it. And in the case of JavaScript-heavy architectures, the foundation is made of a material — client-side script execution — that is inherently expensive on constrained devices.
The Server-Side Renaissance and Its Discontents
The timing of this critique is not accidental. The web development community has been experiencing what might be called a server-side renaissance, with frameworks like Astro, Fresh, and enhanced versions of Next.js and Remix pushing more rendering work back to the server. The philosophy behind these tools is that HTML should be generated on the server wherever possible, with JavaScript reserved for genuinely interactive elements that cannot be accomplished any other way. This approach — sometimes called “islands architecture” or “progressive enhancement” — represents a philosophical return to the web’s original model, updated for modern capabilities.
Yet adoption of these lighter approaches remains uneven. Many large organizations have invested millions of dollars and thousands of engineering hours into JavaScript-heavy single-page application architectures. Migrating away from these systems is not a weekend project; it requires rethinking routing, state management, build pipelines, deployment infrastructure, and team skills. The sunk-cost dynamics are formidable. As Soueidan’s essay notes, the economic incentives of the framework ecosystem — where open-source projects are often backed by companies with their own strategic interests — further complicate the picture.
Real-World Performance Data Paints a Sobering Picture
The empirical evidence supporting the anti-JavaScript-heavy position continues to mount. The HTTP Archive, which tracks the composition of millions of web pages over time, has documented a relentless increase in median JavaScript payload sizes over the past decade. According to recent HTTP Archive data, the median mobile web page now ships over 500 kilobytes of JavaScript — a figure that has roughly tripled since 2015. Meanwhile, the performance gap between high-end and low-end devices has not narrowed; if anything, it has widened, as flagship phones gain processing power faster than budget devices do.
Google’s Chrome User Experience Report (CrUX), which aggregates real-world performance data from Chrome users who have opted in, tells a similar story. Pages that rely heavily on client-side JavaScript consistently score worse on Core Web Vitals metrics than pages that lean on server-rendered HTML. This correlation is robust across industries, geographies, and device categories. It is not a subtle statistical signal; it is a blaring alarm that the industry has largely chosen to acknowledge without fully acting upon.
The Accessibility Dimension That Often Gets Overlooked
Soueidan’s essay also raises a point that is frequently absent from performance discussions: the accessibility implications of JavaScript-heavy architectures. Screen readers, keyboard navigation, and other assistive technologies interact with the Document Object Model (DOM) as rendered in the browser. When that DOM is constructed entirely by JavaScript at runtime, rather than delivered as semantic HTML from the server, the opportunities for accessibility failures multiply. Custom JavaScript components must manually replicate behaviors — focus management, ARIA attributes, keyboard event handling — that native HTML elements provide for free. Every such reimplementation is a potential point of failure, and the empirical record shows that these failures are not hypothetical. The WebAIM Million report, which annually audits the accessibility of the top one million websites, consistently finds that JavaScript-heavy sites have higher rates of accessibility errors than their more traditional counterparts.
This accessibility dimension adds moral weight to what might otherwise be a purely technical debate. When a JavaScript-heavy architecture degrades performance on low-end devices and compromises accessibility for users with disabilities, it is not merely an engineering trade-off — it is a decision about who gets to use the web effectively and who does not.
What the Industry’s Leading Voices Are Saying Now
The debate has intensified in recent months across developer forums, conference stages, and social media. Alex Russell, a former member of the Chrome team and one of the most vocal critics of JavaScript bloat, has been arguing for years that the industry’s framework choices impose a “tax” on users that is both unnecessary and regressive. His analyses, published on his blog Infrequently Noted, have provided detailed breakdowns of JavaScript budgets and their real-world impact on performance metrics. Russell’s work has been influential in shaping the arguments that Soueidan and others now advance.
On the other side of the debate, framework advocates argue that the developer experience benefits of tools like React — component-based architecture, rich ecosystems of third-party libraries, strong typing with TypeScript integration — translate into faster development cycles and more maintainable codebases. These are not trivial advantages. In a labor market where experienced developers are expensive and scarce, tools that boost productivity have genuine economic value. The question, as Soueidan’s essay frames it, is whether that developer-side value is being purchased at an unacceptable cost to users.
The Path Forward: Hybrid Approaches and Hard Choices
The emerging consensus among performance-focused engineers appears to be that the future lies in hybrid approaches that use JavaScript surgically rather than structurally. The islands architecture pattern, popularized by frameworks like Astro, allows developers to build pages primarily from server-rendered HTML while selectively hydrating specific interactive components with JavaScript. This approach preserves the developer experience benefits of component-based frameworks while dramatically reducing the JavaScript payload delivered to users.
But even this compromise requires cultural change within development organizations. Teams must learn to ask, for every feature, whether JavaScript is truly necessary or whether HTML, CSS, and server-side logic can accomplish the same goal. This is a fundamentally different mindset from the one that has dominated front-end development for the past decade, in which JavaScript was the default answer to virtually every problem.
Soueidan’s essay, and the broader movement it represents, is ultimately an argument about values. It asks the web development industry to weigh the convenience of its current tools against the experience of its most vulnerable users — those on slow devices, slow networks, and those who depend on assistive technologies. It argues that the web’s long-term health depends on making that trade-off honestly, rather than continuing to optimize for developer comfort while hoping that Moore’s Law will eventually bail out the user experience. The data suggests that hope is not a strategy, and that the reckoning with JavaScript’s true cost is overdue.