Maybe I'm nitpicking, but you don't have to use the front-end templating in WordPress if you don't want to these days. It has a REST API, so you could use it as a headless CMS.

Postlight has a pretty cool WordPress/React starter kit https://postlight.com/labs/wordpress-react-starter-kit

Fair; I made a clarification

No?

Headless = DB/content is separated by an API from the display/front-end/output and possibly a data entry-UI

The benefit: you can swap front-end and data entry UI to your liking and have no lock-in.

Added bonus: separating by an API forces cleaner code and more documentation

Comparing it to wordpress (ignoring how it can possibly be used headless nowadays too): If wordpress doesn't do the trick for you anymore you have to migrate all your data, rebuild the front-end, teach staff a new UI for data entry and all that possibly just for something like a bit more performance.

For my blog, I actually just edit the database directly and have triggers setup to handle all of the various associated changes.

But I’m weird like that. :)

Yeah, as a technical person there isn't much point to using a CMS unless you want a WYSIWYG editor or something. I suppose it could help ensure data integrity if you're using a noSQL DB.

Yes. New buzzword, and a strange one. Just putting the same content on multiple platforms.

Making your content work on a watch, and on nonexistent AR glasses, probably isn't a major priority yet.

The goal is to use less skilled labor?

I can't help but to think back on my experiences, that's going to make a terrible program.

The goal is to decouple the model (content) from the view (the apps that render the content).

For example, in the old way of doing things you might use Wordpress to host your corporate blog. But what if you want to put that content into an email too? Or an app page?

In the headless-CMS world, you write the content and store it in the headless-CMS DB. Then any client that wants to render it (your blog site, your webapp, the backend server that's sending email messages, etc) can pull the latest version of a particular piece of content, and render it.

A good example use-case is using something like https://www.gatsbyjs.org/docs/headless-cms/ to render a static site, based on dynamic content stored in the headless CMS.

I might not have been clear; it's for nontechnical people to manage data in a database. For example, writers on a blog site.

Edit: The original version of my comment which this poster was replying to, said something along the lines of "a GUI that lets nontechnical people manage a database", which was ambiguous.

No, the goal is to allow people with a different set of skills (content creators) to create content, even though they don't have database or engineering skills.

I'd used systems like this at every game company I've worked for to allow writers, game designers, and translators work on content without having an engineer in their dev loop.

> A Headless CMS is a GUI that simply lets nontechnical people manage content in a database.

This is exactly what a headless CMS is not.

A headless CMS is a content management system served through an API.

Thus, legacy render-based CMS like Wordpress / Joomla where the database is completely tied to framework will decrease because of how heavy, poorly flexible and competitive they are from every point of view.

It’s also important to note that your CMS isn’t bound to any render-full GUI like WordPress but instead can be managed from anywhere as long as you have the APIs for it.

With serverless database having exploded in popularity over the past 5 years it makes 0 sense to use any of the solutions like those.

Takes Firestore/DynamoDB /Cosmos, add one collection named « Article » and you have a rudimentary CMS to store articles with a fully operational CRUD served over HTTP. Works anywhere and will cost you 0$ once it’s cached with your favorite CDN.

Did you really read the article or did you just commented assuming what was in it ?

> a content management system served through an API

That phrase doesn't make any sense.

> legacy render-based CMS like Wordpress / Joomla where the database is completely tied to framework will decrease

That's exactly what I said.

> It’s also important to note that your CMS isn’t bound to any render-full GUI like WordPress but instead can be managed from anywhere as long as you have the APIs for it.

I think you may be getting the front-end GUI and back-end GUI mixed up. A headless CMS omits the front-end GUI, but includes a back-end (content management) GUI. It admittedly also includes a light CRUD API over the database, so it's slightly more than I initially said, but not much.

Here's a more in-depth explanation. Maybe this will clear things up for you: https://css-tricks.com/what-is-a-headless-cms/