~/sumit/portfolio — the-case-for-boring-frontends.md
writing.md/The case for boring frontends
---
title: "The case for boring frontends"
date: 2024-01-29
tags: [opinion]
reading_time: 5 min
slug: the-case-for-boring-frontends
---

The case for boring frontends

5 min read opinion by sumit

Every few months someone reminds the community that HTML is enough. Every few months everyone nods, keeps writing React apps, and goes back to Redux.

I've been on both sides of this. This essay is why I'm mostly off the bus.

The argument, compressed

Most "apps" are not apps. They're documents with a few forms. Treating a docs site, a blog, an admin panel, or a marketing page as an SPA is choosing the wrong tool for the job the same way treating a screwdriver as a hammer is choosing the wrong tool. You can hit the nail; it just takes longer and bends the nail.

A boring frontend means:

  • HTML rendered on the server — by whatever framework
  • CSS that's mostly static
  • A sprinkle of JS where interactivity matters (not everywhere)
  • No client-side routing unless the UX actually demands it

You get a site that loads instantly, ranks on SEO without effort, works with JS disabled, and can be maintained by a single person on weekends. None of which is true of a typical SPA.

What I used to think

I used to think the SPA-everywhere gradient was justified because:

  • Transitions feel nicer
  • State is easier to manage in one runtime
  • APIs stay clean because the frontend is decoupled

Here's what I actually observed after a few years:

  • Transitions mostly just delay the page I wanted
  • State is harder to manage in one runtime, because you're now the source of truth for a thing that used to be the server's job
  • APIs get messier, not cleaner — they become views of the frontend, not a stable interface

When I still reach for an SPA

There are real cases:

  • Real-time collaboration (figma, multiplayer tools)
  • Dense interactive UIs (maps, editors, whiteboards)
  • Offline-first apps
  • Anything with a persistent UI state across routes

If your app is on that list, build it as an SPA. If it's not, consider that you're paying the SPA tax for an experience the user wasn't asking for.

The honest version

The boring stack lets me ship on weekends. That's the actual test for me. If I can't build and deploy a small idea in a Saturday morning, the stack is too heavy.

Five years in on this approach, the gap between "I thought of a thing" and "it's live" has gone from days to hours. That gap is where most good ideas die. Anything that shortens it is, in my view, the actual job.