There is no way around needing a developer (and a lot of testing) to "just fix a typo".

First the typo is discovered and it changes the length of the text. If it's more than a few words this becomes a layout problem. You will have to nudge things around a bit, but now this also fails accessibility testing because the alt text or aria labels were overlooked or font size or line height were changed. Then the marketing team reviews it and change their minds yet again and people are stuck in a hellish loop of tiny updates that start breaking other things through runaway inconsistency. Of course it's worth noting that the typos almost always originate from that same marketing team.

This is the nature of coding websites by committee. A CMS just makes this worse by getting in the way of proper versioning, and as a bonus launders all the blame onto developers.

It's far from naive to just use git and set up a CI pipeline to copy your static build onto a web server. This is done all the time by anyone with common sense and familiarity with web dev. It "just works" so well that it remains under the radar to anyone new to this and looking for solutions. The CMS grift continues as their sales team insists their product is the best solution.

▲

omnimus a day ago | parent [-]

I see you had a bad experience with CMSs but in reality vast majority of content websites use CMS and are for entities that have 0 developers. There is simply no way for them to use some homebaked static site generator script that you personally see as easier solution.

And those sites can be pretty great. The pace of dev is just different. Usually with big initial investment and then some bulk fixup in few months or a year.

I am actually not sure why to hate CMSs good modern ones are basically sweet web framework with highly customisible admin panel.

	▲	sublinear a day ago \| parent [-]
		If I see an admin panel I have to assume this would be server side rendered? I would never agree with that, and you're missing my point. I am not suggesting any framework at all. I'm 100% serious when I say that you will inevitably need a developer. As the requirements become more refined they're going to wind up writing everything on those web pages from scratch in plain CSS, HTML, and JS. Every attempt to avoid this is just wasting time and pissing everyone off regardless of their stake in it. As an aside, I've knocked out at least half a dozen of these projects that I can remember in the past decade and I'm not even really a web dev. Doing it my way was faster, cheaper, more accurate, and way less long-term maintenance. They were all for significant clients and are still running today. When they need maintenance it's done by developers who can effortlessly knock out the tickets because there are no dependencies in the way. There is no dedicated team. The client managers just toss some stories into the backlog and it goes into the next sprint assigned to whoever has the time. A merge in gitlab updates everything and we're done and everyone is happy and nobody ever has to think hard about this. We just write static pages from scratch and avoid all server side rendering. There is no backend apart from maybe a few REST calls where needed and they're implemented as separate node apps. Again, minimal dependencies apart from Express and misc utils. They could probably be lambdas in AWS if we were allowed to do it that way. That's how non-existent the backend is and how static the pages are. Am I just living in a corporate fantasy and don't know how good I have it? The only part where I think we agree is that these projects should be low tech, but we have very different ideas of what that means. Also, the part where I mention marketing being a shit show clown circus is still true, but avoiding a CMS keeps that noise away from devs where it belongs while still delivering a good result. This assumes you have devs. If you don't I still think you need at least a single web contractor and would be better off avoiding a CMS or any other shitty framework. That's all I'm saying.