It’s Raining Headless CMS Systems

There are two competing dynamics in the world of JAMstack. First, there’s the idea that JAMstack is the approach of choice for creating lots of different applications, beginning with marketing sites that are essentially just five pages (about, contact, products, solutions, resources) and continuing on to blogs, and from there to sites that are interactive, consult data through APIs, and so on. In other words, static is the best current choice for making websites. The second dynamic is that, even for those basic marketing sites, decoupling the content management is a good thing.

Building a static site draws most of what ends up live on the website from source code files and, in the simplest approaches, in markdown files. You can build a perfectly snazzy blog just by writing all your entries in the markdown format and storing them in the right directory.

If all you do is put your content into markdown files, you’ve still effectively decoupled the content from the presentation, because you could copy that directory full of blog entries to some other system and present it using some completely different application.

The CMS-as-a-Service Upside

It’s clear why this would be attractive compared to, say, WordPress (the defacto competitor to JAMstack as a whole). In WordPress, you use the site itself (albeit in an administrator console interface) to create and edit your content. Normally, you then serve it up using the WordPress application and, should you decide you don’t like WordPress anymore, you are more or less stuck. (As an aside I’m obligated to say that it’s now easily possible to just use the back end of WordPress and then use something else—Gatsbyjs, for example—to serve up the files to website visitors.)

With a headless CMS, you can theoretically change horses midstream by changing which horses are presenting your web pages. In practice, there just aren’t a lot of sites around that have actually done this—changing from one static site generator (SSG) to another and running the new setup without interruption using data from a third-party headless CMS tool. As long as we’re basically talking about blogs, there’s no reason to think this isn’t readily done, but in some ways it fixes a problem that site builders may not be entirely aware that they have.

It may be increasingly valuable to change presentation (and delivery channel—let’s not forget that this CMS may additionally serve up tweets and Instagram posts) and keep the existing CMS, but one thing that’s immediately attractive is that headless CMSs can offer high-quality user experiences for content creators using the system, plus it’s possible in most of the current platforms to customize things like approval workflows. There’s plenty of room now for anyone who can provide a fantastic content creation and workflow experience. For whatever reason, traditional CMS UX has been something of a backwater. WordPress is probably as good as it ever gets in the old school, and while it’s capable of getting the job done these days, it’s certainly not flawless. If you doubt this, just ask a typical WordPress user how to set a paragraph within a post with a hanging indent. (Hint: there’s not actually an option for this, though you can do it if you tweak the CSS).

Headless CMS has into its own and you can get every flavor you can imagine, except the one where you run WordPress on the front and a different headless CMS on the back (probably someone’s working on this, though it’s not clear to me what the gain from it would be).

There are lots—probably too many—variants on the headless CMS idea, most of them recent startups but a handful of them dating back a half dozen years or so. The list assembled for this article was at 71 companies when this was prepared. The current list is over in our New World Map.

PeakZebra will take a look at all the options that seem to have some measure of traction, but not in this article. We’ll tackle of them in turn, beginning with those that have early market share and influence.

In this article, we’ll look at the concept and capabilities that most or all of the contendors provide, with details and screenshots coming from Contentful, which is the most widely deployed of the headless CMSs. It’s not an endorsement of Contentful in particular, just a reflection of how this service is representative.

JAMstack and GraphQL

To be clear, when people talk about a “modern web stack” in current parlance, they are usually referring to a site written in a JavaScript framework like Gatsbyjs or Nextjs, with content retrieved by way of a GraphQL interface. This setup is appealing for lots of reasons, but it’s not the only way to get things done and plenty of options out there support RESTful APIs.

An early draft of this report tried to sort between offerings that support GraphQL, but it became apparent that practically every one of the services we were looking at were adding support for GraphQL so fast that it was pointless to make the distinction. The problem for organizations looking to adopt a headless CMS strategy is going to be having too many choices. Most of them seem likely to use GraphQL, which will still leave them having to choose between dozens of CMS services.

Contentful is one of the founding companies in this space, having released it’s first beta in 2013. The focus then was on delivering content from one source to multiple targets and frameworks. Obviously, that remains part of the headless CMS value proposition, but the emphasis has shifted over the years towards fitting into the JAMstack ecosystem. According to a TechCrunch article back in June (when Contentful raised $80 million in Series E venture funding), 28% of the Fortune 500 use Contentful. This kind of penetration makes them a heavy hitter in this space.

In terms of how the service works: once you’ve established an account (and they have a free account option for dabblers and zebras), you create one or more “spaces,” within which you create content types. From a developer point of view, this is the equivalent of defining a “struct” variable type in C or, roughly, of creating a class in JavaScript. From the database point of view, it’s the equivalent of defining the fields in a table (and, of course, that’s what’s going on behind the scenes in Contentful).

For the straight-up, no-frills blog application, you’ll create a content type that spells out the data that’s stored in a post. You’ll want a title, might want to be able to store a user-specified slug name, no doubt will want a publishing date, and will need a bunch of text for the body of the entry.

