Headless CMS Is Killing the Buy vs. Build Decision | Hacker News Reader

Headless CMS Is Killing the Buy vs. Build Decision

contentstack.com

51 pointsencorekt47 comments

Cutting through the deluge of marketing-speak:

A Headless CMS is a GUI that simply lets nontechnical people manage content in a database (as opposed to traditional WordPress, which included front-end templating logic). These aren't super new but they are good. They're extra good in a world where you're increasingly likely to have multiple front-ends for a single application.

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.

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.

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.

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.

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.

> 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/

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

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.

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.

Some background: I spent 6 years building customer Django sites; for the last 3.5 years I've been doing IoT.

For many organizations, a headless CMS are going to be more and more of a requirement, as more content is delivered to non-web or and non-mobile contexts. Some examples:

1. Shipping content into voice or chat bots.

2. Shipping content to embedded devices like touch screens on home appliances or factory machines.

Going beyond the separation of the data store and the presentation layer: A lot of people haven't yet felt the pain of using traditional relational data for these nontraditional channels. In voice and chat, for example, a knowledge graph is much more helpful than a bunch of relational data (or at least alongside relational data).

On the flip side of this all: my wife runs a blog, and I doubt she'll ever need more than Wordpress.

So, as usually, pick the right tool for the problem.

>A lot of people haven't yet felt the pain of using traditional relational data for these nontraditional channels.

Haha. Wow. I didn't know it was already time for another anti-relational hype cycle.

You misunderstand. Relational isn't going away, it just isn't a solid fit for all forms of knowledge. Google's knowledge graph is a good example of a what I'm talking about, and that's about around 2012. It's used to power the assistant, for example.

It's similar to how data warehouses aren't going away, but a lot of companies aren't trying to shoehorn _all_ their data star schemas.

So if "relational databases aren't for everything" is hype, sign me up?

I just skimmed this article since it does seem like a bias post from a Headless CMS provider however almost all transitional CMSs that you can use/build also provide the features of a Headless CMS. WordPress has a REST API built in, Wagtail has an API built in via django-rest-framework. I'm sure if I looked almost every other CMS has solutions for this too.

The build vs buy decision is still straight forward. Does the headless CMS solution I'm buying provide all of the features my project will need with room to grow? Yes? Cool, why bother building it. No? Looks like I'm building my own on a "reliable framework" (tm) already used by hundreds of thousands of sites.

Keep in mind that many FOSS CMS's can also do headless. Drupal has very robust JSON:API support (as well as GraphQL through a contrib module), and WP has its own Rest API. Drupal also has a distribution specifically geared toward headless/decoupled: https://www.contentacms.org

There have always been headless CMS's, the flavor of CMS that really means "web CMS" has always been a single category of CMS.

What this article is really saying is that the web CMS is going away, leaving content CMS's with web API's as the king. What you're saying is that Web CMS's are morphing into content CMS's.

Which is great, but I don't really see the point of the article. None of this is really new.

(according to a headless CMS provider)

I don't have any data to prove my point, but I have the feeling that more and more companies and individuals are using static generators for their public blogs/marketing/ corporate websites!

My immediate reaction as well. Headless CMS seems like a good idea, but I would not want to outsource the core of my own business if I were in the content biz. And honestly, if it were that advantageous, there’s no good reason there can’t or shouldn’t be open source headless CMSes just as there were headful open source CMSes...

Strapi[0], Cockpit[1], Directus[2], Ghost[3].

Just to name a few open source headless CMSs. There are a lot more where they come from. And you can always add a JSON or Graphql module to your wordpress, drupal, etc.

[0] https://strapi.io/ [1] https://getcockpit.com/ [2] https://directus.io/ [3] https://ghost.org/

I used Ghost as a non-headless CMS and had no idea it could be used as headless. Neat!

> And you can always add a JSON or Graphql module to your wordpress, drupal, etc.

That’s a great point, especially for migrating. I’ve worked where we had a huge nearly unmaintainable Drupal instance and it could’ve probably saved us a lot of time to just jam a GraphQL API on-top instead of trying to synchronize everything to another separate database. (Many lessons learned from that experience.)

My biggest gripe with most CMSes is how they handle organization (tags, categories, hierarchies...) as it always seems to come off as too flexible in some ways and not enough in others. Oh, and scaling, but at least you can always cache everything.

I'm considering using Ghost for a project.

A part as the usual CMS, but also to drive a portion of a mobile app, and in that case its using essentially the headless part.

Since you have used it, any caveats I should be aware?

Thanks.

I haven't upgraded to the latest version lately, and mostly just use it for more or less casual blogging so far. But, my experience has been positive. The editing experience is pretty good.

I think for bigger, more complicated sites, it is probably still lagging behind the old guard in raw features. But, on the other hand, it is a breath of fresh air for what it does do. So, if it supports the features you need, it seems like a solid choice to me.

