Do I Need React for a Website? Usually Not — Here's What to Use Instead
Do you need React for a website? For most content and marketing sites, no — server-rendered HTML plus a little vanilla JS is faster, more accessible, and lasts longer.
Do you need React for a website? For the overwhelming majority of content and marketing sites — blogs, brochure sites, documentation, portfolios, landing pages — no. Server-rendered HTML with a sprinkle of vanilla JavaScript is faster to load, easier to make accessible, cheaper to maintain, and will still work in ten years. React earns its keep when your interface is a genuinely stateful application, not a set of pages someone reads.
We say this as people who ship React professionally. This is not a "JavaScript bad" rant. It's a tradeoff argument, and the tradeoff usually points the other way for the kind of site most people are actually building.
Do I need React for a website? Start by classifying what you're building
The single most useful question is: is this a document, or is this an application?
- Documents — pages whose job is to present content the user reads or scans. A marketing homepage, a case study, a pricing page, a journal post, a docs site. State is shallow: a menu toggle, a tab, a form. The URL is the state.
- Applications — interfaces with deep, persistent, client-side state that changes faster than the network: a spreadsheet, a design canvas, a trading dashboard, a drag-and-drop builder, a chat client. The DOM has to stay in sync with a model that lives in the browser.
React was built for the second category. Facebook's news feed is an application. Reaching for the same tool to render a chocolatier's product page is like renting a forklift to carry a single grocery bag. It works. You also now own a forklift.
The hidden cost: hydration
Here's the part that gets glossed over. A React site doesn't just send HTML. Even with server-side rendering (Next.js, Remix, Astro islands), the browser receives the rendered HTML and then downloads the JavaScript bundle, re-executes your component tree, and re-attaches event handlers to DOM that already exists. This second pass is called hydration, and it is pure overhead from the reader's point of view — the page already looked done.
What does hydration actually cost?
- Bytes. A baseline React + framework runtime is tens to hundreds of kilobytes of JavaScript before you write a line of your own. That ships to every visitor, every page, including the ones who bounce in two seconds.
- Main-thread time. JavaScript parse and execute is far more expensive per byte than HTML or images, and it blocks the main thread. On a mid-range Android phone — still the median device for a lot of the web — this is the difference between a page that's interactive instantly and one that looks ready but ignores your taps for a beat.
- A second source of truth. Now the same UI exists twice: once as server-rendered markup, once as a component tree. Mismatches between them are a whole category of bug ("hydration error") that simply cannot occur if there's no hydration.
For an application, you pay this cost gladly because you get a reactive UI in return. For a page someone reads once, you paid for a forklift to move a grocery bag.
What server-rendered HTML + a little vanilla JS buys you
Our own site runs on PHP 8.3 on OVH shared hosting behind Cloudflare, with Cockpit CMS v2 (SQLite) as the content store and no build step at all. The pages you're reading are assembled on the server and sent as finished HTML. There is no client framework. Here's what that posture actually delivers.
1. Performance, for free
The fastest JavaScript is the JavaScript you never send. A server-rendered page is interactive the moment it paints, because being painted is being interactive — links work, forms submit, anchors jump. There is no hydration gap, no "Time to Interactive" lagging behind "First Contentful Paint." Cloudflare caches the HTML at the edge and most visitors never even hit our origin.
2. SEO and AI crawlers that actually see your content
Crawlers — Google's, and increasingly LLM crawlers building answer engines — get a complete document on the first request. No waiting for JS, no rendering budget gamble. Your content, your structured data, your internal links are all there in the initial response. With client-rendered apps you're betting that every crawler executes your JavaScript correctly and patiently. Some do. Many don't, and the ones that matter most for AI answer extraction often don't.
3. Accessibility by default
Semantic server-rendered HTML — real tags, real <button> elements, real <form> with a server action — is accessible before you do anything else. Screen readers, keyboard navigation, and browser back/forward all work because you used the platform instead of reimplementing it. Most accessibility failures we audit come from <div onClick> standing in for a button, or a client router that breaks focus management and the back button. You can't break what you never replaced.
4. Longevity and a tiny maintenance surface
A no-build PHP-and-HTML site has almost no dependency churn. There is no node_modules to rot, no bundler config to migrate, no framework major version forcing a rewrite every couple of years. We deploy by syncing files. A site we build this way will run, unchanged, far longer than the half-life of any current JavaScript framework. The cheapest code to maintain is the code that doesn't exist.
"But I need interactivity"
You almost certainly need some, and almost certainly less than a framework. The vast majority of "interactive" needs on a content site are handled by a few dozen lines of vanilla JavaScript or the platform itself:
- Mobile menu, accordions, tabs — a tiny event listener, or
<details>/<dialog>with zero JS. - Form validation — HTML constraint validation attributes (
required,type="email",pattern) plus a server check. - A bit of dynamic content — fetch JSON and update a region.
fetch()has been in every browser for years. - Progressive enhancement — render it on the server, then enhance with JS for those who have it. The page works either way.
This is the same discipline behind our cookieless, GDPR-friendly analytics: a few kilobytes of script that does one job, instead of a tag manager that loads a megabyte of third-party surveillance.
When React (or a SPA) IS the right call
We'd be the contrarians we're criticising if we pretended React is never right. Reach for it — gladly — when:
- The UI is the product and it's deeply stateful. Editors, dashboards with live data, design tools, anything with drag-and-drop, multi-pane sync, or optimistic updates. This is React's home turf and it's excellent there.
- You're behind a login. An authenticated app dashboard usually doesn't need SEO, and the SPA model (load the shell once, then talk to an API) fits perfectly. We used exactly this shape for the recommender-driven surfaces in the Jofit wellness product.
- You have a large team and a component-driven design system. React's component model and ecosystem genuinely pay for themselves at scale and with many contributors.
- Highly interactive, app-like flows — multi-step wizards with rich client state, real-time collaboration, anything where round-tripping to the server per interaction would feel broken.
And the honest middle ground: if you genuinely want the React component model but you're building a content site, use an islands architecture (Astro) — ship static HTML and hydrate only the interactive components, not the whole page. That's a principled way to have it both ways.
The short version
- Building a document (content/marketing site)? Server-rendered HTML + a little vanilla JS. No React, no build step. Faster, more accessible, cheaper, longer-lived.
- Building an application (stateful, behind a login, app-like)? React or a similar SPA framework is a fine, often correct choice.
- Want components on a content site without the hydration tax? Use islands (Astro) and hydrate selectively.
- Hydration is the second pass where the browser re-runs your JS over already-rendered HTML to make it interactive — pure overhead for pages people only read.
The default for the web should be HTML. React is a powerful, specific tool for a specific job. Most websites aren't that job — and you'll ship something faster, more accessible, and easier to keep alive if you start by asking whether you need it at all. Usually, you don't.