An important difference between defining a database table and creating content types in Contentful is that content types may wind up defining something that you’d do with multiple tables in a SQL database. In the example workspace that Contentful gins up for you when you create an account, you have a set of content types for a learning site, with lessons and courses that include lessons, and so on. In this scheme, there’s a content type for Categories, containing two fields, as shown in Contentful’s interface here:

The JSON preview tab here shows you what you’ll get if you do a meta query to get a description of what I think of as the table definition (though content types don’t talk about it that way). The sidebar tab is interesting: it lets you configure what widgets will populate the right rail when your users are editing this type of content. The entry editors tab lets you replace the editor itself.

So the page where users will enter and edit your content has a main window for the editing and a right sidebar, like this:

It looks, in fact, rather like the back end of WordPress. I’m not sure whether that’s because this is the way this sort of editor page tends to look, or whether it’s because Contentful made a conscious choice to make something WordPress refugees would be familiar with (which would have been, honestly, a smart product design choice).

Two things to note here:

1. Remember that you can define lots of different content types and arbitrarily change out the tools available as well as the editor used for those types. There’s enormous underlying flexibility, in other words.
2. Funnily, this actually looks like what’s now called the “Classic” WordPress interface. The new Gutenberg UI in WordPress is based on the idea of serially adding blocks of various types. Gutenberg, in turn, is arguably running a bit behind the design principles of the popular add-on theme/editing tools in the WordPress ecosystem, like Divi and Elementor. They have both the concept of blocks and support for (within limits) dragging and dropping them. Furthermore, they are WYSIWYG. My point here is that Contentful, along with lots of other headless CMSs, has a fairly blog-centric notion of how to build content.

To summarize, a headless CMS lets developers set up specific types of content (the rough equivalent, in WordPress, of creating new page template types) and provides a non-developer, end-user interface for creating and editing instances of those content types. Differentiation among the services revolves mostly around support for things like role-based access and editorial workflows.

Following along on this “blog-centric” idea, note that non-CMS online services like Coda, which offer a sort of document-meets-spreadsheet authoring environment, may provide a model for what the CMS will become. Here’s a sample page I edited by dragging objects like the embedded table around the page:

Coda seems to understand the possibility here—they allow you to present Coda documents as web pages. And yes, there’s an API if you want developer access to those pages (RESTful, not GraphQL). You can see how the headless CMS and the “document+formulas” will begin to overlap in interesting ways.

Pricing for headless CMS varies widely, but seems to tend toward $500/month for business-level use. Most have free options for getting your feet wet or supporting personal blogs and the like.

The Down Side?

Based on numerous reviews on services like G2, discussions on Discord channels, and tweets, there certainly are some potential pitfalls in the headless CMS model:

1. Some see the learning curve as steep. I suspect that’s not true if you’re coming from immersion in React, but is probably absolutely on the mark if you’re coming into the JAMstack world cold. Even if developers have to pick up some new skills in, say, GraphQL, once they’ve got the basics sorted out, the approach is no harder (and is arguably easier) than using RESTful approaches or old-school SDKs.
2. Speaking of SDKs, some headless CMSs offer them and they sometimes don’t match the functionality of the GraphQL interface (or the interface of other SDKs for other channels within the same service). This may be the sticking point for adoption of CMSs that can’t get this problem sorted.
3. Some services make it awkward to use one content type within another as content is created. In other words, this isn’t an issue where it’s hard to have a content type defined as containing or referring to another content type as developers create the type. Rather, it’s reportedly hard or involves too many steps to embed a video type (to take one example) inside a text blog post. This is actually one area where the block approach of the WordPress Gutenberg editor works with a satisfying simplicity.
4. The CMS service becomes separate cost. Whether this ultimately matters is a function of whether you could previously get by with a no-frills WordPress site running on a third-party hosting service. In that scenario, you get a lot accomplished with one monthly fee. Once you get fancier than that, though, the costs may be allocated differently, but are likely to be the same or lower overall.

If you are a JAMstack purist, your approach is not just to have a headless CMS, but to have all manner of capabilities delivered by way API connections to third-party services. The difference between headless CMS and all the other possibilities (such as search functions, comment providers, authorization services and so on) is that the other services are invoked from the live, running site. The headless CMS, though, is a sort of integrated development environment (IDE) for content, used to create what is essentially the content source code for a site. My view is that the “pre-compile” nature of the headless CMS means that some interesting potential capabilities that could be provided, but I’ll save these for a subsequent post.

You can’t swing a JavaScript developer without hitting a headless CMS. It’s heartening how the churn of creativity has presented so many takes on almost all the pieces of the JAMstack ecosystem. But probably some kind of rough consensus about actual JAMstack stacks will need to emerge before more complex systems can be routine achievements. What’s interesting about the CMS, though, is that it has a fairly large interface component and, as such, might serve as a center point for building future web presences. That is, it may not be so much about choosing your SSG wisely, but choosing your content system wisely and then hanging other capabilities around it. In any case, businesses should almost certainly spend more time choosing the CMS service than they currently do, because what your CMS will do will, more than ever, determine what your website can do.