The Unreasonable Effectiveness of Simple Static Site Generators in 2026

I still see teams reach for Next.js to host a five-page documentation site. Five pages. That's a <nav> with five links and maybe forty kilobytes of text. And they're shipping a runtime that parses React on every request, hydrates a client bundle, and needs a build pipeline that takes longer than reading the docs. The words are not wrong, exactly. They are worse than wrong: they are frictionless. Nothing sticks, and the page still takes 1.4 seconds to load on a 4G connection from Bangsar.

What's actually wrong with the modern JAMstack for small sites?

The problem isn't that frameworks are bad. It's that they solve problems you don't have. A static site generator (SSG) reads Markdown, applies a template, writes HTML files. That's it. A modern framework does that, plus a client-side router, a data fetching layer, code splitting, and a hydration step that makes the page interactive. For a blog or docs, none of that is needed. You're adding complexity that doesn't exist in the output.

I've rebuilt internal dashboards where the old version was a Python script writing HTML to a folder. No build step, no Node modules, no lockfile. The new version has a CI pipeline that takes four minutes to build and deploy. The old version took eleven seconds. The old version also had zero security advisories because there were no dependencies to update. That's not a hypothetical. I've seen that tradeoff made, and it's usually made because the developer wants to learn a framework, not because the project needs it.

The tell is not vocabulary or even grammar. The tell is the shape of claims. A modern stack will say it's "scalable" because it has static generation. But a makefile can generate ten thousand pages in under a second. A framework will say it's "maintainable" because components are reusable. But a plain HTML template with one include file has been maintainable since 1995. The specific mechanism that makes a simple SSG effective is the absence of a runtime. There is nothing to patch, nothing to cache, nothing to break when a CDN edge node decides to run your code.

When does a simple SSG actually win?

Documentation. Most docs are read, not interacted with. A search box can be a static JSON index and a few lines of vanilla JS. No framework needed. I host all my project docs as plain HTML generated from Markdown. For example, the Travel Booking Platform docs are just a handful of pages. No client-side routing, no API calls. Pages load in under 100ms on a cached CDN edge. The whole site is a folder I can zip and email to a client.

Blogs. A blog post is text. It's not a real-time dashboard. The comment section? That's a separate problem, and you can solve it with a form that posts to a serverless function or a third-party service. You don't need to hydrate the entire page with React to handle a textarea.

Internal tools. This is where the temptation is strongest. You have a script that generates a report. You want to show it in a browser. A simple script that writes an HTML table is enough. But then someone adds a dropdown filter, and suddenly you're importing Vue and writing a whole SPA. I've seen internal dashboards with four hundred npm packages to display a table that updates once a day. The old version was a cron job and a static file.

The moment you add a framework to an internal tool, you inherit the entire JavaScript ecosystem: version upgrades, breaking changes, build times, and the need for a frontend developer to maintain the code. If the tool is used by five people in your company, that's a poor tradeoff. A simple SSG or even just a script writing HTML is better.

What does a simple SSG actually look like in 2026?

It's not complicated. You have Markdown files. You have a template. You have a script that combines them. That script can be a makefile:

build:
	for file in posts/*.md; do \
		pandoc $$file -o output/$$(basename $$file .md).html --template template.html; \
	done

That's it. Pandoc handles the conversion. No Node, no bundler, no framework. If you want a bit more structure, you can use a static site generator like Hugo or Zola, but the principle is the same: they output plain HTML files. Hugo, for example, builds a thousand-page site in milliseconds. Zola is even faster. Both are single binaries with no runtime dependencies.

The key is not the tool. It's the discipline to keep the output static. No client-side routing, no dynamic data fetching, no heavy JavaScript. If you need interactivity, add it with a <script> tag and keep it small. A search box can be a few lines of vanilla JS that filters a precomputed JSON index. A form can post to a serverless function. That's enough for 90% of use cases.

When should you actually resist the urge to add a JavaScript framework?

When the content changes infrequently. If you update docs once a week, a build step that takes four minutes is wasted time. A makefile that runs in a second is fine.

When the site is read-only. Blogs, docs, landing pages. No user-generated content, no real-time updates. Static is the default.

When you don't have a dedicated frontend team. If you're a backend engineer and the site is a side project, don't add a framework you'll have to maintain. A simple SSG is easier to reason about.

When your users are on slow connections. A static HTML file is 20KB. A React app is 200KB before you load any content. That matters on a 3G connection in rural Malaysia or a crowded conference Wi-Fi.

When security matters. A static site has no server-side code, no database, no injection surface. The only risk is the CDN or web server misconfiguration, and that's a solved problem. A framework adds a whole new class of vulnerabilities.

I've been on both sides. I've built JomJual, a marketplace platform, with a proper frontend framework because it needs real-time interactions and user-generated content. But for documentation and blogs, I use a simple SSG. The distinction is not about purity. It's about recognizing what the project actually needs.

But what about DX, hydration, and the things frameworks do well?

Frameworks have their place. If you're building an application with complex state, client-side routing, and real-time data, use a framework. But a documentation site is not an application. It's a collection of text files rendered to HTML. The best developer experience for that is the simplest one: write Markdown, run a command, see the output.

The JAMstack promised to make websites faster and more secure. It delivered on that promise for some sites, but it also introduced a layer of complexity that often isn't justified. A plain static site is faster to build, easier to deploy, and trivially secure. If you can achieve the same output with a makefile, you should.

Don't let the hype cycle convince you that a simple solution is outdated. Sometimes the simplest tool is the right tool, not because it's retro, but because it solves the problem without adding new ones. That's the unreasonable effectiveness of simple static site generators in 2026.