The Very Scary Story of How CMS Lost Its Head

It’s the 200th anniversary of Washington Irving’s The Legend of Sleepy Hollow so in honor of that and since it is nearly Halloween, it seems fitting to talk about one of the newest trends in content management, the Headless CMS.

Forget about how a CMS could lose its head for a second. Some of you are probably asking, “What is a CMS?” A CMS, or Content Management System, in the simplest terms, is an application that stores content in a database for use in a digital platform (think website or mobile app). The idea of content management has been around for a very long time and the systems developed over the last 30 years for content management have evolved significantly.

Some of the earliest CMSs started to appear in the 1990s and it’s around this time that we first see the term Content Management System come into use. These first iterations focused on web publishing and making it easy for anyone to do. Over the next ten years, the number of CMS offerings exploded. They made it easy to publish low-cost websites quickly and easily without the need to understand HTML. Throw in a growing selection of templates, and the publishing of professional-looking websites became a breeze.

Sounds great, but how on earth can a CMS have a head, let alone, lose it? I mean, it sounds kinda spooky, right? I keep seeing images of a headless rider on horseback holding a jack-o’-lantern in his hand. (Thanks Washington Irving and maybe a shout out to Disney, too.) Things moved right along in the CMS world through the 1990s and 2000s with a lot of great systems delivering content to a lot of websites. Initially, CMS platforms were focused on static websites, as browsers and scripting languages evolved, so too did CMSs. It became standard fare to expect a CMS to be able to deliver rich content dynamically and to allow the non-programmer content managers to control the layout of the pages being delivered. To make all this work, they added an administrative portal to the CMS which allowed the user to control everything, on almost any scale, for a CMS-driven website. And there you have it, a fully mature CMS ecosystem that delivers amazing web pages while removing the dependency on developers so that just about anyone can control the content and the layout. This version of a CMS is what we would now call a Traditional or a Coupled CMS.

Then, in the late 2000s, we got smartphones, and everything changed. Wait, now we can browse the internet on a phone? Awesome! But maybe not so much for website developers and our aforementioned CMS platforms. How do we deliver all that great dynamic content to a phone when all the layouts and templates are built for desktops and laptops? Initially, the only real solution was to have a mobile site that was entirely separate from the desktop version, and that didn’t play well at all with all those CMS platforms. Did users really need to curate all of their content in two separate places and try to keep it all in sync? Fortunately, responsive web design came to the rescue and we were back to being able to have a single CMS to curate and deliver all the content from a single source. But you see the problem coming, right?

It’s also around this time that JavaScript frameworks like Angular started to appear and the Single Page Application (SPA) was born. It would now be conceivable that we could have a CMS that needed to deliver content to a traditional website as well as one or more SPAs. Enter the Decoupled CMS. The premise of the Decoupled CMS is that we can begin to separate, or decouple, the content from the presentation layer. A Decoupled CMS allows for the curation of a variety of templates that all pull from the same content source, but that can deliver HTML that is tailored to a specific platform. Prior to the Decoupled architecture, the CMS generally shared the same domain URL as the website it was serving and was tightly coupled to the website. One of the critical architectural evolutions that made the Decoupled architecture work was the integration of an API to interact with and deliver the HTML. Now the CMS could deliver any markup to any website in any format, all through the API.

We need to remember that, until this point, a CMS was all about delivering stuff for websites, including all the HTML, CSS, and JavaScript. How are we supposed to now deliver that content to a native app when native apps don’t understand HTML or CSS? All they really need are the images and text, you know, the good stuff. What if there was a way to just deliver content without any HTML and let the consumer of the content take over responsibility for figuring out how to display it? Well, there’s only one way to make that happen and it would make Ichabod Crane shake in his boots. You guessed it, we needed to cut the head off the CMS. Ok, so maybe it’s not a real head, but we needed to remove the presentation layer from the picture. A Headless CMS focuses on only one problem, how can we manage all our digital content in a single location and deliver it to anywhere and everywhere it’s needed? So there you have it, the evolution of the Headless CMS, a content management system that utilizes an API architecture to deliver text and image assets to any digital consumer including websites, native mobile apps, voice apps, podcasts, wearables, IoT devices, and on and on.

Headless CMSs first appeared in the late 2010s and are proving to be a valuable tool for content delivery, but Traditional CMSs are still widely used and will continue to be for some time to come. In that case, how should you go about deciding which is the right digital solution for you? Let’s consider the pros and cons of each. A Traditional CMS allows non-programmers to control every detail of layout and content, so that’s a big plus, but it can be more costly to maintain since every customization affects the entire ecosystem. In addition, a Traditional CMS is not a viable solution when we need to deliver content to anything other than a website. A Headless CMS, on the other hand, solves all our problems for content delivery to non-website platforms. It offers flexibility in deciding what types of front-end technologies are used and, because the CMS is separated from the presentation layer, changes and customizations are typically less impactful and less costly. The one major drawback with the Headless CMS is that the content managers now forfeit their ability to control page layout from within the CMS.

I know, I know, there’s a lot to unpack and you’re probably asking, “Can’t you just tell me what to use and when?” As with any digital solution, you will need to consider the current and future needs of the platform before making any architectural decisions, but in general, you can follow these guidelines:

Use a Traditional CMS if …

You only need to deliver content to a web-based application and your content manager wants a high degree of control over the layout.

Use a Decoupled CMS if …

You need to deliver content to more than just a single web-based application, and your content manager also wants some control over the layout.

Use a Headless CMS if …

You need to deliver content to a variety of application types and your content manager does not need to be involved in controlling the layout.

Thanks for reading and I hope you have a wonderfully spooky Halloween.