Reframing Headless CMS

It’s time we put headless CMS in perspective

By my calculations, it’s just over seven years since the first intentionally headless content management system (CMS) appeared on the market. People had been using remote APIs for years, but in January 2013, I was first introduced to a new company that would eventually become a large headless CMS vendor, so I’m calling that the very beginning of the industry shift that appears to be in full swing today.

When people discuss headless, words like “revolutionary” get thrown around a lot. Everyone naturally wants to claim they unlocked some previously hidden secret, but almost a decade into this, is headless even that revolutionary anymore?

Remember when having a Blackberry was the only way you could get email remotely? That was a singular advantage that only they possessed. Inevitably, this became something everyone did. The idea of getting email on the go was just too strong of an advantage to be confined to one vendor. Blackberry pioneered the paradigm, but they couldn’t contain it.

We need to establish that “headless” means different things to different people. Perhaps not “headless” itself, but rather what people want to accomplish with it and the benefits they think it offers.

The objective definition of headless is consistent: it’s a CMS that doesn’t do direct delivery. A headless CMS doesn’t render web pages or app interfaces. The only thing it exposes is pure data, in the form of a remote API that outputs JSON. What you do with that is up to you.

And what people want to do with headless CMSs seems to have clearly bifurcated. It’s begun to fall into two distinct camps, to which I’m assigning my own names.

1. Rich Templating: Users in this camp want to use client-side delivery technologies like React and Vue to generate interfaces. They specifically don’t want to use server-rendered, static HTML.
2. Channel Distribution: Users in this camp want to use the CMS as a single-sourcing tool, so they can re-use their content in other delivery channels. They view the web channel as just one among many, and want to make sure content is not web-specific.

These two uses are not mutually exclusive, of course – lots of people want to do both. But more often, we get inquiries from organizations that are fixated on one use case, and might be totally oblivious to the other.

A front-end development team might only be working on a single website, but they want to use React and need a remote datasource that gives them JSON. A back-end development team might need a place to store content that they push into multiple channels over various APIs. In both cases, usage of the “other” style might not have even occurred to the people involved.

The two use cases can be characterized almost by acceptance or rejection of the web channel itself.

If a user wants to use rich templating, they’re not rejecting web content management, they’re actually embracing it. You don’t need an exclusively headless CMS for this. (For all predictions of the death of web CMS, I’m pretty sure you’re still reading this article in a browser…)

In fact, you’d do better with a web CMS that has templating flexibility and a headless interface. There’s quite a bit of hard-won web-specific functionality a web CMS provides which isn’t irrelevant just because you decided to template your site differently – you still operate on a “page-ish” model, and things like navigation and content structure still matter.

Buyers need to understand that using something like React is just not an absolute disruptor, and it shouldn’t rise to the level of an architectural decision.

In competent systems, templating languages should always be swappable. Optimizely is built on ASP.NET MVC, where templating is managed by what’s called a ViewEngine. The default ViewEngine uses Razor, Microsoft’s standard templating language.

But what if you don’t like the default ViewEngine? Well, just swap it out for your own. Very few people actually do it, but the option is completely supported.

Just for fun, I tried it. In 17 minutes – including research time – I had “written” and installed a new ViewEngine into an Optimizely site that rendered the title of the content object in plain text. (I’ve quoted “written” because I think it only had six lines of non-boilerplate code.) It was totally useless, but it proved the point that Optimizely’s templating is loosely bound and easily swappable.

(Also, while I’m not promising anything, I’ve seen an internal proof-of-concept that templates an Optimizely site using Fluid, which means an Optimizely project could be delivered by a front-end engineer without ever having to touch Visual Studio. Stay tuned.)

But, as easy as swapping templating systems is, it isn’t even necessary anymore – two months ago, we released our Foundation SPA React site which templates an Optimizely site using React. For performance, it renders the first request using server-side React. This converts into a full, active React app in the browser. (This isn’t a unique model - – progressive web app generators like GatsbyJS do the same thing.)

The larger point is this: rich templating is quickly becoming the norm. It’s no longer necessary to seek out a headless CMS and give up a boatload of features just because you want to use React. While Optimizely has traditionally used server-side templating, we’re rapidly achieving parity between that and client-side templating. We’re preparing for a day when no one renders HTML server-side any longer.

