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.
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.
Yes. This is what we're discussing.
- 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.
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.
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.
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.
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.
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.
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.
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 can chsmge stuff in the terminal with vim or via VSCode remotely over ssh. But I can just as easily login to the admin panel and do stuff there.
What I like about Kirby for client work is that I can adapt the admin panel so easily that I can adapt it to my clients' needs and workflows.
And there is no DB in the background I need to maintain.
So I feel it always depends on use case and personal preferences in the end.
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.
I barely have enough time to just create content. I don't want to waste that time managing my blog deployment.
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.
See https://pilabor.com/blog/2021/05/building-a-blog-with-hugo/#... for details.
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.)
And no, Google's tag+name@gmail.com system isn't good enough - any spammer worth their salt will strip those.
I agree about the google part, although google mail is NOT my chosen provider any more :-)
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.
You'd be surprised how powerful and elegant some WYSIWYG editors are.
Last time I built a blog it was just Nginx, Django with some WYSIWYG editor, and Postgres.
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).
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.
I'd be more worried about one of those 10,000 dependencies in your React project doing something malicious :)
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.
Idk, the setup feels pretty clunky to me!
The curly braces everywhere when using logic in the templating sure makes things less elegant, for me.
I have a shell script called "blog" which just opens an empty template in my editor and then publishes it when I save it in non-draft mode.
Publishing is just another script that runs hugo and rsyncs the public folder to a vm.
I don't even use git, I don't care about versioning my blog posts.
The only thing I miss is comments, but nobody comments on blog posts any more anyway.
There are better ways. (Shameless plug alert) https://roastidio.us is a free commenting platform specifically designed to go with a SSG based blog.
