In short
A zero-build-step static site — plain HTML, CSS, and vanilla JavaScript deployed as-is — works well for marketing sites and content-driven pages, giving up nothing in performance (often gaining it) while removing an entire category of tooling, dependency, and build-failure risk.
When zero-build makes sense
A build step (bundling, transpiling, a framework's compile pipeline) earns its complexity when a site genuinely needs client-side interactivity, complex state, or a large component tree. A marketing site, a documentation site, or most content-driven pages don't need any of that — they need HTML that displays content, and a build step there is often solving a problem that doesn't exist yet.
What you give up, and what you don't
You give up: a component framework's ergonomics, npm's package ecosystem, and hot module reloading during development. You do not give up performance — a static HTML file with no framework overhead often loads faster than an equivalent React or Vue app, because there's no JavaScript bundle to download, parse, and hydrate before content appears. For content-first sites, this trade is usually a clear win.
Structuring without a framework
Use plain, semantic HTML files organized by URL structure — a folder per route matching your desired path (/insights/article-slug/index.html). Share a header, footer, and navigation by including a small vanilla JavaScript snippet that injects them into every page at load time, rather than duplicating markup everywhere — this gets you most of the maintenance benefit of componentization without a build step.
Handling repeated content without a templating engine
For content that changes across many pages but shares a common shape — an article template, a card component — write a small script (in Node, at authoring time, not runtime) that generates the static HTML from data, then commit the generated output. This is effectively "build time" without a full bundler — you get consistent, DRY-authored templates while shipping plain static files with zero client-side generation cost.
Content management without a CMS
A lightweight admin panel (even a simple server-side script) can write directly to the static HTML files or a small database, regenerating pages on publish — this gives non-technical users an editing interface without requiring a full CMS or a build pipeline at deploy time. The key property to preserve: the published output is still plain static HTML that needs no build step to serve.
Deployment is trivially simple
A zero-build static site deploys by copying files to a server — FTP, rsync, or a simple CI step that syncs changed files. There's no build to fail, no dependency to go stale, no bundler configuration to maintain. This dramatically reduces the number of things that can break a deploy compared to a framework-based pipeline.
When to graduate to a build step
The signal to add tooling is a genuine need — client-side interactivity complex enough that vanilla JavaScript becomes hard to maintain, or a component count large enough that manual consistency starts failing. Until that need is real and specific, adding a build step preemptively usually adds more maintenance cost than it saves.
A practical minimal stack
Plain HTML/CSS/JS, a small script for shared header/footer injection, a lightweight generator script (in Node or any language) for repeated templates run at authoring time, and a simple deploy step that copies files. This covers the vast majority of content-driven sites without ever introducing a bundler.
Keep reading: Why Your Site Doesn't Need a Framework.
Common questions
Is a zero-build static site slower than a framework-based one?
Usually the opposite — without a JavaScript framework bundle to download and hydrate, a static HTML page often shows content faster, especially on slower connections and devices.
Can I still have reusable components without a build step?
Yes — a small vanilla JavaScript snippet that injects shared markup (header, footer, nav) at load time gets most of the maintenance benefit, and a generator script run at authoring time (not runtime) handles more complex repeated templates.
When should I add a build step to a static site?
When there's a genuine, specific need — complex client-side interactivity or a component count large enough that manual consistency becomes error-prone — not preemptively.