--- title: "Why Content-Heavy Websites Should Ship Less JavaScript" description: "Content-heavy websites should prioritize fast, stable, accessible pages by reducing JavaScript and letting HTML, CSS, and the browser do more of the work." date: "2026-05-06T14:26:00.000-04:00" updated: "2026-05-06T14:26:00.000-04:00" url: "/writing/web-platforms/why-content-heavy-websites-should-ship-less-javascript" --- # Why Content-Heavy Websites Should Ship Less JavaScript We spent a decade building websites like apps. We pulled in heaver runtimes, state libraries, and front-end frameworks to optimize for application-like experiences. We changed how we built, how we thought about the browser, what skills we learned, and even how we hired. But for those building content-driven experiences with the main purpose of relaying information, it was often the wrong choice. In a world where content expands beyond the human eye to search engines, AI systems, and retrieval pipelines, the front-end framework trade-off becomes ever more difficult to justify. ## How Content Sites Inherited the App Framework Model To be fair, the framework ecosystem was the right move in many cases. If you’re trying to build a highly interactive application on the web, React, Vue, Angular, and other frameworks make a lot of sense. Frameworks solve real challenges for front-end development for web experiences that behave like an application. Quality of life improvements include: - Managing stateful interfaces at scale - Creating UIs from composable components - Increasing performance by reducing manual DOM updates - Making rendering more declarative and predictable User interfaces in need of frequent state changes and rendering updates certainly benefit. Consider a web-based audio interface where the state of each instrument channel level streams from a WebSocket. A standard PCM16 mono stream at 16 kHz represents tens of thousands of samples per second before you even derive the state of the visual meter. For a web UI handling hundreds or thousands of visual updates per second, manual DOM updates on the main thread struggle to keep up. Assuming offloading the rendering path to canvas or WebGL is off the table (a topic for another day), this is exactly the kind of problem modern front-end frameworks were built to manage. Frameworks like React made the UI declarative instead of hand-managed. Rather than writing brittle code to keep DOM elements in sync with constantly changing state, developers could describe the interface in states and let reconciliation handle the rest. For real-time, fast-changing interfaces, it was a beautiful thing. As the SaaS economy grew and, with it, the demand for application UIs on the web, it made all the sense in the world for front-end frameworks to take off… for applications. What made far less sense, and what may someday end up as a mimetic theory case study, was the trend for editorial content hubs, blogs, and other content-heavy sites to follow suit. Modern blogs and content-driven websites inherited too much of the front-end application model by default. ## Content Sites Need Discovery, Not Interactivity The fundamental purpose of content-driven sites is to disseminate information: a fact often lost in the chaos of secondary concerns. You could reasonably ask: why wouldn’t we want to curate and display information in a rich, interactive experience? It’s a fair question. But content platforms now live in a world shaped by zero-click search, runtime costs associated with downloading frameworks, and AI discovery platforms incentivized to keep users inside _their_ environments rather than send them to yours. “What action would you like me to take next?…” For the purposes of this piece, I’m defining “content-driven” as: - Primarily an experience of reading, searching, or scanning for an answer - Designed to put answers in front of users, regardless of the delivery mechanism - Managed separately from development teams, often through a CMS - Optimized for both traditional SEO and AI discovery This creates a different set of architectural priorities from rich web apps. The right question is not, “Are frameworks like React and Vue objectively worse for content-driven sites?” It is, “How much runtime machinery and abstraction does this website _really_ need?” Does a server-side rendered blog, whose content is already available on the initial document fetch, really need client-side state machinery by default? Does it need to accept the costs of hydration when the experience is, unlike an audio metering UI, largely stateless? These are choices that deserve consideration beyond “this is what modern front-end teams do.” Not every website benefits from modern frameworks and the runtime, organizational, and complexity costs that can follow. For many experiences, the framework model over-engineers secondary concerns that may never meaningfully appear — particularly for websites whose main value lies in content and structure inherently handled by HTML. ## How Low-JavaScript Architecture Improves Content Delivery Let’s assume we’re talking about the subset of websites where the content itself, rather than the presentation, is the real star of the show. For those kinds of sites, there are several major advantages to a zero or low JavaScript architecture: 1. Run-time performance 2. Resilience 3. Simplicity and maintainability 4. Consumption at scale ### Run-time Performance The key concern should be rendering content as quickly and reliably as possible. All else equal, less JavaScript means a smaller bundle for the browser to fetch, less bandwidth used, and faster parsing and execution for the scripts that do exist. In short, it’s the quickest path to getting users the information they came for. ### Resilience Low JavaScript architectures, rooted in the original web, are naturally resilient. Structured HTML is far more durable than rich web apps, particularly when a user has a slower connection. Once the document arrives, users receive the actual content rather than waiting on an application shell, hydration, or additional client-side execution. This creates the shortest path from user query to answer. ### Simplicity and Maintainability Low JavaScript architectures also benefit from simplicity and maintainability. By returning to the basic idea of content first, site owners and content creators can eliminate many of the moving parts that otherwise weigh down the publishing process. Client-side routing, complex state management, hydration issues, dependency management, and framework-specific development all become less of a concern. The result is a simpler and more maintainable ecosystem. ### Consumption at Scale Finally, humans aren’t the only users interacting with a typical website. SEO bots and indexers benefit greatly from simple, structured content returned directly from a web service, without having to depend on hydration or JavaScript execution. Yes, headless bots can and do execute JavaScript on framework-driven websites, but it’s far less efficient. And then there’s AI. Content platforms now live in a world shaped by zero-click search with AI discovery platforms incentivized to keep users inside _their_ environments rather than send them to yours. “What action would you like me to take next?…” The primary consumption of content may no longer happen inside the carefully curated, application-like experience of the domain environment. ## Why Zero-JavaScript Should Be the Default for Content Sites When the goal is a highly interactive web application, front-end frameworks make sense and likely represent the right decision. But given the reasons above, I believe zero or low JavaScript architectures should be the default for blogs, editorial, and other content-driven experiences. At the very least, choosing a front-end framework over an HTML-first approach should be an architectural decision rather than a reflexive default. Based on the recent(ish) popularity of frameworks like Astro, Qwik, and others, it seems quite a few people agree. Using Astro as one example, you can often get the best of both worlds: zero JavaScript by default, with the ability to declare “islands” of app-like, hydrated framework components when you need them. You can even choose your preferred framework for those specific app-like scenarios without committing the entire site to it. But that’s a post for another day. So the next time you reach for a framework, or prompt AI to build with one, take a few seconds to ask yourself: “Is the priority scalable content or an app-like presentation?” If the answer is the former, or especially if it’s “both,” do yourself a favor and check out a low JavaScript framework like Astro or something similar. You might be surprised by the results.