In a shared web hosting environment I'm building a React site myself, but found myself not updating it as much as I can't build on the go and am thinking about returning to a classic CMS solution. Even though I dislike all the clutter WordPress comes with, I'm used to it after all these years.
I wrote a custom web-based editor that lets me conveniently edit all the files from any device including mobile.
https://github.com/eoncarlyle/portfolio-website https://iainschmitt.com/post/november-2024-grab-bag#moving-t... https://iainschmitt.com/post/new-syntax-highlighting
It's not anything anyone would build today, and I would not recommend it to anyone, but it does have some very interesting properties that make some things that are often difficult very easy. Embedding dynamic content mid-article for instance is very easy because of a processing pass before a page gets handed to the view. It has a concept of ordered content filters, so by post I can declare what filters get applied and in what order. Filters include markdown parsing, as well as a syntax for injecting dynamic elements.
It's kind of my Frankenstein's monster at this point, but as an tinkerer I enjoy maintaining it. If I didn't enjoy it, I would have switched to something sane years ago.
I built shedtheshade.com few years ago, and learnt a few things about blogs along the way.
Here are my takeaways:
- Substack is great for starters
- Mailing should be always included with blog config for best results
- If a blog is updated, best way is to make sure changes are reflected in real-time as it can do a lot of damage.
- People(and crawlers) don't tend to wait for a lot of time, make sure it is fast for at least first paragraph loading in few seconds
- Understanding about Readability in modern society is important
- Media hosts should be served via CDN
- Comments should be independent to blog post db because it's the only user entered content with possiblity of getting your blog hacked
Hence the best way would be:
- Some SSG (preferably SEO optimised)
- Backend API on CF Workers
- Websockets for Blog Update
- Some DB (Preferably NoSQL for Posts and SQL for User Acc. info)
- Additional Layer of CDN
- API for Top or Suggestive Posts
- Editor.js for Editing
My one mark against it is the learning curve is sharp. That's okay for me, since I plan to use it to the end of my days, and so I can amortize the cost of learning it once against many decades of productivity. I have an old GitHub page for people struggling to get to base camp on its learning curve: https://github.com/Siilikuin/minimum-viable-hugo
And here are some sites I run in it:
https://andrew-quinn.me/, my barebones personal blog.
https://hiandrewquinn.github.io/til-site/, my much more frequently updated TILs. Think of this as halfway between a blog and Twitter.
https://hiandrewquinn.github.io/selkouutiset-archive/, a daily updating news archive for the Simple Finnish broadcast, happily running since 2023. The pipeline for this one is interesting, since it uses not only Hugo but Git submodules under the hood. One Git repo exists purely to curl the page I'm watching every night, and I try to mess with that one as little as possible because messing up might mean a night goes unarchived. An intermediate one submodules repo #1 and cleans up the HTML to Hugo-friendly Markdown with pandoc and sed. The final one imports this slimmed down, Markdownified version directly into its content/ directory as a Git submodule and redeploys the whole shebang every night. So far we're up to over a thousand unique HTML pages and this refinery has continued to work with only minimal changes, because we've stuck with such reliable and slow-changing tooling.
And apart from the domain, it’s free.
Once it's published, Brevo automatically picks up the RSS Feed to send out my daily newsletter, since I switched from long-form sporadic blog posts to a shorter-form daily newsletter.
I've used Hugo/Jekyll in the past and liked it, but I'm used to SvelteKit now so I just stick with it, plus I could always hook up a Headless CMS still if necessary.
- Jekyll => which generates static pages -> amazing to deploy it on Github Pages or any web server
- Rails 8 with Sitepress => for when I want to have some extra dynamic functionality. With Rails 8 running with defaults like SQLite and import maps there is little to be done for server config/installation
I prefer Markdown syntax for blogposts. It is the most "transferrable" way for blog content. Multiple other blog engines are supporting it, so if you want just to use something else, you can just take the MD files and put them there.
Ghost self-hosted in a container setup using a Hetzner VPS.
Planned:
Astro website with Ghost as a headless CMS, possibly using Obsidian or Outline wiki to draft posts and push to Ghost using an automation workflow like n8n.
When I did blog, it went through different tech eras. My biggest tech era was simply using Go and compiling the entire blog to a static binary and deploying with rsync/systemd.
I then moved from Go to Rust doing the same thing (static binary, all assets/html/etc baked in).
All self-hosted, no middlemen, just me, my own templates, formatting, code. I focus on design simplicity, lightweight pages, and being as accessible as I can. This means both visual accessibility(Every page is hand-checked with WAVE's browser extension(https://wave.webaim.org/) and Sa11y(https://sa11y.netlify.app/)) and technical accessibility(Low- or no-JS always, make pages as lightweight as possible).
To me, this is the ideal experience, where it's all stuff I've written, and even helped contribute to(I've been doing a lot of revising the Lume docs since the author isn't a native English speaker, been a relaxing and fun experience). Also, the entire design makes sense to me, and I haven't had that in the past with any other blog stack, so this feels like an end-game blog setup.
It works so well, that I’m working on oknext.io using the same stack .
Usually Sveltekit + Vercel for blogs and bigger projects.
I also use Listmonk for my newsletter and Umami for analytics, both open source and easy to run from Pikapods.
I wrote about my publishing process here:
When I'm on the go I don't really do any building, I'll add/edit a markdown file, push it to the remote in a branch. Cloudflare Pages will then give me a preview environment. If I like what I see, I merge the PR and it automatically deploys to "production."
I might migrate to Hugo or another static site generator at some point because I'm too lazy to commit the Ruby/Gem stuff to long-term memory and I'm not using it for anything else.
No database, nothing to manage. Just write, commit, and push to deploy.
A personal blog.
Stack is Django server and Sveltekit for the frontend.
I could have just used Django for everything, but I initially had bigger plans for the blog with lots of interactivity, I ended up just keeping it simple.
Family blog: Markdown files edited with Obsidian, site built with Quartz, hosted on Cloudflare
It uses Astro SSG, deployed to netlify. I want to eventually move to deploy on Hetzner VPS via GitLab CI/CD.
If something gets mathy I'll use LaTex.
Github CI/CD publishes my main branch to Azure AppService.
Blog: https://clintmcmahon.com
OpenBSD, httpd, acme-client.
Blog: rnikhil.com
Netlify & Cloudflare
D3
Python (to generate Markdown files)
All the blog posts are just written in markdown and would be easy to migrate, but some of the fancier stuff would be harder.
Luckily if you just write drivel like me, the free tier lasts a long time