A Smaller React Surface Area

I have been more careful this year about where React belongs on a website.

That is not because I dislike React. I use it where it makes sense. The problem is that it is easy to reach for a large client-side application shape when the website itself is mostly content, forms and a few genuinely interactive areas. At that point, the question is not whether React can build it. The question is whether the visitor and the project benefit from that much JavaScript owning the page.

The more content-led websites I work on, the more I like the idea of a smaller React surface area. Use React for the parts of the page that need complex state or interaction, but do not make it responsible for everything by default. A contact page, article page or service page should not carry application-level complexity unless it has a reason.

Starting With The Interaction

The first question I ask is what actually needs to be interactive. A pricing calculator might. A product configurator probably does. A search interface with filters might. A simple content section with headings and images probably does not.

That distinction matters because every interactive layer brings maintenance with it. There is state to manage, rendering behaviour to understand, build tooling to maintain and JavaScript to send to the browser. Sometimes that is the right trade. Sometimes it is just habit.

I find it useful to sketch the page as static content first, then identify the parts that genuinely need client-side behaviour. Those parts can then be isolated instead of turning the whole page into an application.

The Island Approach In Practice

The idea of islands is useful because it matches how many real websites behave. Most of the page is content. A few areas are interactive. Those interactive areas can be hydrated separately, while the rest of the page remains plain HTML and CSS.

Even when I am not using a specific tool built around that idea, the thinking is helpful. It encourages me to keep boundaries clear. The article body is not React state. The navigation may not need React. The calculator probably does. That separation makes the page easier to reason about.

<main>
  <article>
    <h1>Service Pricing</h1>
    <p>Static content explains the service clearly.</p>
  </article>

  <div id="pricing-calculator"></div>
</main>

import { createRoot } from 'react-dom/client';
import PricingCalculator from './PricingCalculator';

const element = document.getElementById('pricing-calculator');

if (element) {
  createRoot(element).render(<PricingCalculator />);
}

That pattern is simple, but it keeps the responsibility clear. React owns the calculator, not the whole page. The rest of the website can remain fast, readable and easier to maintain.

Why This Helps WordPress Builds

This thinking also fits well with WordPress. A WordPress site already has a strong server-rendered content model. Posts, pages, templates and blocks all produce HTML. Adding React for specific admin or front-end interfaces can be useful, but replacing the whole shape of the site is not always necessary.

For example, a booking widget, dashboard panel or filtered resource library might justify a React component. The surrounding page may not. Keeping that boundary clear means the client still gets the benefits of WordPress content management, while the more complex interface gets the structure it needs.

It also helps performance. Less JavaScript has to be parsed and executed before the page feels ready. The visitor can read the content without waiting for an application to wake up around it.

The Maintenance Argument

The other benefit is maintenance. Smaller interactive areas are easier to replace, test and reason about. If the calculator changes in a year, I can work on that part without worrying that the entire page rendering model is tied to it. If the content structure changes, it can remain a normal WordPress or server-rendered change.

That separation reduces risk. It also makes the project easier for another developer to understand later. The codebase explains which parts are content, which parts are interactive and where the boundary sits.

Retrospective Thoughts

I think the question for React in 2023 is not whether it is powerful enough. It clearly is. The better question is how much of the page it should own.

For me, the answer is increasingly practical. Let React handle the parts that need its strengths. Let HTML, CSS and the server handle the parts they are already good at. A smaller surface area is not less ambitious. It is often the cleaner decision, especially on websites that need to be fast, editable and maintainable over time.