Having the visual interface makes heaps of difference, both for those that know code but get lost in too much text like me, or those with no code experience at all. It allows those with absolutely no code experience to do all the cool things on a website with no prior knowledge, while ALSO getting access to how those systems work and learn it passively by using visual indicators they’d likely be more familiar with. So I’m very glad the interface doesn’t hide what the exact code it’s using like things such as Squarespace does.
It may be convoluted to anyone that’s done it by hand and knows exactly what they’re doing, but for anyone that doesn’t know the range one has with CSS, all the options out there, how they all can be used and layered, the rules of each style and the order it must be applied in, or the maths involved for some of them, then writing it out is the convoluted approach and this is much more intuitive.
Oh totally. And as I said, if this is helpful to someone that’s awesome. I just find it amusing that after all these years no one has figured out a way to abstract out the css part in a better way and people are basically still writing css using a slightly different interface. But at a structural level they’re pretty much the same thing.
But again if this is helping people that’s all that matters.
A file-based CMS still has a build step. Something is taking your TXT file and translating it to HTML. Pretty much all file-based CMSs are SSGs underneath, with an interface on top and/or the build step automated for you (which many folks using SSGs automate themselves).
It’s not how I run my site, but, for example, if I had my site build as a Github Action, my experience on mobile would be the same as yours-- open a text file on Github, hit the pencil to edit. Save when I’m done. Site is updated for me.
I don’t know, it seems deeply counter to my experience that you’re more concerned about a SSG build process breaking than a server side rendered piece of software-- maintaining software of any kind successfully over time is essentially the same process.
Nothing wrong with SSR, SSG, or CMS’s in general-- they have different benefits for different people for different reasons. But your specific objection to SSG versus a “file-based CMS” feels like it’s coming from out dated experiences with where SSGs are today.
This whole post sounds like, “I want Wordpress, but not Wordpress.” to me. I’m not sure what the story is with his shared web hosting, but … I’m quite confident that shared hosting can support things like Wordpress and Ghost, it doesn’t mean their chosen host has a 1 click solution. But frankly, virtually every shared web host and VPS (why not run a VPS? I don’t know.) does have one click installs.
I don’t want to use Wordpress, but I also don’t want a WYSIWYG drag and drop editor for my site.
There was a rich market for this kind of editor for the web in general years ago, but it turns out it’s a crappy way to generate HTML, the market for folks who want that experience is quite small, and we have lots of other options that have learned, over time, better ways of dealing with webpages that meet more preferences.
I don’t miss Dreamweaver or Frontpage for a second.
Edit:
Funny enough, I decided just to search for shared web hosting to see the cost difference. It’s pretty minimal ($2 a month at the cheapest versus like $5 a month), but also, Namecheap directly advertises their WYSIWYG website builder as part of shared hosting: https://www.namecheap.com/hosting/shared/website-builder/.
I’d never use this, but sure looks like it exists. This was from the literal first link when I typed “shared webhosting” into Google (past the AI slop).
Yes but it’s a step I don’t have to manually trigger. That’s the entire difference. I come back to the same question: can you update a site running on an SSG while on your phone on top of a mountain? My experience says that the answer to that question is no. But maybe I’m wrong.
I could, if I paid extra for a tethering plan, had my laptop with me, and used my phone as a grossly ovepriced wifi hotspot. Just gotta type “make install”.
And again, it’s fine if developers want to use them. If they’re happy with their set up that’s awesome. If it helps them write more and publish more, that’s great. I consume the content on the other side of the browser and I don’t really care how that content got made.
But from the perspective of helping non devs getting started with a site, I think SSGs are the wrong way to go.
Definitely, at least in their current form. If there was a SSG as easy for a non-developer to use as a word processor, I might change my tune. The closest thing I’ve seen is Publii, and I had a look at that again last night because I was a bit frustrated by a kink in my RSS feed generation scripts.
You know what I did when I saw what I’d have to do to build a site with Publii? I said, “fuck this,” and fixed my damn scripts. It was easier than starting over with a rigid GUI that expected me to tick certain boxes in a particular order.
I’m not a typical case here, and probably not on the web in general. I figure that since I’ve got brain damage from exposure to Unix in college, I might as well take advantage of it.
In a weird way, there is. Micro.blog if i’m not mistaken runs on Hugo and by using that you’re essentially outsourcing away all the complex part of running the SSG and you can focus on the content.
If the SSG has been coupled with a headless CMS, yes. This setup is sometimes called Jamstack. But watch out: most of the headless CMS developers are not targeting hobbyists.
I think weblog.lol runs in similar fashion. Neither are what I had in mind, since they’re web apps and thus might not be usable without an active connection. It’s often easier to focus with wifi turned off, and for that you need apps that run locally and locally accessible storage.
Yeah very familiar with this concept. But as you said, headless is definitely not something a hobbyist would—and maybe should—choose. They’re not the intended target audience.
The thing I probably didn’t make clear enough, is that i’m aware that there are solutions to all the problems I’m flagging. I know one could set up all sorts of publishing pipelines to enable publishing on an SSG from anywhere.
Hell you could set it up so that you can send an SMS to a number and that triggers a whole song and dance that results in your site being updated. What I’m saying is that it’s not reasonable to expect non-devs to use and maintain something like that.
Fair. Now, what if tomorrow GitHub decides to change their TOS and they say that everything on GitHub is fair game for their AI training and you don’t like that and want to move your site somewhere else?
Now you have to rebuild your entire setup somewhere else and your UI interface will change overnight.
But I don’t want this to become an ideological war on what’s better because frankly, I couldn’t care less. I have my experience running sites both for myself and for friends and clients and based on the types of site I work on I have an idea of what works and what doesn’t but that’s just my experience. Other people working on different types of projects, in different environments, will come to different conclusions.
The answer to this is yes, and there are quite a few CMS options that operate on top of an SSG if that’s what you want.
I personally use Micro.blog (as I think you mentioned elsewhere) effectively because it means I have a very good (for me) mobile app to post to my Hugo site and can use things like MarsEdit or iAWriter, since Micro.blog adds a standards-based API end point on top of Hugo. I have run my own servers in the past though, and I’d probably run one of many small MicroPub servers to give me the same APIs before I’d run an SSR blog.
For me, it’s moving the boundaries of where something can go wrong. Once the HTML exists, whcih happens immediately, it doesn’t matter if 15 milllion people show up on that page, it’s essentially impossible for anything to go wrong. With any kind of dynamically rendered site, I could find myself with a webpage not working that I absolutely do not want to fix from my phone.
And what if your CMS of choice is abandoned not long after a major security flaw is revealed that has active bots crawling to take over your server as a bitcoin miner?
Any dependency on anything I don’t fully do myself may one day need to be replaced and I’ll worry about that then. I don’t think you’re being entirely fair or honest by seizing on GitHub being mentioned.
But of course, like a file-based CMS, my UI is really just a text file. So it doesn’t matter to me what happens once I hit save.
Any of a number of hosts and systems from Cloudflare to Netlify to Vercel to my own code which is effectively a cron job or a file watcher could be a replacement. Triggering a build step in a CI/CD like manner is a deeply solved problem with no shortage of choices.
I think what I’m responding to at least is some notion that a file-based CMS has some huge set of obvious advantages over SSGs where in my mind, they operate essentially the same way. Many file-based CMSes are SSGs, some are not. SSGs have advantages, so does having a CMS of any kind regardless of how the site plumbing works.
The idea that you even mention “with caching…” originally as though caching is less complex than typing hugo build somewhere or any number of “here’s how you setup an automatic build step” and as through caching doesn’t introduce potential complexity…
I think you’re kind of being dishonest (perhaps with yourself) about not understanding why other people may have different preferences.
And that is what you’re missing: I’m talking from the perspective of non devs. All the points I’m raising are from the perspective of someone who doesn’t do web for a living.
You’re looking at this from a technicaly point of view while I’m arguing UX. For the average user, logging in with a password and using a textarea is different than opening up a CLI and writing words in a terminal.
I’m not sure how else to say this. I even wrote it explicitly
I don’t care if people want to use SSGs. I don’t care if people want to combine them with a JS framework. I honestly couldn’t care less. But if my mother comes to me and says “I want a blog” my answer won’t be “Awesome, let me teach you what a terminal is”
But if instead you think that is in fact a reasonable answer then we’ll just agree to disagree because we have different ideas of what good UX for people is.
No, I don’t think that’s reasonable. But the reason the original blog post is unreasonable is because this is someone who rejects all of the very reasonable options for someone who wants to setup their first blog. They want self hosted on a shared host, open source, but not something like Wordpress or Ghost, two platforms with one click installs on virtually every host on the planet.
If you’re just someone looking to start a blog on your own site, it’s insane to think you’d start with either shared hosting or a VPS in the first place. Someone who is starting there is already not the person you’re talking about now.
The default answer for most people who say “I want to start a blog” is and should still probably be Wordpess. I often recommend other things like Bear Blog or Micro.blog or any of a number of things.
It’s absurd IMO to say “I’d give someone Dreamweaver before Wordpress” in 2025.
But anyone who’s start point is “I have my existing hosting and I need it to all be FOSS” is in a way different zone.
And I absolutely agree on that. I have no fucking idea what the person who wrote the original article is actually looking for because it seems like nothing is good enough.
Especially because between his options 1 and 2 at the beginning of the article there are a million different tools available. I even left him a comment with links to various tools.
I think the real point is simply that making a site in 2025 is, generally speaking, harder than a site in 2000 but that’s just because there are more things one has to worry about since the web itself is a lot dynamic and we aren’t all running 800x600 CRTs
But there are also a million tools that completely abstract away that complexity—for example micro.blog like you said—and people who just want a site should probably go in that direction rather than hosting WP on a crappy 3$ month shared hosting. They’d have a much better time imo.
But if someone is a dev, then the possibilities are endless. They can go SSGs, they can do flat file cms, they can go custom build scripts, they can code their own cms, they can host their own server at home.
I’d say there are in fact A LOT more options now, compared to twenty years ago. And that’s awesome.