Pure Headless is Not the Answer for the Web Channel

There’s a knee-jerk reaction we see a lot that rarely helps customers –

If I want to use advanced front-end technology on my website, then I need a pure headless CMS!

No. You don’t.

We see this all the time – organizations want to step up their UI game, so they decide to use React or Vue or whatever on the front end. These are JavaScript-based templating systems that retrieve content from the server via Ajax calls, and dynamically re-render the page.

Technically, websites built with these systems only make one “traditional” HTTP call to the server – the first one, which downloads a page shell and “bootstraps” the JavaScript framework. From that point on, everything is swapped behind the scenes, without a full page reload.

This sounds…headless-y, I know. Ajax, JSON, React, JAMStack – those acronyms all just scream the need for headless.

But here’s the truth –

You still have a website.

Sure, you might be doing some fancy templating and layout management, but you’re still generating a website, and there are still a lot of website concepts you need to manage.

You still have URLs.

You still have pages.

You still have page composition.

You still have links from page to page.

You still need to visually embed media.

You still want to preview web pages.

You still have a website.

What you don’t have is the need for server-rendered HTML. If you pick the right CMS, generating HTML server-side is a very, very small part of the request-response process.

What you need is a web CMS (yeah, I said it) that can swap its templating layer out for JSON rather than HTML.

Lots of systems can do this. Here’s one: Optimizely Content Cloud

Pure headless vendors want you to forget you’re fundamentally building a website. They make dramatic proclamations about how you need to “manage content, not pages.”

Well, sure.

But you still need to manage pages.

Because you still have a website.

I’ve seen people manage websites with pure headless CMSs. You can do it, but you’ll end up rebuilding a bunch of functionality or suffering through lower-fidelity functionality because the tool you’re using is completely ignorant of the requirements of working on the web.

A few months ago, I met with a client that had used a leading headless vendor to build their website. They were proudly showing me the backend of their system. Curiously, the things they were most proud of were how they recreated a bunch of web-centric functionality to serve the web channel which was their primary means of customer contact.

They were proud of the system they rigged up to preview content.

They were proud of the URL routing mechanism they had implemented.

They were proud of the “edit this content” links they had hacked into the delivery layer.

They were proud of the Rube Goldberg method they created to embed content in other content to form a composite page.

They were proud of all the metadata they added and managed to organize pages into navigation.

I estimate that fully one-third of the work they put into their site was simply to get a headless CMS to perform minimally well for the management of a website. They spent hundreds of hours just getting back to what a web CMS does out of the box.

This prompted me to ask, “Why didn’t you just use a web CMS in the first place?”

They were surprised I even asked. They answered:

“Well, we wanted to use React. And we use some of this content in our mobile app. So…well…naturally, we needed to start with headless.”

…no, you didn’t.

A good web CMS can template in whatever: server-rendered HTML or React or anything else.

And a good web CMS has a content delivery API that can repurpose content as pure data so you can use it in other places.

All that, and it’s designed to help you build a website.

I make the point that front-end technologies are just templating, and Episerver is flexible enough to swap that layer out. In fact, we provide a React starter site in our Foundation React open-source project.

Additionally, Episerver has a content delivery API that will give you your content as pure data, free from any server-side rendering. You can do this with content you’re using in pages, or you can manage pure content which is free from any presentational component (you know…headless content).

In that second blog post, I even linked to some code that proves this:

Managing Non-Web Content in Episerver

Hybrid headless is a great choice for organizations that are building websites, but want to use advanced front-end technology and still have the flexibility to serve content as data to any other platform.

You can have all this, without having to rebuild all the web-centric functionality that you probably won’t think about until it’s gone, and that your editors just assume they’re still going to have in the new system.

When your editors start asking how they drag content elements around their pages, link them to each other, and preview them in context, you’ll start scoping how much that’s going to take to rebuild in a system that refuses to acknowledge the web exists.

Trust me when I tell you that’s not gonna be a good day.