No. Everyone used them because people editing the websites are almost never developers. Moving to some static site generator powered by git is cool until your marketing team constantly bothers your dev team to change a typo.

▲

GlitchInstitute 12 hours ago | parent | next [-]

you literally need 1 guy who will check marketing's AI Cursor commits of the changed typo. way cheaper than paying for the CMS.

▲

bonesss 11 hours ago | parent | prev | next [-]

Imagine if that dev team could create some kind of hyper intelligent interface to git so powerful even a marketer could use it…

Like a couple icons and some basic platform scripts for the 99% use cases of picking a branch, adding content, and occasionally saying “oops”?

▲

omnimus 2 hours ago | parent | next [-]

Whats with the git obsession?

Modern CMS workflows separate the content from the website code/app. The code is always version controlled and for content most CMSes have some sort of content versioning.

▲

sublinear 6 hours ago | parent | prev [-]

Or just hire people for your marketing team that have even a passing familiarity with web dev? They're not even that hard to find.

Keep those initial hires aboard and train up the rest. Get rid of the ones who don't want to learn. I mean really why do we try so hard to avoid bridging such simple knowledge gaps? It's not a big deal and we shouldn't shut people out of career development under all these obviously false excuses.

	▲	omnimus 2 hours ago \| parent [-]
		You are forgetting that the websites/CMS is often tool for the organization. It's not just about publishing the content. CMSes are used for writing and editing. Event spaces use their website for planning, chefs use it to generate printed menus. Static site generators are good for some usecases but too little or too niche for most cases.

▲

sublinear 6 hours ago | parent | prev | next [-]

And their websites are total dog shit and probably a legal nightmare waiting to happen because of it.

▲

sublinear 6 hours ago | parent | prev [-]

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 2 hours 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 an hour 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.