TL;DR: I built a Cloudflare Workers-based Server-Side Includes (SSI) system that lets you use <include> like it’s 2002, but supercharged for 2025. No build steps, no React, no YAML – just plain HTML with dynamic content. This very page is the demo. Check out the source code here: GitHub Repo.
I was setting up a personal blog recently, and the process quickly spiraled into a ridiculous setup ritual. Pick a static site generator, figure out where to host, configure deployment, wrangle CI/CD pipelines, and make peace with YAML. For what? A simple blog? Am I deploying the next Mars rover mission, or do I just want to write some words on the internet? What if I just want to write HTML and push it somewhere without jumping through hoops? Ok, maybe FTP isn’t cool anymore, but come on – committing to a Git repo is even easier. git commit && git push beats dragging and dropping files in some clunky dashboard any day of the week. And yet, even that wasn’t enough.
Back in the early 2000s, I worked at a local web studio. My first real project? A massive product catalog for a local dessert manufacturer – 50 pages, 10 items per page, all manually coded. The studio didn’t have a CMS, just some Perl scripts for contact forms and a guestbook (the true web 1.0 experience). Some pages were even in ASP. It was painful. Late nights of manually copy-pasting HTML, making sure navigation stayed consistent across dozens of files. Then, one day, someone in my local IRC channel changed my life: "Go buy a book about Apache and learn SSI." And just like that, everything got simpler.
Server-Side Includes (SSI) were magic. One line:
<!--#include virtual="/menu.html" -->
And boom – shared content across all pages. No PHP, no CMS bloat, no build step. It just worked. We rolled SSI into several projects, and suddenly, managing HTML didn’t suck as much anymore. But of course, time marched on, and now? Try finding a serverless provider that supports SSI today. Good luck. Mention dynamic HTML in 2025, and someone will hand you a 300-page Next.js manual or suggest setting up GraphQL over Redis Pub/Sub. All I wanted was <include> – not a PhD in overengineering. Even Nginx needs to be compiled with the SSI module, and who’s got time for that? I’d rather spend my time making sure my coffee doesn’t go cold before I drink it. Honestly, I don’t even remember people using SSI back then either.
So I decided to use plain HTML for my blog. But I wasn't going to deal with the same old headaches – updating navigation and pagination manually across multiple pages like it’s 2002. I considered Cloudflare Pages – great for hosting, but not for solving my real problem. Then it hit me: Cloudflare Workers! If I can intercept requests at the edge, why not bring back includes – like it’s 2002, but supercharged for 2025? No build step. No complex CI/CD pipelines. No YAML-induced headaches. Just HTML that works.
It would be so nice if HTML could be dynamic on the server. But wait – doesn’t that mean I need a runtime? Well, sure. And if I wanted one, PHP has been around forever. But PHP and I have a complicated relationship. It’s like an old college friend who keeps inviting me to multi-level marketing schemes. I respect it, but I’m not getting involved. Even if I could stomach it, I'd still have to configure a web server with FCGI, and nobody wants that. Do any of the serverless providers even support PHP these days? Not really. Maybe some forgotten shared hosting service I haven’t touched in 20 years, and I’m not about to go on a nostalgia trip for cPanel and PHPMyAdmin. So I rolled my own.
I built a small demo website using Cloudflare Workers to process SSI-like includes. In fact, this very website – ssi.artps.org – is built using this approach. You can check out the source code in the GitHub repository: GitHub Repo.
Now, full disclosure: this implementation doesn't support nested or deep includes. I didn’t need them, and honestly, I spent about four hours on this – taking breaks for coffee and push-ups. Priorities, you know?
But let’s be clear – this is not your granddad’s SSI. Traditional Server-Side Includes were basic, pulling in raw HTML with zero flexibility. I took that old concept and gave it a 2025 glow-up, using a slots-based approach. Instead of static includes, this method allows dynamic content injection in a structured way, making it feel more like a lightweight templating system rather than just a dumb file stitcher. If you've used Vue, Svelte, or Phoenix LiveView, you'll recognize the slots pattern – self-contained, declarative, and easy to reason about.
Here's how it works:
<include path="/layout.html">
<fill slot="title">
<title>Welcome to My Site</title>
</fill>
<fill slot="header">
<h1>Main Page</h1>
</fill>
<fill slot="content">
<p>This is the main content.</p>
</fill>
</include>
And then the layout:
<html>
<head>
<slot name="title">Default Title</slot>
</head>
<body>
<header>
<slot name="header">Default Header</slot>
</header>
<main>
<slot name="content">Default Content</slot>
</main>
</body>
</html>
Not everything needs to be a React app. Seriously, I don’t need a virtual DOM just to display a paragraph of text. Maybe simple tools like this, built on web primitives, are still good enough for some cases. The web was supposed to be simple. With Cloudflare Workers, I’m bringing back the good parts – fast, server-rendered, maintainable pages without the headaches of modern frontend tooling. No Terraform. No pipelines. No YAML-induced suffering.
Just includes, like it’s 2002 again.
But now that I’ve built this, I can’t help but wonder: What if we take this further?
This whole experience made me realize that a real server-side XML/HTML-powered runtime could be genuinely useful. Something lightweight, declarative, and structured – pulling data from databases, handling form submissions, and writing structured output, all without the bloat of modern frameworks. Something that doesn’t just handle includes but also integrates with databases as data sources, processes form submissions, and provides structured data sinks for writes. Basically, a proper runtime – just without the baggage of bloated frameworks. The simplicity of working this way was refreshing, and I might just explore turning it into something more serious.
If you want to take it further with me, let's build it together – contact me at [email protected]. I'm also actively looking for a job right now – whether it's pushing the boundaries of server-side rendering, hacking on edge computing, or solving deeply technical problems. If you need someone who thrives on simplifying complexity, loves building pragmatic solutions, and has a super crazy sick brain, then let's talk. Reach out at [email protected] or connect on Linkedin.