I don’t understand the hatred for classic content management systems. Every time I see those static blog posts, they’re for barebones blogs with a dozen posts.
These things fall flat when you need to regularly update the content. Then a proper editor feels nice. Formatting text and uploading images doesn’t break your workflow.
It also lets you have more metadata without resorting to a weird data format. The guides on my website have sources, glossary entries, categories, images and widgets. Describing that as text would be awkward.
Besides, you can just log in and change something. There’s no need to fire up a terminal, type commands or deploy changes. Just click save, from any computer with a web browser.
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.
Of course this point of view is with common developers, so I understand that view.
People who are content editors in newspapers, magazines, etc. would highly likely use Wordpress, Ghost or even Substack.
In the end, use whatever you're comfortable with, I always go with, "can I extend this" or "will this save me time?" and Wordpress/Ghost almost always gets chosen.
Indeed, emacs and vim are very “proper editors” in this context, which is where having your posts stored as flat files, as is done in most static site blogs, really shines.
I understand what you are saying... and you are right for most of it. You have to change your mindset a bit to use a static site generator. But you should keep in mind that "classic content management systems" have some major disadvantages, that are real:
- 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.
I have made tons of headless CMS powered static generated sites. And I've made personal mark up powered sites. The markup is fun if you are the only person who will ever work on it, otherwise I recommend hooking up a proper content editable site.
It depends on your workflow and preferences, I guess.
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.
It depends (as with everything) on your goal and purpose.
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.
Because the complete lack of maintenance alone more than makes up for the lack of a login to change content for me. Not to mention I still have an editor and can log in to it to change content, it just commits to git instead of using a complicated backend.
Most static site generators are much easier to customise than common GUI CMSs. I use nanoc, which is basically a build system with some website-oriented builtins. I wrote a snippet that replaces images with responsive ones with srcset. Sure, there's probably a Wordpress plugin for that, but it's not 50 LOC.
> Besides, you can just log in and change something. There’s no need to fire up a terminal, type commands or deploy changes. Just click save, from any computer with a web browser.
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.
yeah, same here. After trying a dozen of these "simple" static hosting tools, I always go back to Wordpress , and recently, Ghost.
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.
My personal blog has almost 400 posts[0] and I'm using Jekyll (another static site generator). I find writing in my code editor to be the path of least resistance. It lets me quickly write drafts as I'm working without breaking my flow and writing Markdown feels good. Jekyll supports live reloading too so after I save a post the browser auto-reloads with the new content in about 2 seconds.
> Every time I see those static blog posts, they’re for barebones blogs with a dozen posts.
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.
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.
Beware, I will shamelessly plug my product here but this is exactly the problem I am solving with my tool. Why not have the best of both worlds? The easy-of-use of a CMS and the speed of a static blog. This is exactly what I do with https://panakit.com
I mean, a CMS adds complexity and hosting costs when enough people just want to get those dozen blog posts out there and don't care about the rest. Not like people don't know about stuff like WP.
I hosted a WP blog for years. It hit the front page of Reddit multiple times and #1 once and it never cost more than $10/month. These days, the same blog could easily run on a $5/month VPS. You could also host a WP blog for free, using their hosted service.
Even as a non-programmer back then, I didn't find the complexity bad at all. It was certainly a lot less than what's involved with the OP's setup.
I've gone from using WordPress to static sites and back again because I missed having all the features that WP offered. Even Ghost is simpler but still nicer than any static site I've created.
While this is a good tutorial, I don't think that docker or python is even required. The main benefit of hugo is, that it comes as a single binary for every OS that can be downloaded and executed without any dependencies.
The contact form is cool, but for a simple blog I think that it is enough to just provide an email address, which is obfuscated as SVG paths and therefore not extractable. Although it is nice to have a real contact form to hide your email address from visitors.
You should also consider using a partial for the render-image.html to be more flexible in templates.
> The contact form is cool, but for a simple blog I think that it is enough to just provide an email address, which is obfuscated as SVG paths and therefore not extractable. Although it is nice to have a real contact form to hide your email address from visitors.
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.)
At the very least, I really suggest you use an email alias that you can filter or burn by if necessary. If you ever post a link to your site to something like HN or Reddit, you absolutely will get tons of spam and once you're on a list somewhere, you'll never ever get off of it.
And no, Google's tag+name@gmail.com system isn't good enough - any spammer worth their salt will strip those.
Absolutely... usually the site is hosted on a domain "domain.tld" and i tend to use something@domain.tld as redirect, which may be redirected or filtered.
I agree about the google part, although google mail is NOT my chosen provider any more :-)
> obfuscated as SVG paths and therefore not extractable
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.
Yeah that's correct, but the "better use redirect emails" comment above is also valid. If you keep your email as private as possible, it might reduce the amount of spam, which is usually a good thing.
Almost spit out my coffee when I saw Docker and Hugo together! Still, I like the self-contained nature of this with the Python form handling.
For anyone that wants a simpler setup:
Netlify forms [0] can handle form submissions, 100 per month (per site) on the free tier, just add "netlify" to the form html. I have some sites that use this and I get very little spam. Netlify also gives you a CDN.
Caddy [1] is a great webserver and can reverse proxy, serve content, and does automatic SSL. Configuration is pretty easy, although V1 was a little easier. I have it running a Django site right now and probably wouldn't even bother with nginx again. Traefik AND nginx for a static site seems pretty heavy to me.
What's your solution for WYSIWYG Image uploading? Does the editor handle the image upload + processing? and where do you store the images? I have tried a project with similar requirements but stuck on the WYSIWYG editor choice.
I used django_ckeditor and ckeditor_uploader for a very simple site I built for an academic where they needed WYSYWIG forms, it worked a treat and easy to integrate. It's used by Django CMS too.
The whole docker setup just to accept contact form submissions seems like overkill. On my blog I’ve got a form that posts the data to a lambda which sends me an email. The blog is built using Hugo and served from s3 so my setup is completely serverless.
There is nothing that comes even close to DX of using something like Gatsby + MDX + <any_cms> for blogs. Simplicity and options it gives you is amazing. Deploy that to any CDN and you are golden.
Or if you want to try something new and skip SSG you can try remix.run. But you loose Gatsby graphql data model, which is ok depending on the usecase.
There's a huge maintenance burden with WP sites and many things break if you dump them to static files.
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).
"There's a huge maintenance burden with WP sites"
I can't subscribe to this notion. WordPress can run almost unsupervised on auto update. Perhaps when you install 40 poor quality plugins things will break between updates, but with a few base plugins such as Advanced Custom Fields Pro + Custom Post Type UI you have no such problems.
Basically there is nothing wrong with WP. It is maybe too bloated for some. Too riddled with insecurities. Too far used (and therefore an interesting target).
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.
Have you played with https://pods.io/ ? It does most of what ACF does and also lets you create custom post types through the UI. Curious about your thoughts on that vs ACF Pro and Custom Post Type UI.
These things fall flat when you need to regularly update the content. Then a proper editor feels nice. Formatting text and uploading images doesn’t break your workflow.
It also lets you have more metadata without resorting to a weird data format. The guides on my website have sources, glossary entries, categories, images and widgets. Describing that as text would be awkward.
Besides, you can just log in and change something. There’s no need to fire up a terminal, type commands or deploy changes. Just click save, from any computer with a web browser.