
Headless CMS Is Killing the Buy vs. Build Decision - encorekt
https://www.contentstack.com/blog/all-about-headless/headless-cms-vs-building-custom-cms
======
_bxg1
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.

~~~
shareIdeas
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.

~~~
theptip
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/](https://www.gatsbyjs.org/docs/headless-cms/) to render a static site,
based on dynamic content stored in the headless CMS.

------
wiremine
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.

~~~
forgottenpass
>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.

~~~
wiremine
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?

------
overshard
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.

------
mherchel
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](https://www.contentacms.org)

~~~
celticmusic
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.

------
notatoad
(according to a headless CMS provider)

~~~
jchw
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...

~~~
iosonofuturista
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/](https://strapi.io/) [1]
[https://getcockpit.com/](https://getcockpit.com/) [2]
[https://directus.io/](https://directus.io/) [3]
[https://ghost.org/](https://ghost.org/)

~~~
jchw
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.

~~~
iosonofuturista
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.

~~~
jchw
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.

~~~
iosonofuturista
Seems to be my impression as well. Thanks.

------
rossdavidh
"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.

~~~
winternett
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.

------
berns
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.

------
KaiserPro
"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.

~~~
zdragnar
"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.

~~~
Dylan16807
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.

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

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

~~~
jordan801
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.

------
rectang
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.

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

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

------
chmarr
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.

------
majkinetor
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.

~~~
Kimitri
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.

