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.
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.
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.
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).
WordPress.com doesn't support many of the plugins out there (or at least not on the price tiers I can see) -- but I happily used it for https://librefm.wordpress.com for a number of years.
Of course, WordPress.com is updated differently to a blog running the wordpress.org code.
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.
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.
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.
> 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.
Again, we're talking about blogging, not business sites or SSR or CMS tooling. Very different needs with very different solutions.
I personally don't think it's that much work, and definitely not complicated, to keep my software up to date. And as a blog all I need to do is cache / throw behind a CDN and I'm golden. Nothing complex going on here. No headaches, no late nights, not even a wink of worry.
I think you two are talking past each other. Yes, people use WordPress for serious websites, and WooComerce stores, and all that stuff. But Tallain is not talking about those people. Tallain is talking about blogging.
Blogging is also often business critical. Entire businesses are built around blogs. I presonally know someone who sold their "wordpress blog" for $30m.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
For a similar reason, blog posts should have no words as these can become SOE and the purpose of blogging become intrinsic SEO.
Personally, I blog in my head but am concerned still it could lead to bias in my other activities which are mainly related to sitting under a tree by a lake in the middle of nowhere.
My general experience with RSS users is that they understand not every post is for them. I've got some feeds that I read once or twice a year when I'm in the mood to learn what's going on in that corner of the world. I've got feeds where I skip 90% of the posts, because they're not the topic(s) I subscribed for. And I've got feeds I read daily, of course.
I tend to expect most useful sources of high-quality information to have a fair amount of off-topic content, since it's hard to reach critical mass on a single narrow niche. I read Hacker News, but click maybe 10% of the links
RSS is very liberating. Quality of content is something very subjective and the audience can choose what to engage with. Nothing called perfect and not every post has to be a masterpiece.
I’ve had a Wordpress blog since 2012, and many years of a Livejournal before that (when timeline filters were pretty much nonexistent) and I don’t think I ever felt this fear. Sometimes I had art to share. Sometimes a serious post about something that was on my mind. Sometimes just the results of a “which Teenage Mutant Ninja Turtle are you” quiz that half my friends had already posted.
Worrying about this “pressure” is a great way to be that guy with three posts about their new static site generator and nothing else.
> 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.
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.
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.
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.
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.
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
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!
I think that the best setup is Jekyll on GitHub pages. It's the lowest-effort way to turn text files into a website.
If you don't start from scratch, the biggest problem with static websites is maintaining old URLs. At some point you need URL rewrite rules, and then you can't just have static files on a server. You need server rules.
It's also nice to just editing text files locally without having to install stuff. Then you need some sort of build system on another server.
Then you might find that you need forms, comments and other features beyond text on a page.
I decided on running an instance of Grav, which is a flat file CMS, with a fairly minimalist theme, except I version all of the files (even the PHP dependencies) in my Git repo, from which I build Docker images that actually get deployed: https://getgrav.org/
The benefit here is that I can launch it locally and see how the blog posts look, it's just a bunch of files unlike SSG, but with dynamic templating, meaning that I also get an updated index of the pages, as well as search functionality out of the box.
Furthermore, each new post is basically a deploy of a new version of the container, which curiously also means that if something goes wrong (e.g. if it gets hacked), there is no serious data loss because none of the data is meant to be truly persistent, I don't even need to think that much about backing it up, rather just the Git repo its built from.
Plus, there's a nice admin UI if I need it (behind additional auth through the web server), or I can just write things in a text editor of my choice locally.
Oh, and the performance is pretty good, too, because there is no database to hit with complex SQL, more like some disk I/O (which also is lessened by the cache).
I use the GitHub pages for that. Though hopping through various CMS or static-site-generators (like, Hugo, Jekyll, etc), I settled on a fully static and custom system, works with Javascript.
I think same could also be achieved via React, but I did not want any `npm install` hence, I used some JS libraries like marked and markdown.js directly at the frontend. (Added as git submodules)
I also sort-of liked how a dependency management mechanism could be built directly on top of the git submodules, without requiring an explicit package manager. Given the commits cloned are already pinned and committed to the repository. Though, the tooling is not as good as the well-established dependency management software like Maven, NPM, PIP, etc.
Nevertheless, it worked well for a basic blog, I publish the articles directly in markdown format, embedding some HTML if necessary. In fact, all the pages are some sort of markdown, rendered to HTML upon loading. But of course, the URLs are not "real", I use the query string to refer to the pages, such as `mert.akeng.in/?/blog`, the JS fetches `/blog.md` and renders it to the `<main>` element. Much like how you would initialize React through/within JS.
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.
> 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.
> 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).
• 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):
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).
Not following all requirements, but you could also just have an RSS feed generated from markdown files you have locally and publish that (using a tool like mdrss).
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.
* 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)
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.
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.
My blog is more minimal, and still viable. It's just a big page with 761 posts on it. It's 360 KB all in, and it's interactive in about 1 second.
No category pages, no individual pages. No search... well, CMD+F is your search engine, and it's blazingly fast.
That design actually works really well if all you care about is getting text content out there, and the idea of comments—let alone ads—isn't appealing to you.
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 :)
Enjoyable to see another minimal static blog and the discussion around it.
Since we're chatting about our static site generators - I've been working on mine for a few months and naturally spend way more time on the generator than the content. ;) Mine is written in TypeScript and I'm targeting HTML 4.01 Strict for compat with old browsers.
It started pretty simple, just walk a directory of .md files and output .html, but it now has RSS, Atom, tags, a "latest" page, sitemap, stats, table of contents, SEO features, etc.
It's been fun - a nice "easy" project to slowly polish over time and to gradually grow my TS skills.
I'm in the process of resurrecting an old blog of mine, which had used hexo back in the day with all the raw posts being markdown files that are statically rendered to HTML... and to be honest I'm pretty tempted by this very simple approach because hexo is, honestly, annoying me.
For whatever reason it's just not picking up themes even though I'm now using the most up to date everything. And actually I've realised I don't even like the vast majority of the themes anyway, including the one I used previously. And since developing my own hexo theme seems like kind of a faff, I'm pretty tempted to just throw together a Sass sheet, compile it to CSS, and use that as my theme.
I guess if I got into the detail of it - comments, archive pages, etc. - the complexity would start to creep in and I'd find that what I was doing was building my own home-rolled hexo-alike... so maybe I should persist with figuring out why themes aren't working for a bit longer.
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!
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?
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).
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.
If I was going to do a blog today, I'd dump hand written HTML into an S3 bucket and call it a day.
The static site generators are nice, but it's really not a huge deal to spin up a few common css classes and maintain a little bit of mental discipline.
I think using a blog to communicate your ideas and skills is great. I think making the blog tech stack itself representative of those things seems distracting. Not everything has to be a smartass ego implementation. As long as you spend 5 minutes testing on mobile, your audience probably won't notice a damn thing the next time it touches the front page of HN or wherever.
I was handwriting HTML for a while but found that I write a lot more with an actual CMS. At the end of the day it doesn’t matter what your setup is as long as it helps you write as much as possible.
I went all in on using Caddy for rendering my website and blog, but I’m encountering a frustrating issue that I’m not sure how to solve.
The feed on my site uses the listFiles feature to populate from a directory. I take care to name things so ordering is preserved.
No problems on my machine getting the feed ordered correctly.
However, when deployed to Railway via a container, the ordering is all wrong.
Any thoughts on how to debug?
listFiles is not sorted. It provides the files in the order that the OS provides them. That it's ordered on your machine, probably has to do with when the underlying nodes were created. But that's not going to much work in production.
dirInfo, err := dir.Readdir(0)
if err != nil {
return nil, err
}
names := make([]string, len(dirInfo))
for i, fileInfo := range dirInfo {
names[i] = fileInfo.Name()
}
Yeah that was what I was afraid of. I thought I saw in the caddy code that they did a sort on file name, but I must have misread it.
Thanks for responding!
Edit: after looking more closely at sprig, the solve was sortAlpha
I restarted my own blog in exactly the same way after getting frustrated with WordPress. The most important thing in blogging is to get something simple that will not get the way of you actually writing.
Over the years I have added to my solution with custom markdown, tagging, rss, and most lately exif-stripping. Technically the source is available [0] but I can’t see anyone else using it.
I did the same. Sync'd my Obsidian .md vault between my macbook and my server. Asked AI for an index.php that would render a nice html/css webpage at domain.com/whatever for every whatever.md on the fly. Works fantastic. Supports everything Obsidian markdown does - pics, videos, resizing via drag, wikilinking, codeblocks, etc… No publish step - from my site you can literally see me typing live in Obsidian. No more friction to share things.
I don't know if a minimum viable blog needs to pre-render html... For this a PHP script is lightning fast and the source markdown file is the only source of truth -- if you correct a typo then it's immediately live, no need to think about rendering.
Made this silly thing to have a site with just html and have a way to have templates & header includes, while still having the site accesible without JS if needed
It lets you create a blog and a newsletter with Markdown and publish directly from the command line (or the web editor). You get the offline-first workflow of Markdown, but with beautiful themes like substack.
It's like a mix between Wordpress, netlify and substack.
If you're already using Emacs and/or org mode, then this is a useful guide to setting up a blog/site that is super easy to maintain/push/etc, including free hosting at github with a custom domain name:
This reminds me of my own website using Apache's server side includes in the late nineties. No Markdown though, but otherwise not substantially different. Simplicity tends to work best (most reliable, least resources) for text content.
I personally use a combination of quarto to statically render markdown files and hosting on GitHub pages because I don't want to bother with the self hosting for now.
In the past I used a combination of R-markdown with a nginx server but decided to move to a simpler solution
As easy as wordpress, square space or whatever claim to be, in my mind this is even easier, the solution is more elegant, and you expose yourself to a whole lot less crap along the way.
Edit: I recognise this doesn't cover hosting, domain registration etc.
Thanks! Yeah, I find this a lot easier. And yes, hosting is an exercise left to the reader :-) I might write about my hosting setup in an upcoming blog post.
Very nice and minimal. I am going the opposite direction. I am cancelling my static generated blogs and moving everything to LakyAI which will help me to manage everything from a single place. Not quite ready for prime time tho.
I've been wondering what is the benefit of putting up your own web server or scripts to serve your static content when you could put it in a Github repo or serve from something like S3?
The nice thing about latter is that the bandwidth, DDoS or other load-related issues aren't that much of a problem. Server maintenance also isn't a problem as you don't have any.
One key benefit of putting up an own server is that there are no limitations on file types and much fewer restrictions on what kind of content you can create.
For serving static files, I can (and have) lived a long time with one of the "free hoster" sites -- from times before Github Pages or S3 were a thing I guess, today I'd go for Github Pages.
A key advantage of moving to an own server was that I can enable the odd feature or technology any time. E.g. most recently I wanted to have some "private" subspace with fancy authentication and it was easy to add with proper access to the server config.
> I've been wondering what is the benefit of putting up your own web server or scripts to serve your static content when you could put it in a Github repo or serve from something like S3?
I think you're overestimating the work required to put together a web server. For example, you mention dumping files in a S3 bucket, but that doesn't require much more work than whipping out a nginx instance and dropping said files in a folder.
Also, some people already run their own servers or deploy their services in some cloud procider. The work required to put together a blog is minimal.
Thank you for putting the effort to keep the open web alive, especially by sharing this simple though effective tool. I use Wordpress and like it. I learned to enjoy using it when I stopped reading "pros & cons" bulleted lists about it.
your blog has 1 big problem - no SEO optimization, meaning that after spike of visitors from HN today, it will disappear in Google void after couple of days, meaning no visitors in the future, no mentions from ChatGPT, etc. It's most common problem for all self-hosted blog engines, though idea I like that main idea of minimalist blogs (I am using Bear blog by myself).
How much does that actually matter? Most blogs I read I found via HN or through other blogs, I'd seldomly go googling for one, except when maybe lost the link, etc.
I was thinking, another thing you could probably easily add is optimizing the images for web delivery, in your first article there are quite large jpgs.
The hardest part is the DevOps part where you need to find out reliable host, how to deploy, CI/CD and all the server-related stuff if you want maximum customization.
Cache plugins still go through the PHP interpreter. I'm under the impression there still isn't anything faster than serving HTML files.
Better is use a static site plugin, then you don't have to bother with configuring any caching or external services.
Best is also use the SQLite Database Integration plugin, so the server doesn't even have to run MySQL/MariaDB (other than initial installation), and on an otherwise light server, the filesystem will effectively keep the site in page cache while using less memory, if I understand that correctly.
The WordPress interface can be kept behind HTTP auth or client cert.
> Cache plugins still go through the PHP interpreter. I'm under the impression there still isn't anything faster than serving HTML files.
Several WordPress caching plugins, like W3TC (https://wordpress.org/plugins/w3-total-cache/), actually add rules to your Apache/Nginx server so that the cached HTML pages are served statically without touching PHP.
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.
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.
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.
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.
Maybe not so benevolent after all.
It keeps itself up to date.
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).
Wordpress.com works fine for ordinary people. No updates to worry about. Not my cup of tea, but dead simple.
WordPress.com doesn't support many of the plugins out there (or at least not on the price tiers I can see) -- but I happily used it for https://librefm.wordpress.com for a number of years.
Of course, WordPress.com is updated differently to a blog running the wordpress.org code.
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.
Blog spam? :) The URL is https://rakhim.org/honestly-undefined/19/
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.
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.
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.
> 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.
Again, we're talking about blogging, not business sites or SSR or CMS tooling. Very different needs with very different solutions.
I personally don't think it's that much work, and definitely not complicated, to keep my software up to date. And as a blog all I need to do is cache / throw behind a CDN and I'm golden. Nothing complex going on here. No headaches, no late nights, not even a wink of worry.
Wordpress is used for business sites / ecommerce all over the place. There are whole business built around Wordpress sites.
I think you two are talking past each other. Yes, people use WordPress for serious websites, and WooComerce stores, and all that stuff. But Tallain is not talking about those people. Tallain is talking about blogging.
Blogging is also often business critical. Entire businesses are built around blogs. I presonally know someone who sold their "wordpress blog" for $30m.
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.
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.
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.
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.
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.
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.
[1] https://getnikola.com/
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.
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.
> 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.
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.
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.
For a similar reason, blog posts should have no words as these can become SOE and the purpose of blogging become intrinsic SEO.
Personally, I blog in my head but am concerned still it could lead to bias in my other activities which are mainly related to sitting under a tree by a lake in the middle of nowhere.
My general experience with RSS users is that they understand not every post is for them. I've got some feeds that I read once or twice a year when I'm in the mood to learn what's going on in that corner of the world. I've got feeds where I skip 90% of the posts, because they're not the topic(s) I subscribed for. And I've got feeds I read daily, of course.
I tend to expect most useful sources of high-quality information to have a fair amount of off-topic content, since it's hard to reach critical mass on a single narrow niche. I read Hacker News, but click maybe 10% of the links
RSS is very liberating. Quality of content is something very subjective and the audience can choose what to engage with. Nothing called perfect and not every post has to be a masterpiece.
I’ve had a Wordpress blog since 2012, and many years of a Livejournal before that (when timeline filters were pretty much nonexistent) and I don’t think I ever felt this fear. Sometimes I had art to share. Sometimes a serious post about something that was on my mind. Sometimes just the results of a “which Teenage Mutant Ninja Turtle are you” quiz that half my friends had already posted.
Worrying about this “pressure” is a great way to be that guy with three posts about their new static site generator and nothing else.
> 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.
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.
https://marginalia-search.com/
I agree but I could also imagine a world where a minimally viable blog is just an RSS feed.
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.
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 :-)
In the spirit of being minimally viable you could just have that in the filename and sort it before generating.
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.
[0] https://everest-pipkin.com/teaching/handmadeRSS
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.
[1] https://github.com/susam/susam.net/blob/main/site.lisp
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.
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.
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...
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
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!
I think that the best setup is Jekyll on GitHub pages. It's the lowest-effort way to turn text files into a website.
If you don't start from scratch, the biggest problem with static websites is maintaining old URLs. At some point you need URL rewrite rules, and then you can't just have static files on a server. You need server rules.
It's also nice to just editing text files locally without having to install stuff. Then you need some sort of build system on another server.
Then you might find that you need forms, comments and other features beyond text on a page.
Basically, it's hard to have just static files.
I did something a bit unconventional for my own blog: https://blog.kronis.dev/blog/my-blog-doesnt-need-quality-it-...
I decided on running an instance of Grav, which is a flat file CMS, with a fairly minimalist theme, except I version all of the files (even the PHP dependencies) in my Git repo, from which I build Docker images that actually get deployed: https://getgrav.org/
The benefit here is that I can launch it locally and see how the blog posts look, it's just a bunch of files unlike SSG, but with dynamic templating, meaning that I also get an updated index of the pages, as well as search functionality out of the box.
Furthermore, each new post is basically a deploy of a new version of the container, which curiously also means that if something goes wrong (e.g. if it gets hacked), there is no serious data loss because none of the data is meant to be truly persistent, I don't even need to think that much about backing it up, rather just the Git repo its built from.
Plus, there's a nice admin UI if I need it (behind additional auth through the web server), or I can just write things in a text editor of my choice locally.
Oh, and the performance is pretty good, too, because there is no database to hit with complex SQL, more like some disk I/O (which also is lessened by the cache).
I use the GitHub pages for that. Though hopping through various CMS or static-site-generators (like, Hugo, Jekyll, etc), I settled on a fully static and custom system, works with Javascript.
I think same could also be achieved via React, but I did not want any `npm install` hence, I used some JS libraries like marked and markdown.js directly at the frontend. (Added as git submodules)
I also sort-of liked how a dependency management mechanism could be built directly on top of the git submodules, without requiring an explicit package manager. Given the commits cloned are already pinned and committed to the repository. Though, the tooling is not as good as the well-established dependency management software like Maven, NPM, PIP, etc.
Nevertheless, it worked well for a basic blog, I publish the articles directly in markdown format, embedding some HTML if necessary. In fact, all the pages are some sort of markdown, rendered to HTML upon loading. But of course, the URLs are not "real", I use the query string to refer to the pages, such as `mert.akeng.in/?/blog`, the JS fetches `/blog.md` and renders it to the `<main>` element. Much like how you would initialize React through/within JS.
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.
> 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.
> 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).
Gemini has its own format?
> 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.
https://geminiprotocol.net/docs/gemtext.gmi
> 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?
Oh yes, good catch! The code in the post is the first draft from O1 and this string has been replaced with {{ title }}.
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.
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):
I salute your yak shaving.
So every time you post snippets how of code from your template/blog engine, it will be replaced by current blog post title? /s
Wow, yes.. that's actually exactly what happened here :-)
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).
Not following all requirements, but you could also just have an RSS feed generated from markdown files you have locally and publish that (using a tool like mdrss).
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.
Astro is absolutely amazing. I don't know how it's more popular.
Do you use someone else's theme or did you write your own?
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)
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.
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.
1: https://512kb.club
2. https://radar.cloudflare.com/scan
My blog is more minimal, and still viable. It's just a big page with 761 posts on it. It's 360 KB all in, and it's interactive in about 1 second.
No category pages, no individual pages. No search... well, CMD+F is your search engine, and it's blazingly fast.
That design actually works really well if all you care about is getting text content out there, and the idea of comments—let alone ads—isn't appealing to you.
Could you share the URL please?
I'd like to try the same thing.
Is there a list of posts at the top or just H1s for each post?
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 :)
Enjoyable to see another minimal static blog and the discussion around it.
Since we're chatting about our static site generators - I've been working on mine for a few months and naturally spend way more time on the generator than the content. ;) Mine is written in TypeScript and I'm targeting HTML 4.01 Strict for compat with old browsers.
It started pretty simple, just walk a directory of .md files and output .html, but it now has RSS, Atom, tags, a "latest" page, sitemap, stats, table of contents, SEO features, etc.
It's been fun - a nice "easy" project to slowly polish over time and to gradually grow my TS skills.
Am I the only one who uses bash and pandoc? I really should switch to a "real" language for SSG
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
I like this a lot and it looks great! How does it look on mobile?
It looks pretty good I'd say. Feel free to use the design if you like it!
Here’s one using Emacs’ Org mode built-in HTML publishing capabilities:
https://github.com/hcarvalhoalves/org-mode-site-template
I'm in the process of resurrecting an old blog of mine, which had used hexo back in the day with all the raw posts being markdown files that are statically rendered to HTML... and to be honest I'm pretty tempted by this very simple approach because hexo is, honestly, annoying me.
For whatever reason it's just not picking up themes even though I'm now using the most up to date everything. And actually I've realised I don't even like the vast majority of the themes anyway, including the one I used previously. And since developing my own hexo theme seems like kind of a faff, I'm pretty tempted to just throw together a Sass sheet, compile it to CSS, and use that as my theme.
I guess if I got into the detail of it - comments, archive pages, etc. - the complexity would start to creep in and I'd find that what I was doing was building my own home-rolled hexo-alike... so maybe I should persist with figuring out why themes aren't working for a bit longer.
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!
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?
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).
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.
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.
If I was going to do a blog today, I'd dump hand written HTML into an S3 bucket and call it a day.
The static site generators are nice, but it's really not a huge deal to spin up a few common css classes and maintain a little bit of mental discipline.
I think using a blog to communicate your ideas and skills is great. I think making the blog tech stack itself representative of those things seems distracting. Not everything has to be a smartass ego implementation. As long as you spend 5 minutes testing on mobile, your audience probably won't notice a damn thing the next time it touches the front page of HN or wherever.
I was handwriting HTML for a while but found that I write a lot more with an actual CMS. At the end of the day it doesn’t matter what your setup is as long as it helps you write as much as possible.
Static HTML will also hold up a lot better if a post gets popular than a heavyweight dynamic site framework will.
I went all in on using Caddy for rendering my website and blog, but I’m encountering a frustrating issue that I’m not sure how to solve. The feed on my site uses the listFiles feature to populate from a directory. I take care to name things so ordering is preserved. No problems on my machine getting the feed ordered correctly. However, when deployed to Railway via a container, the ordering is all wrong. Any thoughts on how to debug?
listFiles is not sorted. It provides the files in the order that the OS provides them. That it's ordered on your machine, probably has to do with when the underlying nodes were created. But that's not going to much work in production.
Yeah that was what I was afraid of. I thought I saw in the caddy code that they did a sort on file name, but I must have misread it. Thanks for responding!
Edit: after looking more closely at sprig, the solve was sortAlpha
I'd love more info about your process!
Inspiring.
I've built a blogging platform with similar vision which I could call "Minimum Viable Blogging Platform"
https://mataroa.blog/
I love matoaroa.blog!
When I was experimenting with SSH apps I decided to create a blog platform inspired by it: https://prose.sh
Thanks for the inspiration!
I remember I read it on HN a few years ago and then I completely forgotten about it.
I am moving (some of) my blog over now.
I restarted my own blog in exactly the same way after getting frustrated with WordPress. The most important thing in blogging is to get something simple that will not get the way of you actually writing.
Over the years I have added to my solution with custom markdown, tagging, rss, and most lately exif-stripping. Technically the source is available [0] but I can’t see anyone else using it.
[0] https://github.com/andrewstephens75/gensite
>The most important thing in blogging is to get something simple that will not get the way of you actually writing.
Yes! I find the easiest way for me is to just open a new tab in my code editor and typing.
Exif is a real gotcha. I'm planning to compress images anyway, so this could be done in the same step.
> Exif
Yeah, I thought I was being careful and manually stripping it from photos until a nice reader emailed me to gently let me know i had missed a few.
I did the same. Sync'd my Obsidian .md vault between my macbook and my server. Asked AI for an index.php that would render a nice html/css webpage at domain.com/whatever for every whatever.md on the fly. Works fantastic. Supports everything Obsidian markdown does - pics, videos, resizing via drag, wikilinking, codeblocks, etc… No publish step - from my site you can literally see me typing live in Obsidian. No more friction to share things.
Makes me think of https://bearblog.dev/.
I've been thinking about using Obsidian as a static site generator.
Besides Obsidian Publish, one may consider the Digital Garden extension or https://benchristel.github.io/mdsite/
I don't know if a minimum viable blog needs to pre-render html... For this a PHP script is lightning fast and the source markdown file is the only source of truth -- if you correct a typo then it's immediately live, no need to think about rendering.
It can be more simple: Just use php for SSR
Made this silly thing to have a site with just html and have a way to have templates & header includes, while still having the site accesible without JS if needed
https://github.com/sareiodata/hx-weaver
That being said, I don't find myself actually writing a blog :)
I have a very simple setup using 11ty (https://rory.codes) - but nowhere near as simple as this. Very impressive!
Take a look at https://markdown.ninja
It lets you create a blog and a newsletter with Markdown and publish directly from the command line (or the web editor). You get the offline-first workflow of Markdown, but with beautiful themes like substack.
It's like a mix between Wordpress, netlify and substack.
I just made this thing[0] last few days, and it's sooo much, and you showed me simple. So here's my simple: https://o0101.github.io/mvb/
I think I like simple.
[0]: https://studio.dosaygo.com
If you're already using Emacs and/or org mode, then this is a useful guide to setting up a blog/site that is super easy to maintain/push/etc, including free hosting at github with a custom domain name:
https://stuff.sigvaldason.com/how.html
I want to blog but my DOMAIN name got taken and it costs 16k now wtf.
This reminds me of my own website using Apache's server side includes in the late nineties. No Markdown though, but otherwise not substantially different. Simplicity tends to work best (most reliable, least resources) for text content.
This is why I created https://github.com/xeoncross/jr all those years ago
You don't need a backend.
Love this, and how more and more folks are going minimal, like https://wordgag.com/.
I personally use a combination of quarto to statically render markdown files and hosting on GitHub pages because I don't want to bother with the self hosting for now. In the past I used a combination of R-markdown with a nginx server but decided to move to a simpler solution
Nice solution, and congrats on winning HN for the moment. And thanks for 46elks. (Happy customer here.)
That was unexpected! My friend Calle wrote this article and he has made some really cool projects with 46elks (and demos with voice recognition).
Ping me on my work email and I’ll send you some fun links! :)
The perfect minimal web is Astro Js and that’s because of images.
Mobile screens and desktop are fundamentally different. You can’t have small and big at the same time.
That is solved via the standard html img srcset
Astro solves that easily.
And Wordpress of course.
I tried to follow the same reasoning and made my own SSG for this purpose - Hajime.
It really does help when you don’t even have the potential option to distract yourself with bells and whistles.
Write some markdown, run a command and your blog updates.
Hi sounds interesting, do you have this tool online anywhere?
Yeah, the source is on SourceHut: https://git.sr.ht/~hxii/hajime
It's 2025, the web has come full circle again, so where's the RSS feed?
Thanks for sharing, I like your approach.
As easy as wordpress, square space or whatever claim to be, in my mind this is even easier, the solution is more elegant, and you expose yourself to a whole lot less crap along the way.
Edit: I recognise this doesn't cover hosting, domain registration etc.
Thanks! Yeah, I find this a lot easier. And yes, hosting is an exercise left to the reader :-) I might write about my hosting setup in an upcoming blog post.
Very nice and minimal. I am going the opposite direction. I am cancelling my static generated blogs and moving everything to LakyAI which will help me to manage everything from a single place. Not quite ready for prime time tho.
This is the kind of post that makes me visit Hacker News time to time.
Starts getting messy once you add sorting, pagination, categories/tags.
True! Luckily, I don't have a need for those features :-)
Definitely one of those things to design with the expectation that it will grow.
Yeah but too technical for 99% of the humanity.
For all of them I built Lykhari.com
The post is skipping the hosting side. Guess it doesn't matter too much these days? What's the best besides Netlify's or Cloudflare's free tiers?
Imo oracle cloud free tier vm with a simple caddy or traefik setup.
Three lines in a Caddyfile would be sufficient
I currently have a very similar setup. And tbh I’m keen to move to a less involved solution…
Are there anything like ghpages with a built in wysiwyg editor?
There are still some wysiwyg html editors available. On the top of my head I can think of the editor included in the Seamonkey suite.
Also, etherpad can export to html.
I've been wondering what is the benefit of putting up your own web server or scripts to serve your static content when you could put it in a Github repo or serve from something like S3?
The nice thing about latter is that the bandwidth, DDoS or other load-related issues aren't that much of a problem. Server maintenance also isn't a problem as you don't have any.
One key benefit of putting up an own server is that there are no limitations on file types and much fewer restrictions on what kind of content you can create.
For serving static files, I can (and have) lived a long time with one of the "free hoster" sites -- from times before Github Pages or S3 were a thing I guess, today I'd go for Github Pages.
A key advantage of moving to an own server was that I can enable the odd feature or technology any time. E.g. most recently I wanted to have some "private" subspace with fancy authentication and it was easy to add with proper access to the server config.
> I've been wondering what is the benefit of putting up your own web server or scripts to serve your static content when you could put it in a Github repo or serve from something like S3?
I think you're overestimating the work required to put together a web server. For example, you mention dumping files in a S3 bucket, but that doesn't require much more work than whipping out a nginx instance and dropping said files in a folder.
Also, some people already run their own servers or deploy their services in some cloud procider. The work required to put together a blog is minimal.
Usually a web server is a real simple add-on to an already established home network/lab.
It's not necessary. Just a fun thing to do.
Doing it easy for yourself and get quicker to the content is the way to go.
Auto-index with header.html and some js for me
Thank you for putting the effort to keep the open web alive, especially by sharing this simple though effective tool. I use Wordpress and like it. I learned to enjoy using it when I stopped reading "pros & cons" bulleted lists about it.
Sanitize your strings!
your blog has 1 big problem - no SEO optimization, meaning that after spike of visitors from HN today, it will disappear in Google void after couple of days, meaning no visitors in the future, no mentions from ChatGPT, etc. It's most common problem for all self-hosted blog engines, though idea I like that main idea of minimalist blogs (I am using Bear blog by myself).
How much does that actually matter? Most blogs I read I found via HN or through other blogs, I'd seldomly go googling for one, except when maybe lost the link, etc.
If you don't want others to discover it later, then it doesn't matter
This is tongue in cheek yes? I thought you were actually advocating for SEOization until the GPT mention.
I think even SEO is on the outs in favor of established domain authority, so the best tactic is to blog expecting obscurity.
I feel like the first MVB was Maddox - too bad he fell way off.
> Tired, so ask O1 for a render.py script
Groan
I was thinking, another thing you could probably easily add is optimizing the images for web delivery, in your first article there are quite large jpgs.
The hardest part is the DevOps part where you need to find out reliable host, how to deploy, CI/CD and all the server-related stuff if you want maximum customization.
good idea .... for ipfs
yes.
Dear god the bugs in that Python…
I'm more of a WordPress guy. Click "install wordpress". When I need something I add a plugin. No code required.
I would be genuinely interested to know how well the average wordpress blog handles a hug from the HN frontpage! :-)
Wordpress is of course overkill for a personal blog like yours, but implying wordpress cant handle a HN hug is a bit naive.
Millions of sites use WP and there are configurations to mitigate this. Some caching and easy server config will be enough to survive the “hug”
It's pretty easy to proxy your WordPress with cloudflare's cdn. Then your WordPress isn't hit very often.
WordPress handles volume just fine. Nothing a HN hug would disrupt.
There are cache plugins that effectively turn it into a static site. You could also run CF atop of it.
WordPress is used at scale by many companies.
That seems like a great stack, if you're looking for one!
Cache plugins still go through the PHP interpreter. I'm under the impression there still isn't anything faster than serving HTML files.
Better is use a static site plugin, then you don't have to bother with configuring any caching or external services.
Best is also use the SQLite Database Integration plugin, so the server doesn't even have to run MySQL/MariaDB (other than initial installation), and on an otherwise light server, the filesystem will effectively keep the site in page cache while using less memory, if I understand that correctly.
The WordPress interface can be kept behind HTTP auth or client cert.
> Cache plugins still go through the PHP interpreter. I'm under the impression there still isn't anything faster than serving HTML files.
Several WordPress caching plugins, like W3TC (https://wordpress.org/plugins/w3-total-cache/), actually add rules to your Apache/Nginx server so that the cached HTML pages are served statically without touching PHP.