Building a blog from scratch in 2022 using Hugo, Docker and a bit of Python

From the other side:

You can just update it straight from you terminal in your preferred text editor and push the changes. There's no need to open up a web browser, log in, and navigate through a web UI or clunky WYSIWYG interface.

But yeah, whatever floats your boat.

A proper editor for whom? What "proper" means is different to everybody. I already have and use a perfectly proper editor, and don't want to be forced to use another one just to write a few posts somewhere.

> Besides, you can just log in and change something. There’s no need to fire up a terminal,

Alright, but please recognize that this is a subjective point of view. My subjective point of view is the opposite: I'm already on the terminal, and I can just edit some files in there to update a post. There's no need to fire up a web browser, log-in using an ad-hoc login interface, and then use and ad-hoc editor.

That's why I prefer static sites. A proper editor is emacs, not some custom text box in a browser.

> There’s no need to fire up a terminal, type commands or deploy changes.

If you set up a CI pipeline then deploying changes is as simple as making a commit and pushing it. I don't fire up a terminal or type commands to make changes.

The problem with static tools os, they are only simple if you write 5-6 blogs (in total). Once you start writing more often, the lack of a good editor, styling becomes painful.

You can bash Wordpress all you want, its still the best way if you just want to focus on content without jumping thru a lot of hoops.

- security - a static site tends to have less vulnerabilities and security issues

- performance - there is nothing faster than a static site, if the webserver is configured properly

- maintainability - a static site has no database and is easy to version control, backup/restore and manage

> Then a proper editor feels nice.

And there is no one that prevents you from setting up "content management" for a static site generator... I tend to use my JetBrains IDE, but there is also Typora or MarkText for editing my files.

> It also lets you have more metadata without resorting to a weird data format.

Hugo supports external data files, and with little effort, even static site search. See https://pilabor.com/blog/2021/05/building-a-blog-with-hugo/#....

> Besides, you can just log in and change something.

You can use github actions for deployment, then you can just use github editor to change something.

Just my 2 cents. Maybe try it for a smaller site... it's awesome.

Static sites have their uses (and there's a surprising amount of people who do run more complex blogs as static sites, me included), but they're a very different design goal.

The main thing that makes most traditional CMS systems nearly unworkable for me is the combination of a data lock-in and the inevitable mess that content + widgets ends up becoming in the database. I'm sure everyone has their own horror story with the Wordpress site that has 20 plugins and one decided it stopped playing nicely with the APIs and now you're untangling a mess set up by a secretary 3 years ago who didn't leave any notes (theoretic example).

Static sites are at least good at that; you can separate the core content of your site (blogposts/images/pages) from the layout and visual logic. Personally I've swapped between three different static site generators for my blog over the past 7 years (usually because another offered better functionality or just had a cooler CSS theme I wanted) and the process usually didn't take more than an hour or two.

Meanwhile, Wordpress took me several days to upgrade to a new version because a bunch of older extensions needed manual hacks to keep working.

On another degree, since I self-host my blog, it's quite nice to not have to bother with a webserver besides Nginx. Running any sort of webapp is a joy for security (and server usage), while just serving HTML/CSS/JS from a folder is something webservers are already pretty good at doing quickly with not that much of a load.

That said, there's a bunch of advantages with CMS systems too; accessibility being the big one. These are systems designed to make it easy to put up a new blogpost while not having to worry about layout and styling, and that makes them very accessible to the layman.

I think that's often because people are most excited about writing about their blogging software when they have just built it. But there are a lot of bloggers (ex: me) using static site generation who've been doing it for years and have hundreds of posts.

I barely have enough time to just create content. I don't want to waste that time managing my blog deployment.

I've started with hugo and editing in IntelliJ but eventually switched to Ghost, when I needed to automatically cross-post my content to social media.

Zero regrets then.

Github has supported creating PRs directly in the browser for years now. It's a pretty good editor with support for Markdown previewing and such. Depending on your needs, Github itself has been a "proper editor" for SSGs for a long time now. Now that Github Actions exists and you aren't restricted to only Jekyll as your SSG for auto-builds on PR merges, it is even better than before. (Drag and drop for things like images into PRs on the web has also worked to various extents in the Github web UI for some time.)

With github.dev (and the . shortcut) you can even create a PR in VS Code on any computer with a web browser if you want even better Markdown previewing with VS Code extensions and Settings Sync. (Even things like uploading new photos, you can drag and drop into VS Code on github.dev! Some of the domain specific data editors for your CMS needs you could potentially build custom YAML or JSON editors as VS Code extensions.)

I don't think there is necessarily a "hatred" for classic content management systems, but the tools have "converged" somewhat. Github is a reasonably good CMS with powerful web editing tools (especially github.dev) at this point, but more importantly the "version management" tool for the "Github CMS" is git so you know that you'll have strong auditing of content changes over time and also content reviews (code reviews, PRs) and things like that which other CMS tools do to various extents, but git was built to do specifically.

Or just add the address. I have a mailto link (no obfuscation or anything) on my page (that nobody visits anyway, but I believe Google has it). I think I have never received a single mail to this alias, spam or otherwise. (YMMV of course.)

Off-topic but I’ve found that it’s a lot better to just use a spam filter than to constantly try and hide my address. I’ve signed up to countless services that have gotten hacked and exposed my email, so the cat’s out of the bag - my email is out there. There is no chance of avoiding spam.

A bit like using windows. Some prefer Mac, some *nix.

Some are put off by php. Some don't need/want a SQL DB in the background.

Personally I like Kirby CMS (I actually don't mind the licensing fee). I am more productive and more flexible in it than in any other system I ever used. For personal and client projects.

But in the end it is often a choice of preference and that is fine.

Also, the WP plugin ecosystem is almost as "dirty" as mobile apps are - few things are really open source, there's "please give us 5 stars" popups everywhere, fishy data collection, constant uspelling to premium offerings... It's just not a good experience to work with, unless you code most things yourself (in which case you will be absolutely disgusted by most of the API).