Why we ship websites with no client-side JavaScript framework (and when you should)

Somewhere along the way, “build a website” quietly came to mean “build a JavaScript application that happens to display a website.” A marketing site with five pages and a contact form gets shipped as a single-page app: a framework, a build pipeline, a bundle the browser downloads and executes before anything appears, and a maintenance surface that outlives the reason it was chosen. For a lot of sites, that is a heavy answer to a light question.

We build most of our websites the other way — rendered on the server, sent as HTML, with little or no client-side framework. This is not nostalgia, and it is not a rule we apply blindly. It is a default we picked because it produces faster, more accessible, longer-lived sites for the kind of work most businesses need. It is also a default with clear exceptions, and being honest about those is the point of this post.

What “no client-side framework” actually means

It does not mean no JavaScript at all. It means the page is assembled into finished HTML on the server and sent to the browser ready to display, rather than shipped as an empty shell that a framework fills in after it downloads and runs. Where a page needs a little interactivity — a menu, a form, a small widget — we add a small, targeted piece of JavaScript for that one thing, instead of running the entire page through a framework’s rendering engine on the client.

The distinction is between “HTML with a few sprinkles of behaviour” and “an application that constructs the HTML in your browser every time.” For content-led sites, the first is almost always the better trade.

Why this is the better default

It is faster, structurally. When the server sends finished HTML, the browser can show it immediately. There is no bundle to download, parse, and execute before the first meaningful pixel. A single-page app inverts this: the user waits for JavaScript to arrive and run before they see content, which is felt most sharply on mid-range phones and slower connections — which is most of the real world. Rendering on the server and delivering from close to the user, as Cloudflare’s network does, removes an entire category of delay rather than optimizing around it. We build on Cloudflare’s platform partly for exactly this reason.

It is more accessible by default. HTML that exists on arrival works with screen readers, keyboard navigation, and assistive technology out of the box, because the semantic structure is there before any script runs. Framework-rendered pages can absolutely be made accessible, but accessibility becomes something you have to actively maintain against a moving target rather than something the platform gives you for free. Starting from real HTML means the floor is higher.

It degrades gracefully. A server-rendered page still shows its content if a script fails to load, a network hiccups, or a browser extension misbehaves. A page that depends on client-side JavaScript to render anything at all shows a blank screen when that JavaScript fails. Fewer moving parts between the user and the content means fewer ways for the content to not arrive.

It is cheaper to maintain over years. This is the one businesses feel long after launch. A framework is a dependency, and dependencies age: major versions change, patterns get deprecated, the surrounding tooling moves on, and a site built on last cycle’s conventions needs ongoing work to stay current and secure. HTML and a small amount of standard JavaScript age far more slowly. A zero-framework site written carefully today needs less attention in three years than a framework app of the same size — and less attention is real money for a small business that would rather not re-platform its website every few years. It is part of why we work the way we do: building things that stay built.

The SEO and sharing story is simpler. Search crawlers and link-preview scrapers get the real content in the initial response, with no dependence on whether they executed the page’s JavaScript. You spend less effort making sure machines can see what humans see, because there is only one version of the page.

When a framework is the right call

Here is the honest half, because “no framework” as a dogma would be its own mistake. Client-side frameworks like React and Vue exist because they solve genuine problems very well, and there are whole categories of product where they are clearly the correct choice.

Reach for a framework when the interface is the product and it is genuinely application-like:

• Rich, interconnected client state. A dashboard where a dozen controls all affect each other, a design tool, a spreadsheet-like editor, a booking flow with many interdependent steps. When the UI has to keep a lot of state consistent in the browser and re-render large parts of itself in response to user actions, a framework’s whole reason for existing is to manage exactly that, and hand-rolling it is a worse trade.
• Real-time, live-updating views. A chat interface, a collaborative editor, a live dashboard that changes as data streams in, anything with presence or continuous updates. Keeping the screen in sync with fast-changing state is precisely what these tools are built for.
• Highly interactive, app-shaped experiences that people keep open and work inside for long sessions, where the cost of the initial JavaScript load is amortized over a long, interaction-heavy visit rather than paid on a five-second brochure-page glance.

For these, the framework earns its weight. The initial cost buys you a manageable way to handle complexity that would otherwise be far harder to get right. That is not a marketing site with a form — that is custom software, and we build that on frameworks when the problem calls for it. The tool is not wrong; using it for the wrong shape of problem is.

How to tell which you have

The useful question is not “framework or not” in the abstract. It is: is this thing a document or an application?

If it is mostly content that people read — pages, posts, marketing, a portfolio, a form or two — it is a document, and a document is best served as HTML from the server. If it is mostly something people operate — state, real-time updates, long interactive sessions — it is an application, and an application is often best built with a framework. Many businesses need one site of the first kind and, later, one tool of the second kind, and the right answer is to build each as what it actually is rather than forcing a single approach onto both.

The failure mode we see most is a document built as an application: a simple site carrying a framework’s full weight and maintenance cost for interactivity it never really needed. It is slower, harder to keep accessible, and more expensive to own, in exchange for capabilities that go unused.

The short version

We default to server-rendered, near-zero-framework sites because for content-led websites they are faster, more accessible, and cheaper to keep running for years — and we reach for React or Vue without hesitation when a project is genuinely an application with rich client state or real-time behaviour. The skill is not preferring one tool; it is matching the tool to the shape of the problem.

If you are not sure which shape your project is — or you have a site that feels heavier and harder to maintain than it should be — send us two paragraphs about what you are building and how people will use it, and we will reply in writing within one business day.