In the process of setting up this blog, I developed my own blogging engine, atop the brand-new, just-released Next.js 13. I was sort of running alongside the Next 13 development effort, reliant on nightly builds.

After an intense refactor, I’ve produced an early alpha of the underlying engine, ‘sbstr8.’ And of course, I put it up on GitHub, and made a website for it.

This is a server-component-first, Markdown-centric blog written in React. It was written because, despite the plethora of blogging engine options in 2023, I couldn’t find anything that captured the range, power and simplicity I was craving. You don’t need to reinvent the wheel, but sometimes you do need to iterate on it.

First, let’s talk requirements:

I’m a coder, writer and creative, and I am always running into problems integrating these traits. For example, I do a lot of work in React; but when I would go to write, I’d pick up a tool like Medium.com or WordPress. (Or — and let us be honest here — just as often, Facebook or Twitter.) Nary a one of these platforms would permit me to slide back and forth between words for humans and words for machines.

In a sense, the underlying platform of blogging over the past twenty years has not mattered as much as the idea of a blog, which has remained rigid affair of text, with a smattering of images, and, maybe, a few awkwardly-iframed videos. This makes as much sense to me as posting an A4-formatted PDF: just like page breaks in an environment where paper is a distant memory, the rules of what constitutes a blog post are not only arbitrary (which would be fine,) but are motivated by the constraints of a medium that was long ago virtualized away, in the endless, ongoing cycle of reic eutrophication called “progress”. A blog post today can and should include not just ‘rich media elements’ as foreign objects lodged in a body of text, but should itself be code. A blog post should be a kind of app.

Moreover, the app should not have dependencies within the walled gardens of others. If there’s anything that the past few years have taught us, it’s that donating your content to a platform that someone else owns is basically to work for them for free. No, worse than free! A volunteer gardener is not the subject of constant surveillance and advertisement.

If you do not own the platform, it does not matter if the platform today is run by literal saints. Money can and will purchase that platform whenever it likes, and that money is often, but not always, in the hands of people with odious politics, aesthetics and ethics. Not owning your platform means you don’t own your words, and that means you are vulnerable to have your entire life, livelihood and audience taken from you at any time, for any reason, especially political ones. As everyone on Twitter has recently learned.

So: with this in mind, Medium, Substack and Ghost are all eliminated from the running, as in each case, there is an underlying power dynamic that would not favour me, should there be regime change.

That left me with options like Gatsby, WordPress, or Soupault.

Gatsby is probably the closest living relative to what I wanted to see in the world, being both React and GraphQL-based (as is sbstr8!) but it had some design decisions that I couldn’t agree with. Firstly, it explicitly limits itself to static site generation. This means that it’s not possible to produce an article-as-an-app. Because I use Next, I can produce content that’s rendered statically at first (for great SEO,) but also contains client-side React elements that come alive when the page is loaded. A sbstr8 story can have its own endpoints; it can have live client-side React elements; it can seamlessly combine video, text, animation, sound, anything. By contrast, in Gatsby, it’s workaround city.

That said, I have enormous respect and awe for Gatsby; if it had just been a little bit different, I would have merrily gone down that road. And I do look to Gatsby for inspiration and emulation. There are many things about Gatsby that I admire.

Hugo is another static-site generator, this time in Go. Most of my feelings about Gatsby also apply to Hugo, but harder. While build times are undoubtedly fast, Hugo is even more wedded to the idea of serving up static assets, but this time, without the expressive power of either GraphQL or React. Hugo is a formidable tool for generating static HTML, but nowhere near what I wanted for blending modes of creation (coding, writing, etc.)

Soupault is what I used the for the first version of my blog, and, like Hugo and Gatsby, it’s a static-site generator. Soupault is probably the most austere of the three, yet also the most elegant in its architecture and execution. If my goal was to produce a basic 2010 website quickly and repeatedly, I’d grab Soupault again. The downside, though, is again what it asks you to do without.

WordPress is a tool I have loved and admired a lot over the years, was never a serious contender for my 2023 ambitions. Mostly I see the current stylistic/genre status-quo of what is called “blogging” as, in large part, having been determined by the technical limitations of WordPress. For it was WordPress that separated content (which was stored in an SQL database) from code (those .php files), and this turn was, I believe, what set in relative stone the core properties both of a blog and of a blog-post.

Indeed it was as a reaction against WordPress that Gatsby and Hugo were created, the insight being: if you’re only serving text and images, why bother shoveling it into and out of a database at request-time? Why not just generate it once, and have done?

This, I think, grasps the wrong end of the stick: the question shouldn’t be “If we’re only using text and images, why bother with dynamic rendering?”, it’s “Why are we still only using static text and images?”

And this, specifically this, is the question I want to answer with sbstr8, and the answer is: “legacy reasons only.” A sbstr8 site is mostly just a Next 13 site, with simple data model for managing chronological posts, which, in turn, can contain arbitrary content, which may execute on either the server or client in real time. I’ve done my best to make it themable and pluggable, but mostly I want it to stay out of your way. If you’re a writer for the website, you’re also a coder of the website, and vice versa.

Finally, the automatically-built docker images that sbstr8 already provides will soon be complemented by a basic set of Kubernetes spec files, that should make deploying and managing your website convenient and easy. The idea is that by shifting a good chunk of the hard work of handling deployments and load management onto K8S, I can make it simple for people to throw up and tear down sbstr8 sites, without the need for a dedicated provider, and moreover, mitigate some of the traditional advantages of hosting content on a CMS like WordPress.

This means that a site created with sbstr8 can be instantly deployed on any kubernetes cluster — which in 2023 means, you can deploy cheaply to the cloud of your choice, or even your own hardware. Sbstr8 is Bring-Your-Own-Cloud (BYOC). This is especially important for those of us at the margins, who need to worry about censorship, doxxing, and denial-of-service attacks. It shouldn’t matter what a billionaire thinks of you and your people. Sbstr8 enables actual free speech, rather than the cartoon version touted by the current crop of moneyed conventionalists, which mostly seems to be about silencing opponents in the name of ‘balance’.

A sbstr8 blog should be effortlessly planet-scale. I’d like there to be no better platform to engage audiences than sbstr8. That’s where we’re going.