which is why i am looking into CMS solutions to offload the content management to. but i don’t have to throw the baby out with the bathwater while switching to it, i can just set up the CMS and have the SSG pull things from it on build time, retaining the benefits of building a website with the SSG.
this authoring approach is just a better way of doing things relative to the “author posts directly in HTML” approach that is pretty natural to an amateur webweaver.
edit: btw, just to clarify, my website is fully static and i host it on nekoweb, so the build process is, in fact, a necessity for me.
There are constrained environments like neocities, github pages, and object storage where no server-side code may run.
There may be updates to PHP or to the CMS which might break compatibility. Static files will continue to work whatever the web host changes.
Speaking of flat file CMS, I actually think Grav might satisfy the original author’s desires since it fits the “unzip PHP into CGI-BIN” installation model. They call this Zero Installation.
I actually think we are close to being able to do maintenance free CMS with containers secured behind an independently updatable auth layer.
But this is what I still don’t get. What are those benefits? Because what you mentioned, having templates and partial files you can reuse and all that, are part of the CMS and you absolutely don’t need an extra tool in the chain. That’s the part I find perplexing.
Sure and in fact I did say that I can see situation where an SSG can be a nice tool to use. It’s not like there’s no place for SSGs. I just find it perplexing that so many devs decide to use them and they then end up writing these crazy posts where explain that in order to fix a typo they have to rebuild the entire site and there’s a dozen automated steps in between. I find that insane.
Fair but that can also be said about the SSGs because you go push an update and you find out something in your tooling chain is now out of date. But if you don’t plan to ever touch a site an SSG is great for that.
I agree I find the incorporation of GitHub actions into the web publishing workflow completely superfluous. Maybe it’s nice to have version control or to fluff one’s GitHub statistics. I actually wrote a Jekyll plugin to rsync my changes to my static hosting and I was really surprised nobody had already done that.
hey, i just like using git, what’s the problem with that. versioning is cool, and perhaps there is a way to improve build times by not touching what doesn’t need to be updated. i’m just lazy and didn’t get there just yet, but at least i only pay $3/mo to host my website, and that’s purely out of desire to support nekoweb.
This hasn’t been my experience because my drafts and sites build entirely locally and there isn’t any need to update my SSG. I’m actually thinking of moving my setup into a container so I can continue to never update it more easily.
Personally I split my setup in half. The structural part goes through GitHub and it’s setup to do push to deploy but that’s just because it’s convenient for me to have a backup copy of the site on GitHub. I could totally just old school ftp into my server and I do that often on many client projects.
The actual content folder lives on the server and I can edit it through the admin interface or I can upload txt files directly on the server.
But the GitHub step is totally optional and the cms also has a zero installation meaning you literally grab the content, plop it into the root of the server and the site is running
What if you update your machine? Does everything still works just fine? Because last time I used similar tools (and it’s been a few years) it was a pain in the ass. I update my Mac and all of a sudden half the things are broken because something got updated at the OS level
Updates aren’t a huge concern because my home server runs Oracle Linux, a free RHEL clone with fairly long term support. If my version of Jekyll and related gems stop working with the system’s Ruby, I’m fairly confident I could recreate the environment in a container. Most of my other applications are already running via Podman.
Oh ok so you have everything fairly under control. Make sense then. Because as I said last time I tried a few of these it was madness. So much time wasted chasing weird errors around.
it isn’t that bad if you just treat it like building html, especially statically. the templating still provides benefits, and the build step makes it flexible to have all the modularization work on static hosts like neocities and so on. static sites also tend to be more beneficial on the user side, with fast loads and all.
the cms you use in effect does server-side rendering, which isn’t actually that far removed as a concept. i could actually use astro that way if i had a server to deploy it on.
It does yes. And as I said, throw a cache in front and the performance is not all that different from serving static html. But the benefit is that you’re not tied to the SSGs build process and once the site is done you can focus on the content and that can be done anywhere. I don’t need to have access to my CLI to post something. Or have direct access to my server.
But you’re absolutely right that this is obviously not an option if one only has access to a limited hosting space. In those situations SSGs are awesome.
yea, i’m not opposed to SSR whatsoever. SSR and SSG both emerged in the modern webdev space as a solution to the problem of everyone doing client-side rendering because frameworks like React became trendy, which made the web slower and clunkier to use. [granted, PHP has been there all along, but it was deemed unfashionable and too many people shot themselves in the foot by making everything an SPA, so it kind of resulted in the reinventing of the wheel, but at least the tooling i use actually feels nice so i can’t exactly complain that they saw the light eventually]
[tbh there was no point in arguing about all this]
Yeah the whole SSR was such a weird thing to see “evolve” considering it was the standard for a long time before someone decided that we had to do things differently only to then go full circle and now we’re back on rendering things on the server again. But that’s just how things go I guess.
well, you can mix and match now, i guess. one of the selling points of astro is that you can also plug a frontend library into it to do dynamic stuff with it [something i haven’t used at all so far], so, in theory, you can have it pre-build static parts that don’t need updates, serve the site on a backend that builds/injects dynamic stuff on-demand, and then also provide client-side niceties the frontend libraries are good at, all packaged into a mainstream webdev-friendly software stack.
for me, the default templates with pre-rendering work just fine for my purposes, and i can also process my website to hell and back for maximum performance. my personal website is for entertaining my personal brain worms.
Ok, now, all that is obviously neat. But you can see why offering that as an option to someone who’s not a dev is a non starter and that’s basically what the article linked here was about.
And that’s also why I always found SSGs to be a niche tool. They require too much knowledge even to simply operate. Anyway, this is a fun discussion, thank you
Ooooh my gosh I agree so much with this person about the way SSG’s work. I already code a lot of stuff by hand and SSG’s feel like a step backward compared to that, they don’t actually feel ‘easier’. The way SSG’s get pushed is really annoying and the people that push them the hardest don’t seem to get how obtuse those systems can be.
Inevitably every time I bring up the problem with the lack of WYSIWYG html composers and how that’s a genuine detriment to the web economy as a whole, someone will bring up SSG’s as though they’re a suitable replacement. they are so very not.
Made a blog post about that some time ago where I listed what was available and their features and it really shows just how… depressing the sphere of WYSIWYG html editors, is.
I actually wrote a Jekyll plugin to rsync my changes to my static hosting and I was really surprised nobody had already done that.