Seems to be my impression as well. Thanks.

"the personalized content that today’s always-on consumers crave..."

No, they don't. You want to sell it, which is not the same thing.

Too many bloggers pushing headless are presenting the idea that traditional CMS'es aren't also pushing forward. Traditional CMS solutions are not dying, even the infrastructure (processing and resources) are moving forward fast to improve everything as well.

There is a constant industry need to change CMS and app configuration without pushing code, this is a big thing that Headless can't yet manage well without a ton of extra development work, and with that you're practically building the same solution as a CMS from scratch. There are always different use cases for each scenario/solution, and as long as vendor supplied solutions are around like ServiceNow, PowerBI & SharePoint, traditional, and especially Open-Source CMS solutions aren't going anywhere.

Headless also requires a lot of work to account for unstructured data, which should, as a best practice, be fixed in your data source. Too much can slip through the test/fix gate when a bunch of customization is done to fix or re-format data at the front-end layer. Big problems occur when multiple front ends are independently displaying from one data source whenever someone tries to reformat, change, or fix data on the back-end...

As a promotional practice, trust worthy company should refrain from disparaging viable alternative methods of implementation, they should stick to promotion of their own method and speak more-so to the benefits of a well thought out solution rather than saying that competing methods are "dying" IMO.

What arrogance! It may be that headless technology is an alternative to traditional CMSs, but at $ 3,500 / month I don't think it's your product that is killing any decision.

"headless" I don't know what field they are operating in, but in the world of financial publishing, thats called multiplatform.

Now, the thing that they gloss over, and the actual hard part of all of this, is not the headless bit, its getting your content in order.

Organising your content so you can syndicate it to people that want it is really, really hard at scale. Its almost never a technical challenge, it a question of selling and making sure people put the right tags on the right content.

At "Large Financial News company" The basic idea was there, the execution was lacking though:

GUI(in fat client and web) -> content database -> frontends

When stuff was being redesigned, most of the effort was in the front end. The content already had an API, it was polluted by politics and idiot architects, but it was there.

"Headless" is a pretty old term in IT, basically for anything that operates without a dedicated monitor or view as part of the primary access.

For instance, Chrome not too long ago released the capability to run headless. Headless servers are hardware servers without a physical monitor, keyboard or mouse (i.e. you typically interact with it via ssh or RDP). Microsoft has also used the term for windows servers and embedded devices for years.

But that's not what it's being used to mean here. The 'head' for a CMS would be the interface you use to edit it, which is orthogonal to the intermingling between the data and the frontend templating that they're actually talking about.

Thank you for giving such an indepth summary of headless and all its meanings. I'm glad we are all now up to speed.

However as you've highlighted, its not whats going on here.

I will accept:

o Content-as-a-service

o multi-play publishing

o API driven syndication

o multiplatform publishing

but "headless"? Its a half arsed term to supposedly differentiate them in a crowded marketplace.

What a poor quality article, it doesn't have any explanation what a headless CMS is.

Not sure who the target audience is, but I found this as I needed clarification myself. https://www.storyblok.com/tp/headless-cms-explained

I would imagine the writer presupposes the reader already knows what a CMS is, and is trying to sell the reader on adopting it.

headless CMS

Which, is kind of silly. Most of the clients we have, like using Wordpress, because they are non-technical and can still have an extremely powerful website, without that.

If I am going to use a headless CMS, I'd probably just rather write my own program completely. Nothing is worse than being in the 9th inning and realizing that you have to do a major infrastructure overhaul because the program your using doesn't natively support a feature.

I was briefly director of CMS at MLB Advanced Media in the early 2000's and I found this article and especially its diagrams to be unintelligible.

What I generally need is a CMS that requires minimal maintenance over the time frame of a decade or more. Static html generation, doesn't have 50 bazillion dependencies, written in a language that isn't moving fast.

Actually, what I really need is a stable, portable file format, since editors will continually bloat up and die in the natural life cycle of software projects.

Hm, stable file formats... LaTeX doesn’t seem to be going anywhere ;)

wiki?

What I would like is the opposite : a front-end that adapts itself to the any model. You give it data, and it organizes information to display it on a screen automagically, to be explorable, no matter the number of dimension in the data

Interesting that there's lots of languages supported, but Python is conspicuously absent. Why no love for Python, Contentstack?

Also, article is more an advertisement than anything educational. And here I am making the situation slightly worse.

SSG FTW!

- Cross platform

- Best performance

- Ultimate security - no database or server code

- Use awesome development tools for funky stuff

- Easy to migrate to another thing

- Easy to experiment with in development settings

- Have small services for dynamic stuff that can be sepparatelly developed (comments, profiles etc.)

Its good to see era of Joomla and friends is coming to an end.

Well... There are lots of sites that just cannot be built using SSGs. Extranet and intranet sites need to work dynamically, as do other sites with user profiles and deep personalization.

Reply on news.ycombinator.com