There’s a certain type of developer who hears “static site generator” and thinks: oh, so you’re doing things the old way. As if complexity were always progress.
What We Added
The web of 2010 was already powerful enough for most things people wanted to build. We added: real-time everything, client-side rendering, megabyte JS bundles, edge functions, CDN configuration, hydration strategies, build pipelines with fifteen steps.
Some of this was necessary. Most of it was solving problems created by the previous solution.
What Static Gives Back
A Hugo site builds to a folder of HTML files. That’s it. You can put it on any server, any CDN, an S3 bucket, a Raspberry Pi. It loads fast because there’s nothing to compute. It’s secure because there’s no runtime to exploit.
$ hugo build
| EN
-------------------+-----
Pages | 47
Paginator pages | 0
Non-page files | 3
Static files | 12
Processed images | 0
Aliases | 0
Cleaned | 0
Total in 312 ms
312 milliseconds to build 47 pages. No containers, no cold starts, no hydration.
The Right Tool
Static isn’t the answer to everything. If you need real-time data, user accounts, or complex interactivity — you need a server. But a blog? A portfolio? Documentation? A marketing site?
The answer is almost always static. We just forgot it for a while.
Complexity should be earned, not assumed.