My blog began as a blosxom (Perl) site running on a VPS. In 2011 I\nmoved to the new GitHub Pages, with the site generated statically\nby Jekyll (Ruby) on a GitHub server. It was a no-brainer: easier,\nfaster, and cheaper, better in every way. After 15 years of Jekyll, this\nweek I replaced it with a new, custom-built static site generator,\ndubbed ssg, in “C with templates” C++20. The ~8KLoC source closely\nfollows my personal coding style including templated arenas and\nslices, zero dependencies, and a libc-free core. It’s wicked fast,\nand a complete, cold generation of my blog takes 150ms on my MacBook. That\nis, it’s done before Ruby would even reach Jekyll’s entry point. It’s a\nbeen a great, real-world demonstration of the effectiveness of my coding\nphilosophy.
\nLook around and you’ll find almost nothing visually changed. Outside of\nsyntax highlighting, the HTML is semantically identical. I did not try to\nmatch Rouge’s syntax highlighting, just its CSS selectors so that I could\nuse my style sheet unmodified. With that in my own hands, I now get syntax\nhighlighting that better suits my needs, some Rouge bugs gone and support\nfor new languages, particularly assembly (WAT, AT&T, Aarch64)\nand QBasic.
\nBecause ssg only supports my site, and its source lives along side it, I don’t need a template system, i.e. Liquid. I can modify the C++ source as needed. So the upgrade was three steps: (1) fix 19 years of accumulated site bugs that Jekyll quietly tolerated, (2) add the new generator, (3) delete Liquid templates and pre-generated tag pages (now dynamically generated, with preservation of original feed UUIDs). Jekyll and ssg both work simultaneously at step #2, allowing side-by-side comparisons from the same site source. This is where most of the time was spent. Dropping templates means performance comparisons with Jekyll are unfair, as Jekyll is solving a different problem. (But I think it’s fair to speculate that ssg with Liquid templates would still smoke Jekyll!)
\nHistorically, Jekyll was a dreadfully slow site generator until the 4.0.0\nrelease in August 2019. While performance is mostly resolved, I still\nhave ingrained habits to work around it. The final Jekyll version of my\nsite took ~2 seconds on the same MacBook. Not too bad, and it has a fast\n--incremental mode, though it’s always been a little buggy, not quite\nmatching a full generation.
No, the pain point for Jekyll is not performance but deployment.\nEspecially when trying to match the GitHub Pages configuration. The Ruby\ndeployment situation remains just awful. I never once generated my blog on\nWindows, in part to avoid jumping through hoops to set up Jekyll. Last\nyear I switched to macOS (from Linux) as my primary, personal development\nenvironment. This meant setting up Jekyll on macOS, and the situation is\nfarcical. The Ruby community ought to feel embarrassed about this.\nThe source lines delay shell startup by 60ms, and I’m unwilling to bear\nthat cost in nearly every shell just to occasionally run Jekyll, plus\nenvironment litter that may interfere with other tools. So I needed to\nremember to enter an isolated Jekyll environment, and to tell AIs to use\nif they needed Jekyll.
With ssg you just need a C++ compiler. As native application, you don’t\nneed any development tools once it’s built of course, and the compiled\nprogram is a single file that could be copied to another system and run\nas-is. It’s a unity build — I did say it closely follows my personal style\n— so you don’t even need a build system. On w64devkit that looks like:
\n$ cc -nostartfiles -o _ssg/ssg.exe _ssg/main_windows.cppcc (or gcc) works because the compiler driver knows to invoke the C++\nfront-end for this input. It doesn’t use the C++ standard library, so the\nlinker doesn’t need -lstdc++. -O0 builds like this run at about half\nspeed compared to optimized builds, and -O1 is sufficient to get all the\ncompiler optimization benefits. Normally debug builds would be around 10x\nslower, but fast debug builds is par for the course for my style. While\nyou don’t need it, there is a CMake build, but that’s really just for\ndriving the test suite.
Both build and tool work on Windows XP, too, so for the first time ever I\ncould fully compose a post on my old XP laptop if I wished.
\nOn the MacBook this -O0 build takes ~150ms — quite good for 8,372 lines\nof code. A cold site generation takes this build ~260ms. That’s so fast I\ncould very well re-compile the generator each time I regenerate the site.\nIndeed that’s exactly how it works in the GitHub Actions pipeline. Overall\nit’s faster to use a debug build than a release build. The cache is too\nslow and unreliable for release builds to make sense in Actions.
$ cc -std=c++20 -o _ssg/ssg _ssg/main_posix.cpp # macOSFor the first decade of GitHub Pages, Jekyll was the only option. It ran opaquely in the somewhere at GitHub with a pass/fail result, requiring a local matching configuration for debugging. When they introduced GitHub Actions in 2018, Jekyll was a pre-configured, transparent pipeline, and it became possible to run whatever generator you wanted in its place. I’m finally taking advantage of that, and I still get automatic page builds on push like I had with Jekyll. It’s now slightly faster — Actions overhead dominates either way — despite compiling an entire C++ program each run.
\nI do not plan to divorce my generator from my blog, so ssg will not become a general-purpose static site generator. Its whole purpose is to serve this one particular need. You’re free to fork it and use it as a basis for your own needs, of course. This sort of bespoke, written-to-order software is likely the future of software. Why bother with one-site-fits-all when an exactly-sized solution has the same cost?
\nI’ve been thinking about this project for years. Had I written it in the\n2023–2025 time frame, I estimate ~2–4 weeks, using u-config (3KLoC,\nlower complexity) as a measuring stick. Here in 2026, it took about\n~20 minutes to write my detailed prompt, then ~2 hours for Opus 5.5 in\nClaude Desktop to produce ssg in essentially its current form, bug-free as\nfar as I can tell, including an untested Win32 platform layer (written\non the MacBook, no Wine). I’ve spent more time on this article than I did\non the new generator.
\nI spent a couple more hours looking it over, shocked at Opus 5.5 perfectly\nmatching my personal style. It really does look like I wrote ssg. Reading\nit is uncanny, like seeing someone reproduce my own handwriting such that\nI couldn’t distinguish it. During this review I realized we ought to use\ndebug builds in the pipeline, so we had one follow-up on the hot spot in\ndebug builds. Then I noticed the Win32 platform layer generated an\nempty site on Windows XP, another small followup. (XP wasn’t in\nmy original prompt, so I don’t count this as a bug.) That was it.
\nTwo years ago I said that AI-generated code was too poor to be\npractical. That changed by the end of 2025. In earlier 2026 projects I\ntried to get AI to write C following my style, using my writing on the\nsubject as a guide, but they’d just recreate the no-good standard\nlibrary from scratch then flub arena allocation. Ask those models\nto write conventional C and you get the usual, error-prone C you’ll find\nanywhere. So I settled on conventional C++ as Good Enough. I could\ncomplete projects ~20x faster, but with results not quite as good as I’d\nhave done myself. A reasonable trade-off.
\nOpus 5.5 released on September 22nd. It is the first model I’ve used that\nactually understands my coding philosophy and writes C at least as well\nas me. This was the ideal project for this test, as my core writing on\nthis subject was naturally in context, but it generalizes when referencing\nmy writing and prior work. As of two weeks ago I can now have my cake and\neat it, too. No more trade-offs.
\nIf you’d like to get similar C-with-templates results on your own project, cite these four articles in your prompt:
\nAs well as perhaps my relevant, similar projects. All the frontier models know about me personally and are familiar with my work, so invoking my name may be enough. If the model is as good as Opus 5.5, you might get an accurate impression of how I would have done your project.
","headings":[{"level":1,"text":"A new, bespoke static site generator to replace Jekyll","id":"a-new-bespoke-static-site-generator-to-replace-jekyll"},{"level":3,"text":"A first for generative AI","id":"a-first-for-generative-ai"}]}}