You Don't Need React to Build a Web App

A web app can be a ten-line route and a template.

Most people never find that out, because the tutorials they start with begin with a framework. So they come to believe that building for the web means React, and that anything simpler is a toy.

It isn't. Here is the version that gets skipped.

The simplest real web app

A server receives a request, fetches some data, and returns HTML. That is a web application.

With Node and EJS, it looks like this:

app.get("/projects", async (req, res) => {
  const projects = await getProjects();
  res.render("projects", { projects });
});

And the template:

<h1>Projects</h1>
 
<% projects.forEach(project => { %>
  <article>
    <h2><%= project.name %></h2>
  </article>
<% }) %>

The browser receives finished HTML. There's no build step for the front end, no bundle to ship, no client-side state to keep in sync. The page works if JavaScript fails to load.

For an admin panel, an internal tool, a content site, or the first version of a product, that is often all you need.

The progression nobody shows

Each step adds one capability, and each one is worth taking only when you feel the need for it:

HTML                     → a page
+ CSS and JavaScript     → a page that looks good and responds
+ a server               → a page built from live data
+ a template engine      → a server that stays organised
+ React                  → an interface made of components
+ Next.js                → conventions for routing, rendering and the server

Notice that nothing in that list replaces the step before it. React doesn't remove HTML, it generates it. Next.js doesn't remove the server, it organises one. The browser still receives HTML, CSS and JavaScript, and HTTP still carries them.

What React is actually for

React solves a specific problem: interfaces with a lot of state that changes while the person is using them.

Think of a dashboard with live data, filters that update a table, a form with fields that depend on each other. Breaking that interface into components lets you reason about each piece on its own:

Dashboard
├── Sidebar
├── Header
├── ProjectList
│   └── ProjectCard
└── ActivityFeed

If your screen looks like that tree, and pieces of it need to update independently, React earns its place.

What it costs

Nothing is free:

• A build step and a toolchain to maintain.
• More JavaScript for the browser to download and run.
• More complexity around loading data and rendering on the server.
• More moving parts when something breaks.

Those costs are worth paying when the problem needs them. They are a bad deal when the problem is a list of projects.

A quick test

Before reaching for a framework, I ask:

• Does the interface change a lot after the page loads?
• Do many separate parts share state?
• Will this grow into something with many screens?

If the answer to all three is no, a server and a template will do. If the answer to most is yes, use React and don't feel guilty about it.

I use Next.js too

I'm not against React. I've used Next.js for dashboards, including Spluur's, and this site runs on it.

The point isn't that React is wrong. It is that the choice should come from the problem. "Everyone else is using it" is a reason to be curious, not a reason to be done thinking.

The web existed before React. Useful applications were built with HTML, PHP, Rails, Django and plain Node long before it. The tools changed. The shape didn't:

User → Application → Data → Response

Choose the tools for the problem you have.