In January 2014, I wrote a blog post called "Pairing Static Websites with CMS." In it, I described what I saw as a coming revolution: the marriage of static file delivery — fast, secure, simple — with the content management capabilities that organizations need to actually run a website.
I called it "the new Reese's candy of web technologies." I'll admit the metaphor was a stretch. But the prediction wasn't.
Here's what I wrote:
"Call me crazy, but once existing attempts at making this happen mature a little, I believe we will see widespread adoption of the technique."
Two years later, Netlify's Mathias Biilmann coined the term JAMstack — JavaScript, APIs, and Markup — to describe exactly this approach. The idea that had been simmering at the margins went mainstream. And over the decade that followed, it didn't just gain adoption. It became the dominant way modern websites get built.
What I got right
The core argument of that 2014 post was simple: traditional CMS platforms like Drupal, WordPress, and Joomla tried to do everything — content management, page rendering, user authentication, URL handling — all on a single server, for every single page request. This made them slow and vulnerable. Static sites, on the other hand, were fast and secure but offered no way for non-technical people to manage content.
The solution, I argued, was to separate the two concerns: use a CMS to manage content, but serve the website as pre-built static files. The CMS stays behind the scenes. The public-facing site is just HTML, CSS, and JavaScript — fast, secure, and nearly unhackable.
That's precisely what happened. Today the ecosystem looks like this:
Static site generators and frameworks like Astro, Next.js, Nuxt, Hugo, and Eleventy can build blazing-fast websites from content stored anywhere. They pre-render pages at build time, producing the exact kind of static output I was describing — but with far more sophistication than I could have imagined.
Headless CMS platforms like Sanity, Contentful, Strapi, and Prismic provide the content management layer without coupling it to a specific front-end. Content editors get a clean interface for managing their site. Developers get the freedom to build the front end however they want. The two concerns are fully decoupled — which is a fancy way of saying exactly what I proposed in 2014.
Edge hosting platforms like Vercel, Netlify, and Cloudflare Pages deploy static assets to servers all over the world, serving pages from whatever location is closest to the visitor. The performance gains I was talking about in 2014? They got multiplied by global distribution.
What I didn't see coming
I'll take credit for the prediction, but I didn't foresee how far the concept would evolve.
I was thinking about extracting static HTML from a traditional CMS — essentially using WordPress or Drupal as a back end and scraping the output into flat files. That was crude, and it's not really how things played out. What happened instead was more elegant: entirely new categories of tools emerged, purpose-built for this decoupled approach. The CMS and the website became separate applications that talk to each other through APIs.
I also didn't anticipate how the developer experience would improve. Modern frameworks don't just produce static files — they offer component-based architectures, server-side rendering when you need it, client-side interactivity where it makes sense, and build processes that handle image optimization, code splitting, and performance tuning automatically. The "static" site of 2026 is a far cry from the flat HTML files I was picturing.
And I certainly didn't predict that AI would enter the picture. But here we are — and the combination of modern static frameworks with AI-powered development has made it possible to build sophisticated, high-performance websites at a pace and cost that would have been unthinkable even two years ago. But that's a topic for another post.
Why this still matters
If you're running an organization and your website is built on a traditional CMS — WordPress, Drupal, or something similar — the problems I described in 2014 haven't gone away. They've gotten worse. Security vulnerabilities in popular CMS platforms are more aggressively exploited than ever. The performance penalty of server-rendered pages now directly impacts your search rankings. And the cost of maintaining, patching, and hosting a traditional CMS stack keeps climbing.
The alternative isn't theoretical anymore. It's proven, it's mature, and it's how most high-performance websites are built today. The question for organizations still running legacy CMS platforms isn't whether to make the shift. It's when.
The original post
For the curious, here's what I wrote in 2014 — unedited, metaphors and all.
I got the broad strokes right. The details played out differently — and better — than I imagined. That's usually how it goes with technology: the direction is predictable, the specifics aren't.
The one thing I'm sure of is that twelve years from now, I hope I'll be writing a similar post about whatever comes next. The web never sits still. The best you can do is pay attention and place your bets early.