Minimum Viable Blog
176 comments
·May 3, 2025Tallain
lolinder
Wordpress in 2025 has a very dangerous pair of traits:
* It and all its plugins must be kept up to date or else you will be compromised.
* The BDFL is a maniac who is happy to block access to deliver or receive security updates for petty personal reasons.
With a static site there are no security vulnerabilities to patch, so it doesn't matter if the SSG project totally implodes because the maintainer goes crazy. With WordPress it matters a lot.
nedt
Use wordpress headless and protected the backend so it can't be accessed publicly. Then you don't have to care so much about keeping it up to date.
Tallain
Had to look up what "BDFL" meant.
Even if the dude tries to paint the internet with Wordpress's brains, I'm confident I will have time (and the impetus, finally) to find an acceptable alternative for my workflow. I'm open to suggestions.
Also, as I mentioned to a sibling response, the upkeep really is not that much work. It's a personal blog and takes a grand total of three (maybe four) clicks to update every once in a while.
RainyDayTmrw
Maybe not so benevolent after all.
egypturnash
It keeps itself up to date.
lolinder
Only as long as Matt deigns to allow your server to access his servers and deigns to allow the plugin authors who you depend on to log in to his servers.
WordPress has no governance, it just has Matt, and wo betide anyone who ticks him off (or who relies on any developers who tick him off).
mbirth
Same here. Started ages ago with DokuWiki and then decided to try GitHub Pages. Transferred everything over, but then wanted some kind of search. So, I’ve implemented a custom Google search. Wanted some way for visitors to leave comments, so added Disqus. And in the end it was a potpourri of different services and a whole lot of JavaScript.
A few years ago I wanted to own my data again and not depend on external services, so exported the Disqus comments and after playing around with Serendipity ended up with Wordpress.
Was able to import the comments and the Markdown pages and there are even plugins to make it publish everything in the Fediverse. Made it all work using SQLite and enabled auto-updates. It’s basically maintenance-free.
mikae1
Blog spam? :) The URL is https://rakhim.org/honestly-undefined/19/
Tallain
Thanks for the link :) I do think the blog I linked makes many of the same points I tried to make, so not really spam as it has actual content.
atoav
I agree, but I think wordpress is overkill in 95% of cases.
Why? Because it takes too much maintenance (keep it up to date ornbecome part of a botnet) for features you probably don't need. A static site generator is totally fine for most blogs and if it needs maintenance it is at a time of your own choice.
Tallain
I disagree, it's not overkill unless you make it overkill.
My update process is:
- Click a button to back up
- Click a button to update everything
- Open my blog to make sure it still looks normal
Definitely not onerous. To be fair I don't use many plugins, and my theme is very simple. I don't think a plain old blog doesn't need many plugins.
Sometimes I take a break from blogging. I don't want to have to read documentation on how my SSG works (either my own docs or docs on some website) to remember the script to generate the updates, or worry about deploying changes, or fiddling with updates that break my scripts, or anything like that. I do stuff like this for my day job.
I like my blogging experience to be focused on a single thing: writing.
atoav
You are running one of the most popoular PHP programs exposed to the internet. So on top of just writing you should probably schedule your regular check for CVEs and patches. And you should do this even if you're not blogging or on vacation.
Not a thing you'de need to do with a static website. If you're like: "Hey, I am not doing it right now and I am fine", consider that your warning. I have been hosting wordpress instances since wordpress existed and I know how things can go wrong with them.
pclmulqdq
I ran into the maintenance load of an SSG for my blog, and only just now switched themes over this rather than fixing the old theme (which had several customizations). In that theme swap, I think I lost all the productivity I gained from using the SSG over raw HTML.
tlavoie
One other productivity gain though is that if you end up switching SSG engines entirely, you still have your source files. Those could easily work with the next one, or at least leverage trying others out. If everything is baked into rendered HTML, it will be much more work.
XorNot
I've been pretty happy with nikola[1]
The only thing I really wanted was 1 command to publish (which is does great) and an easy way to drag and drop images into posts (which I can do via the publish jupyter notebook function).
What I absolutely did not want was anything where "send HTML to clients" created any sort of overhead like a database.
Spunkie
I don't think I could ever go back to SSR like WordPress. My only real concern with SSG is if the build will work, and even when it doesn't it's never an emergency.
Whereas the concerns for something like WordPress is
1. Has our website been hacked and publicly defaced?
2. Has our website been silently hacked and is being used to secretly distributing malware or worse, aka the FBI randomly shows up at your business.
3. Will updating one random plugin nuke your entire live site, resulting in multiple sleepless nights? Will not updating it cause your site to get hacked also resulting in sleepless nights?
4. Or better yet something in your underlying environment changes and nukes your site, usually in the middle of a weekend out with your family, and your hosting provider pinky swears they didn't change anything. So you spend your whole weekend investigating just to find out your provider did change something, usually something stupid too.
5. Considering all the above your off-site backup solution is vital so better keep that maintained and thoroughly tested as well.
6. Plus a thousand other reasons to waste time, worry, and lose sleep.
Tallain
We're talking about blogging here, not business-critical website infrastructure. If my blog went down I wouldn't lose a sleepless night over it. I'd figure it out later.
If I were choosing a CMS or tech stack for a critical piece of infrastructure my requirements would be different and I might find some other tool.
Also, if all these were so much concern, I doubt so much of the web would run on Wordpress. Yes, you need to keep your install and plugins up to date. But you need to keep your toolchain up to date no matter what you use. Risk of breakage on update is a thing everywhere, not just Wordpress. I'm by no means a Wordpress fan, but it really is not as bad as it's painted.
Spunkie
> Also, if all these were so much concern, I doubt so much of the web would run on Wordpress.
I used to run a company that all we did was wordpress, joomla, and drupal maintenance, performance optimization, and hack recovery. It very much was and mostly continues to be that bad.
> Risk of breakage on update is a thing everywhere, not just Wordpress.
Ya the issue with server side rendering is that your live environment is made of up dozens to hundreds of difference software stacked on top of each other and they all pretty much need to work perfectly to actually work and or not be vulnerable. And if you use something standard like cpanel to manage your environment, add another 1000 layers of complexity to the stack.
And lets not even go into all the work it takes to have that environment have decent performance and run on reasonably priced hardware.
Where as my concerns for my SSG live environments basically amounts to, is the host publicly accessible? To be vulnerable you would need to do something very stupid like set file permissions to 777 or something.
lmm
> If my blog went down I wouldn't lose a sleepless night over it. I'd figure it out later.
And if your blog was serving malware, or really nasty porn, or taking part in a DDoS?
> Also, if all these were so much concern, I doubt so much of the web would run on Wordpress.
What is it that gives you that kind of faith in the industry's decision-making processes?
blogloglog
I think you're right. I stuck with manually writing raw HTML and it's fine, good even. I do have a python script that makes an RSS feed though, which was one more script than I wanted to write. WordPress would've saved me; unfortunately I already had a website so it was easier to add a blog there.
Tallain
For the rest of my website I also just write raw HTML / CSS, and JS when needed. It's all static content and little toys, so no RSS need. It's nice to keep things simple when you can.
p4bl0
Nice, but I feel like to be qualified as a blog it needs two little additional things:
1- Make sure to order post by date (most recent first) and to display that date somewhere. The date can simply be taken from the post file meta data (e.g. creation time) to keep things minimal.
2- An RSS feed of course! It should be quite easy to generate a minimal one with only links and titles based on the existing script and a minimal RSS template.
arccy
while rss is nice, it really shouldn't be required to be considered a blog.
being "followed" isn't always a good thing, it can create pressure to pander to your audience, the same thing that makes social media bad.
politelemon
> it can create pressure to pander to your audience
RSS creates no such pressure, as you needn't be aware of who/what is following you. It's a convenience function simply for the convenience, rather than as a form and measure of external validation.
arccy
the pressure is intrinsic from the knowledge that what you publish will now be displayed to a bunch of people, unfiltered by algorithms. do you really want to put out a post that you yourself might find useful, but might be considered shallow, low effort, repetitive, non unique by your readers, and a waste of their time?
the fact that people want to read every new thing being posted is external validation, rather than letting each piece stand alone by its merit.
pclmulqdq
Honestly, my blog's RSS feed subscribers are the best. They tell me when the feed breaks and demand literally nothing else. Once in a while, they will email if they like a post. That's it.
susam
> while rss is nice, it really shouldn't be required to be considered a blog.
I agree. A blog is literally a web log. A chronological sequence of posts published on the web. RSS is certainly helpful for syndication and distribution but I wouldn't consider it to be a defining part of what a web log is.
prox
Good point. My idealistic (realistic?) view of a web log is just a person typing out something unique that concerns that person and their view, life, or experiences.
As soon as you start catering to and fishing for views you lose that angle. Not a drama, but it’s already 99.5% of the internet.
Edit : I really like Marginalia search, for prioritizing non commercial content.
qudat
I agree but I could also imagine a world where a minimally viable blog is just an RSS feed.
citizenkeen
I don’t think RSS is required for soldering to be a blog, but I do think it’s required for it to be a viable one.
ostwilkens
That's fair!
1- I'm leaning towards an automatically generated file containing metadata, TOML or such
2- RSS is definitely coming, but is dependent on point 1 :-)
MarceColl
In the spirit of being minimally viable you could just have that in the filename and sort it before generating.
kryptiskt
Since RSS is a pretty simple format, it doesn't require any automation, just a little copy and paste. "Handwriting your RSS feed"[0] makes the case for doing it that way.
susam
Nice post. Thanks for sharing! I've always been fond of independent websites like this. My own website began in a similar fashion about 25 years ago - minimal, straightforward, and entirely built with ASP (now known as Classic ASP), simply because that was the only suitable technology I knew at the time. Of course, that's not the case anymore. These days, it runs as a statically generated site using Common Lisp [1], and I expect this to be my long-term setup.
Starting with a simple collection of pages was a great way to get started and set up a minimum viable website. But as time passed, I found myself needing a few more features. In order of priority, these included:
1. RSS feeds.
2. A blog listing page with posts ordered by date.
3. The ability to tag posts by topic and generate tag-based index pages.
4. Support for non-blog content, like tools, games, demos, etc. that can also be tagged and included in the RSS feed.
5. Support for comments without relying on third-party services.
With each new requirement, the source code gradually grew. What started as a few hundred lines has now expanded to around 1300 lines of Common Lisp. Not too big in the grand scheme of things but not exactly tiny either. Still, I try to resist the temptation to keep adding every shiny new idea that comes to mind. This remains a solo passion project. I want the entire source code to be something I can hold in my head at once. If I encounter a bug, I want it to be something I can reason about and fix in under 10 minutes, and so far, fortunately, that has been the case.
That said, new ideas are always tempting. Lately, I've been enticed by the idea of adding a blogroll that provides a list of posts from my favourite bloggers. This could replace my usual feed reader. I haven't had the time to implement it yet, but if a quiet weekend comes along, that might just be the next feature I work on. Of course, I remind myself not to let this project spiral out of control. I certainly don't want this to grow into something that can read my email.
brilee
Followed an identical path.
See my source code here:
https://github.com/brilee/modern-descartes-v2/blob/master/ma...
Includes:
1. RSS feed
2. Blog listing pages ordered by date
3. Tagging system
4. Localhost dev server with file-watching recompilation step.
llimllib
my path went similarly to yours, I've actually done it a couple of times.
Here's my current iteration, a python script that does manage to stay under 1000 lines: https://github.com/llimllib/obsidian_notes/blob/c93b9b5c46fe...
cosmicgadget
Exactly this. The ability to say, "I want to make this gadget" and then code it beats any wysiwyg.
I've done derived pages like post sets, indexes, and slideshows. Tag flavors for people and video games. Then just total control over how normal widgets like thumbnail galleries and pull quotes look and feel.
pacifika
I have built Lamb with a Flock feature where you syndicate feeds into your blog. Mainly as an alternative to multi-user. https://github.com/svandragt/lamb
Might be useful as a high level reference
ostwilkens
Thank you for the kind words. RSS and dates will definitely be needed! I can also see myself wanting to embed shaders and web games in the future... hopefully without increasing the complexity too much. I think your blog is perfect!
captn3m0
Something I’d like to see in browsers is native support for text/markdown and text/gemini.
If browsers can decide to render PDFs, surely a simple formatter and user-decidable stylesheets for markdown/gemini content can’t be that hard to ship.
As it stands you can write a text/plain blog but you will be hurt with SEO concerns since it isn’t really hypertext (maybe you could do some magic with link headers). Supporting other formats lowers the barrier to publishing in a neat manner and gives control back to users.
quectophoton
> Something I’d like to see in browsers is native support for text/markdown [...]
Sadly, I can see why it's unlikely that we'd get this.
First, browsers would need to agree on which flavor of Markdown, what extensions, and so on. After all, Markdown is almost like the CSV of text formats, with everyone doing their own thing ("almost" because you can still assume that some basic things work as you'd expect).
Only with that, I can already see the backlash no matter what they choose to do here. Too minimal, and get complains about not being too useful. Choose some extensions, get complains about being bloated. Make any attempt to have a thoughtful discussion about pros and cons (short and long term), get shut down with "don't let perfect be the enemy of good".
If we can get past that and finally agree on one specific set of features, there's still the question of whether it's actually worth it or not. The difference between Markdown and PDF is that reading PDFs directly in the browser is a common enough activity, but reading Markdown directly is only going to benefit the tiny audience of the small percentage of software devs that exist in the world, and maybe 5 weird people. Everyone else with a blog would just use the WYSIWYG from their CMS.
That's why I wouldn't be surprised if I don't see native Markdown rendering during my lifetime.
yellowapple
> First, browsers would need to agree on which flavor of Markdown, what extensions, and so on.
The correct answer is CommonMark. At that point extensions don't matter, since there's a common enough base that a Markdown document written with unsupported extensions in mind will still look decent. Reference code is abundant and permissively licensed. There's no good reason to pick any other flavor (and most other flavors are compatible enough with CommonMark for it to be a non-issue anyway).
fc417fc802
> If browsers can decide to render PDFs
They do that with JS (or at least they did at one point). Similar libraries exist for XSLT if you want newer versions than what browsers natively support, for jpegxl, and many other formats.
Lord_Zero
Gemini has its own format?
tweetle_beetle
> It has some superficial resemblances to Markdown, which will make it easy to learn if you know MD, but it's quite different in other ways.
echoangle
> html_content = html_content.replace('Minimum viable blog', title)
So every time your post contains the string 'Minimum viable blog', it will be replaced by the title of the current post? That’s a bug, right?
ostwilkens
Oh yes, good catch! The code in the post is the first draft from O1 and this string has been replaced with {{ title }}.
90s_dev
Also you don't need to separate :root from html in your code, they're always the same here, so you can save a couple lines by joining them.
chrismorgan
And if talking of such optimisations—
• Trailing slashes in HTML content (apart from SVG/MathML) are completely useless, unless you’re serving the document in XML syntax (which you can’t do by accident). I personally think they’re harmful, because they encourage an incorrect belief, and are seldom even applied consistently.
• <html>, <head>, </head>, <body>, </body> and <html> are all optional. In practice, you should have an <html lang> attribute so that you can’t omit that tag, but the others can normally all be omitted.
• In case-insensitive things, lowercase will normally compress better. But Brotli messes things up because it’s a popularity contest of the HTML that people actually write, so that <!DOCTYPE html> compresses better than <!doctype html>, and even <meta charset="utf-8"> compresses better than <meta charset=utf-8>. Anyway, <meta charset="UTF-8" /> would be better as <meta charset="utf-8">.
• In <meta name="viewport" content="width=device-width, initial-scale=1.0" />, the space after the comma, and the .0 in initial-scale, are unnecessary. (In fact, in theory the .0 might not even be parsed: the badly-incomplete-and-extremely-dodgy spec says to use strtod, which is locale-dependent, so a French machine might parse initial-scale=1.5 as only one, ignoring the .5 because it’s not ,5. In practice I’d be mildly surprised if browsers used the real locale-dependent strtod, though I haven’t checked. If some spec somewhere says “assume LC_ALL=C in such cases”, which would also largely resolve the problem, I’d like to know.)
All up (and with title fixed to be a proper placeholder, as discussed):
<!DOCTYPE html>
<html lang="en">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>{{ title }}</title>
<style>
html {
color-scheme: light dark;
font-family: system-ui, sans-serif;
max-width: 70ch;
padding: 3em 1em;
margin: auto;
line-height: 1.5;
font-size: 1.25em;
}
</style>
<a href="/" id="head-link">Carl Öst Wilkens' Blog</a>
{{ content }}febusravenga
So every time you post snippets how of code from your template/blog engine, it will be replaced by current blog post title? /s
ostwilkens
Wow, yes.. that's actually exactly what happened here :-)
echoangle
Kind of not /s, there’s currently no way to escape the template tags to make them appear in the output (except adding invisible Unicode characters or so).
90s_dev
I've been experimenting with minimal blogs for about 15 years. Some tricks I learned:
* You can get away with const title = lines.match(/# (.+)/)[1] and avoid frontmatter.
* My blogs never have so many posts they need pagination or tags, or categories, or sorting.
* JSX turns out to be a great vanilla server side string builder if you use a questionable hack like https://immaculata.dev/guides/enabling-jsx.html
* GH Pages with arbitrary build steps instead of (sigh) Jekyll is really easy now with things like https://immaculata.dev/guides/using-gh-pages.html
* highlight.js is still basically the king of super easy code syntax highlight by adding literally three lines to your HTML (shiki is cool but slooooow)
FlyingSnake
It is easy using standard static blogging framework like Hugo/Zola + Cloudflare Pages. I have a minimal blog (<100kb) and it meets all the criteria that OP has listed.
This is what I did:
- Use Hugo Blog Awesome theme
- Followed the 512kb guidelines and verified the page size.
- Stripped down any images and unwanted JS, but there weren't many.
null
_fat_santa
I ran an "MVB" for a while but mine was even more simplistic. Just a straight HTML page and for posts I would write them as .txt files and manually update the homepage. While it was quite "verbose", I would still say it was easier than having to deal with the "modern web".
Since that time I have moved to something more sophisticated and now run Astro for my personal site and blog and honestly it's freaking awesome. On their landing page they claim it's the best platform for "content driven sites" and after using it for 6 months I have to say I agree, they take all the BS out of building a blog and just give you clear and easy to follow conventions for just about everything you'd want for a blog.
shepherdjerred
Astro is absolutely amazing. I don't know how it's more popular.
achierius
Do you use someone else's theme or did you write your own?
_fat_santa
Wrote my own. TBH never even thought about custom themes though your comment makes me a bit curious.
emadda
Something I have experimented with for a few sites is using Bun JS with HTML in JS strings.
Bun has a —hot flag that regenerates static html on change.
IntelliJ IDE can detect a // language=html comment above strings which formats the html inside and does highlighting etc.
Just using vanilla JS functions instead of a template language lets you write any logic yourself instead of looking up the template languages way of doing it.
agubelu
I use a very similar approach in my own blog, because I'm tired of over-bloated websites that take waaaay too long to load: https://blog.borrego.dev
Source: https://github.com/agubelu/blog
indigodaddy
I like this a lot and it looks great! How does it look on mobile?
agubelu
It looks pretty good I'd say. Feel free to use the design if you like it!
abhisek
I would really think it depends on use-case. If you are tired of Wordpress bloat and want something simpler you can probably build a markdown server over a directory with a very very minimal template. I remember Renato used to do that for docs, just serve a website on top of a dir containing markdown files.
But as you invest time and effort, get more readers and asks from your readers, your need for features even for a simple blog will increase. At least basic conversation around content. You will probably end up using Discuss or decide to make your simple blog much more complex by introducing a database (or may even be just flat files on S3).
At some point you will either focus on only "writing" and sharing ideas in which case a simple publishing infra is good. If you want more, you will probably end up building a Jekyll, Hugo etc. from scratch or better adopt and contribute to one of these :)
Retr0id
This is basically how my blog works, except I use mistune as the markdown renderer, which has allowed me to extend it over time, including adding syntax-highlighted code blocks and latex math syntax: https://www.da.vidbuchanan.co.uk/blog/mathml-blogging.html
I also generate an index page and an RSS feed.
One thing that's been bugging me more recently (now that I have tens of articles written) is that I need to implement incremental rebuilds. Right now every page needs to get regenerated at once, which takes triple-digit-milliseconds. Unacceptable!
john-h-k
Thats an awesome setup and very similar to the one I have. But damn triple-digit-ms does actually sound shockingly slow for what is effectively just heavy text processing. Is there a huge amount of text?
Retr0id
One of my more dubious design decisions (7 years ago...) was to inline all my images as base64 (I was originally planning on having only simple diagrams that would compress well, but this is less true now). I like that every page load generates just a single request, and that you can ctrl+s the page without any breakage.
I haven't profiled anything though, it could also be the syntax highlighting being slow (it generates quite a soup of HTML tags).
90s_dev
A trick I used to use is to check during my custom build step whether the image is under 1k, and inline it if so, otherwise add its hash to the url and add a preload to the html header. I'm trying to get back to that in my latest custom build tool, but it's a gradual process to evolve it to that point properly.
ostwilkens
Looks nice and minimal as well. Love the look of your blog!
The markdown2 package includes an option for syntax highlighting. You need to bring your own css though.
I'm reminded of the chart from this blog post: https://molodtsov.me/2023/02/how-to-start-your-blog-in-2023/
As I fell into the SSG pit I found I mostly wrote about and fooled around with the SSG itself, instead of all the things I originally planned on writing about and doing. So I threw away the SSG and installed Wordpress and stopped caring. It's been liberating.
If the goal is to tinker and write about the tinkering, that is fine. If you're not like me and the tinkering never gets in the way of the writing, that's also fine. But that wasn't me. I had to learn yet again that the best tool was the one that got out of my way and let me do what I came to do.
The last thing I need when I'm aiming to write is a chance to procrastinate.