Why I Still Build with Plain HTML and CSS

I have been building websites for over ten years. I have used WordPress, React, Next.js, Hugo, Eleventy, and probably a dozen other tools I am forgetting. And after all of that, my default choice for most client projects is still plain HTML and CSS. No framework. No bundler. No build step. Just files on a server.

People sometimes look at me funny when I say that. There is an assumption in our industry that if you are not using the latest JavaScript framework, you must be behind the times. But I would argue the opposite. Choosing static HTML and CSS for the right project is not a step backward. It is a deliberate, informed decision that benefits both me and my clients in ways that matter.

Speed that is hard to beat

A static HTML page loads fast. Not fast-ish. Not fast-after-the-JavaScript-bundle-finishes-parsing. Fast. When there is no client-side rendering, no hydration step, and no megabytes of JavaScript to download before the content appears, the browser just does what it was built to do: read HTML, apply CSS, and paint the page.

Most of my clients run small businesses. Their customers are searching on their phones, often on mediocre connections. Every millisecond counts. A static site consistently scores in the high 90s on Lighthouse without me having to wrestle with code splitting or lazy loading workarounds. The performance is baked in from the start, not bolted on after the fact.

Simplicity keeps projects on track

Every dependency you add to a project is a liability. Build tools break. Package versions conflict. Node modules folders bloat to absurd sizes. I have lost count of the number of times I have returned to a project after six months only to find that npm install throws a wall of deprecation warnings and the dev server will not start without an hour of troubleshooting.

With static HTML and CSS, there is nothing to install and nothing to break. I open the file, I edit it, I save it. The feedback loop is immediate. I can focus on the actual work instead of maintaining a toolchain. That simplicity also makes it easier to stay on schedule and on budget, which is something every client cares about.

No build step means fewer surprises

A build step is an abstraction layer between what you write and what gets served. Most of the time it works fine. But when it does not, debugging can be painful. Minification bugs, CSS purging that strips styles you actually need, environment variables that behave differently in production. I have dealt with all of it.

When the HTML file on my computer is the same HTML file the browser receives, there is an entire category of problems that simply cannot happen. What I see locally is what the client sees in production. That directness is underrated.

Longevity you can count on

HTML written in 2005 still works in every modern browser. The same cannot be said for a React app from 2018 that depends on a specific version of Webpack and a dozen plugins that are no longer maintained. Static HTML ages gracefully. It does not rot the way JavaScript projects tend to.

This matters because most of my clients are not going to redesign their site every two years. They need something that will work reliably for a long time with minimal maintenance. When I hand over a static site, I know it will still render correctly five years from now. That kind of durability is a genuine selling point, and I talk about it in more depth on my search page when discussing long-term content strategy.

Client handoff is straightforward

Not every client has a developer on staff. Many of them are small business owners who want to be able to make minor text changes themselves without calling me every time. With static HTML, I can walk someone through the basics in under an hour. Open the file, find the text between the tags, change it, save it, upload it. Done.

Compare that to explaining how to set up a local development environment, install Node, run a build command, and deploy through a CI pipeline. For a five-page brochure site, that level of complexity is not just unnecessary. It is unkind to the client. I would rather give them something they can actually manage.

SEO starts with good markup

Search engines can crawl static HTML effortlessly. There is no waiting for JavaScript to execute, no concerns about whether the crawler will see the fully rendered page, and no need for server-side rendering workarounds. Semantic HTML with proper heading structure, meta descriptions, and structured data gives you a solid SEO foundation without any extra tooling.

I have seen too many projects where teams spent weeks optimizing their framework-based site for search engines, solving problems that would not have existed if the site had been static in the first place. For content-focused sites like blogs, portfolios, and small business pages, plain HTML gives search engines exactly what they want on the first request.

When frameworks actually make sense

I am not anti-framework. That would be a ridiculous position to hold. There are projects where React, Vue, or Svelte are clearly the right choice. If a client needs a dynamic dashboard, real-time data updates, complex form interactions, or a single-page application with heavy state management, a framework earns its weight. I have built those kinds of projects and I will build them again.

The distinction I make is between applications and websites. A web application that users log into and interact with extensively benefits from a component-based architecture. A marketing site, a portfolio, a local restaurant page, a small nonprofit site. Those are websites. They mostly display information. And for displaying information, HTML and CSS have been doing the job well since the mid-1990s.

I keep a running list of tools and resources that I rely on for both static and framework-based projects. The right tool always depends on the job.

The boring choice is often the best choice

There is no conference talk in choosing plain HTML and CSS. Nobody is going to invite me to speak about my lack of a build step. And that is fine. My job is not to use interesting technology. My job is to deliver a website that loads quickly, ranks well, works reliably, and does not create headaches for the person who has to maintain it after I am done.

For most of the projects that land in my inbox, static HTML and CSS checks every one of those boxes. It is not glamorous. It is not trendy. But after more than a decade of building for the web, I have learned that boring and reliable beats shiny and fragile almost every time.