To be totally clear: it’s my personal mission to reduce the impact of your templating decision to a style choice. You shouldn’t need to bind that to an architectural decision.

In fact, let me issue a challenge to all my fellow web CMS vendors: assume that all templating will transition to client-side within the next 18 months. Ruthlessly interrogate your systems to ensure that all your delivery functionality will work with both server-side and client-side delivery, and don’t add any new features that don’t work both ways. Collectively, we need to eliminate the perception that “pure” headless is the only way to do this.

On the other side of the coin, organizations looking for a channel distribution are trying to decouple themselves from the web channel. They might not reject it entirely, but they have other channels where they want to use their content, and they want to ensure flexibility.

Optimizely has always embraced the .NET framework and therefore benefited from all the functionality and tooling that came with it. Advancements like MVC and WebAPI were automatically applicable to an Optimizely site.

I was involved in headless projects using Optimizely a decade ago. The product didn’t have a dedicated headless API then, but it didn’t need one because the .NET framework provided so much extended functionality that making it work headlessly became a matter of simply gluing some pieces together.

Today, our Content Delivery API has unified this under a single framework. You can access content and traverse the content tree using dedicated URL endpoints (or just call the normal URL of any page with a specific Accept header). Using Optimizely Search and Navigation gives you expanded access to directed, parametric queries for content based on whatever combination of data you need.

And it’s not just pages. Optimizely supports untethered content elements that aren’t bound to a URL. They’re simply structured content records that can be incorporated into other content. They can be dragged onto the page surface to render, or can exist only as data, with no visual display component.

Earlier this year, we released Content Manager, which is an alternate UI for editing content. It doesn’t provide any features for managing the web channel, it simply provides a streamlined interface for finding and editing content records of any type. Editors using Content Manager don’t need to understand larger concepts of website management – they can work with content without any regard to the delivery channel.

With Content Manager, you effectively have a headless CMS running inside a more fully-featured CMS. You might have some editors that just manage content, not the web channel. Your website becomes a wrapper of additional functionality around your content. There’s a difference, and now you have tools for both. Let me finish up with a key point

Let me finish up with a key point

So far, I’ve talked about recent functionality that makes Optimizely a great choice for headless projects. What I haven’t bothered to mention is much more relevant: all of this functionality has been built upon one of the strongest content management platforms in the industry.

Optimizely didn’t start from scratch. We started with a complete, battle-tested foundation of content management, and we’ve just layered headless tooling on top of that. We don’t need to go back and solve foundational problems of CMS. All we’ve done is embrace a new paradigm of delivery.

In my first book (and my subsequent college course), I’ve emphasized what I call The Four Pillars of Content Management. They are:

1. Content Modeling: how you describe your content
2. Content Aggregation: how you organize your content to provide greater value
3. Editorial Workflow and Tools: how you manage the process of creating and editing content
4. Publication and Delivery Management: how you generate output artifacts based on your content

For years, those four things were the absolute core of any CMS. They transcended vendors and architectures.

What happened when headless CMS came along? Did it upend that entire model?

No. It just changed that last one – Publication and Delivery Management. All headless vendors did is push that off onto other tools. Modeling, aggregation, and editorial tooling doesn’t change just because you decide to use React.

(This is why I get annoyed about claims of headless being “less complex” than traditional CMS. It’s not less complex, they just ignored a bunch of the complexity. You still have to do delivery, it’s just your problem now, not theirs. It’s like a car manufacturer making their products “more reliable” by selling them without engines.)

Optimizely has always been a great CMS. I knew this from the moment I saw my first demo in 2008, and that remained true through 11 years of professional services, and now through almost a year as the Senior Director of Content Management Strategy.

In no way do I mean to minimize how headless has changed this industry, but the paradigm shifts that headless has brought about are no longer “revolutionary.” And Optimizely’s architecture is such that it’s been an easy pivot for us.

When you consider the entire scope of what organizations need to do with content – from ideation to management to delivery to optimization – the choice of delivery architecture and coupling model fades into the background a bit. It’s important, but it should never be the sole driver behind product choice.

Bring your JavaScript framework and all of your non-web channels. We’ll match them up to our entire suite of content management and optimization tools. We promise you’ll like the result.

Optimizely is quickly adapting to an API-first world, and we’re bringing 25 years’ worth of content management experience with us.