Wasn’t this supposed to be easy?

You paid a glamorous agency to design your new website. You spent thousands of hours and a gazillion dollars laboring over every aspect of the design to get it just right. After rounds and rounds of meetings and reviews and arguments and sweat and tweaks and nudges… finally you have a design you are happy with. Even the board is happy with it. And they want it. They want it now.

So let’s build this sucker. And let’s launch it. Then you can finally say thank you and goodbye to those expensive design and development contractors and get on with managing the content in your gleaming new website yourself. For you, in your wisdom, chose to invest in the best CMS! And now the web is your oyster.

No?

No. Usually not.

An expensive legacy

Content Management Systems, or CMS, often require incredible levels of financial, technical, and even political investment. For years they have promised clients the opportunity to take control of their websites without the need to write code or understand infrastructure. But more often than not, they leave their aspirations of being liberated and creative in tatters.

Back in the late and early nineties, CMS were expensive. Very expensive. No, even more than the number you are probably thinking of now.

The industry was dominated by exotic software solutions, sold by serious sales executives with silver business card holders. Comfort in open source software or a product that wasn’t delivered in sturdy, cling-wrapped presentation cases was yet to take hold.

I undertook my first project to select a CMS vendor back in 2001 when there were far fewer options available. I worked for a software company who had built and were hosting a website for an insurance firm. They wanted to be able to update their news page, and perhaps one day, edit the phone number in their footer without getting any of that messy HTML stuff all over their fingers.

They asked us for a CMS, so we went shopping.

The first two products we found were from companies with offices in London. Quite locally to us as luck would have it, because in order to purchase a license for the CMS from either of these companies we would first need to sit in their office across a large board room table. They were keen to talk about how we would have to pay them just under £1M for the licenses. (I’m unsure of the exchange rate back in 2001, but can we just agree that whatever it was, this is, in layman’s terms, a crap ton of money?)

I wore my best suit to that meeting. I didn’t want to look like a fool while we negotiated a £1M deal to make it easier for my client to update the contact details in their footer.

Of course, the use case for a CMS usually goes further than this. But back then, any flexibility came at an alarming price.

Paying this sort of money for the license (not the hosting infrastructure, not the consultancy, not the training for the developers and authors, not the design nor the build, just the license) surely demonstrates impressive levels of eagerness to remove developers from the equation. Or, perhaps, an over-optimistic view of just how much ease and freedom this kind of tool will provide.

Luckily though, times have changed. Yes, you can still pay a lot of money for a CMS, and the challenges in using them effectively are well documented. But over the years more people put their weight behind trying to solve this problem. New players have entered the market making the cost and the scarcity of the skills come down. The days of giant CMS vendors dominating the entire market may be numbered. And now we seem to be on the verge of something of a revolution. A CMS is now attainable on any size of budget and without a team of specialized consultants to roll it out.

And I no longer need my suit for when I’m searching for the right CMS.

Why was this so difficult?

Before we look at the new approach to CMS which is rising in popularity, it’s worth understanding the some of the history, and some of the challenges which have led legacy models to be challenged.

It once seemed that we had just a small number of complex CMS products available to us. Our choices were extremely limited and things were expensive as a result. But time brought greater acceptance of open source software, and with it, more and more attempts to deliver affordable and approachable CMS solutions.

For example, Drupal grew from a humble message board platform in 2001 to an open source CMS supported by a large community of active developers. Around the same time Wordpress started to bring CMS-like features to a growing community of bloggers. Both projects were empowered by the availability and relatively low cost of infrastructure available for hosting PHP and mySQL.

Other projects began to emerge as more people tackled the challenge of competing with the larger, established CMS vendors. As an industry, we were discovering that we could meet some of the technical challenges inherent in a CMS, and that was empowering. But our approach to usability and also safeguarding front-end code left quite a bit to be desired.

The market started filling up with products which were trying to compete on the basis of how many features they had. The more features and flexibility a product could list, the more desirable, future proof, and valuable it was deemed to be. This was a dangerous path.

We came to expect a CMS to do far more than manage content. It’s a huge misnomer. The most popular and expensive CMS often have a laundry list of tempting features. We expect them to allow us to do everything from customizing our page layouts, to powering e-commerce, to handling user-generated content — all while generating front-end code and being a core part of the hosting infrastructure serving a site to a global audience.

Bundling all of these capabilities into one, monolithic piece of software is incredibly challenging. Each area is full of craft and nuance and subtlety, Yet vendors have tried to package them up with an admin interface for anyone to manage through the click of some buttons.

Managing your site CMS became insufferably difficult. You needed experts to help you use it. And what it delivered fell short of the standard people wanted.

When we try to design a product capable of doing everything for everyone, we often find ourselves with a product so complex that nobody can use it for anything.

Focus

It sounds like I’m stating the obvious, but so many of the features done poorly by a legacy CMS relate to managing the presentation, rather than just the content. After your huge investment to establish the design of your site (remember how excited the board were?), you run the risk of undermining the design with every single content edit.

A good CMS should protect your design investment. Not help you to destroy it.

Happily, the Headless CMS approach has been gaining momentum, and it’s all about focussing on doing one thing well. That thing is managing content.

How do headless CMS work?

Headless, or decoupled CMS, provide the ability to define the structure of your content, offer an interface to populate, manage the content in that defined structure, and then serve the content via content APIs.

In this way, the management of content is not wrapped up with the ability to modify the design. The presentation of the content through the carefully crafted interface, is handled away from your CMS, protecting it from that overzealous content author, who thinks that the headings in their article really need “a little extra pop”.

The admin interface a headless CMS provides is not a part of the infrastructure you host to serve your site. Putting distance between the mechanics of managing your content (along with various user management and publishing workflow) and the mechanics of hosting your site is extremely attractive.

When the CMS was part of the hosting infrastructure it would typically compile the page a visitor requested at the time they requested it. That involved activities like asking a database what content should go into which template and cooking it up to serve á la minute. This means that both your site and your CMS would need to be able to scale to handle the load of whatever you throw at them.

Having a level of abstraction bodes well for scaling and security. The more distance we can place between traffic to our site, and the moving parts which drive the CMS, the better our chances of protecting it from those with malicious intent.

Added peace of mind.

Performance and craft

The benefits of decoupling the management of the content from the control of the design go beyond the aesthetic we discussed earlier. They impact performance, too.

When a traditional CMS allowed authors to manipulate the design of your site, it needed to generate some of the code for the site automatically. Features like drag and drop and WYSIWYG editors bring with them code generated automatically for you by the system.

Most front-end developers will start fidgeting at that thought. And I’m right there with them.

This generated code was devised long before your site was ever being discussed. It was not made for you. It was made to serve a generic purpose. It has been designed to be massively flexible so that it can be used time and time again. That’s hard to do and so we often pay a penalty for it as it introduces a variety of code smells into our sites. I’ve grumbled about this before. You never want visitors to your site to be able to smell your CMS.

Developers responsible for the performance and browser support of a site need control over its code if they are to do a good job of delivering on the promise of the design. A headless CMS gives them back this control by being agnostic to the tools which consume it. In this age of responsive web design and broadening contexts for where and when our visitor use our sites, keeping control over how the code is crafted, in the hands of the experts could not be more important.

Trends in web development continue to advance. As browsers and devices evolve, we need the ability to employ the best techniques possible when rendering the site into its various templates. Abstracting the content via a headless CMS creates a clean separation which allows us to render it with whatever build tools, templating language, or static site generator we might choose.

Content portability

With a headless CMS, you can break out of the monolithic model where all of your eggs are in one basket and your content can reach only as far as your CMS could support. Not only can you select what tools generate and present the content on your site, you can also publish your content in new formats and into other channels.

For example, if a new RSS-like format was to be defined, or presenting content in AMP format were to become attractive, that would be no problem for a Headless CMS. The content is not coupled to any one presentation format. You can expose it with new templates to support emerging formats as they come along.

Another example, structured content served through APIs can more readily be consumed by email campaign tools, or social media campaign tools. It allows you to lean on the expertise of specialists in each of these fields. And on those of areas that we have not even considered yet.

Our content is liberated to go anywhere.

Momentum and adoption

There is growing enthusiasm for this approach. Not only from the developers who build on top of such architectures, or from content authors who have become more empowered and productive than before, but also from businesses looking to avoid the kind of investment and lock-in I was subject to. (I’m still not sure that we ever managed to update the phone number in that footer!)

The market for headless CMS products appears to be thriving.

Contentful, Prismic and Siteleaf are just a few of the players in a rapidly-growing space that’s receiving lots of validation. (Contentful secured a $28M series C funding round at the end of 2017) These companies already have impressive client lists adding weight to the argument that this approach is suitable for big brands with high-traffic and richly-featured sites.

It seems that the positive results of using this type of CMS is becoming increasingly apparent to CMS customers, and even products such as Wordpress are evolving to also support a headless mode.

Where next?

Momentum towards a headless CMS model is helping to demystify and democratize what was once an exclusive and stuffy market. When they are not seen as the domain of only the big enterprise-grade vendors, all kinds of innovations spring forth.

The shift is not limited to the headless model alone.

We’ve seen CMS products which pursue simplicity by building atop file-based systems instead of databases. We’ve seen CMS implementing GraphQL to allow even more expressive and simplified querying of our content. We’re even starting to see CMS like Netlify CMS which solves common version control and integration challenges by delivering a natural authoring experience on top of Git.

Whatever happens next, we should not expect that the only solutions to managing content on a site have to be overwhelmingly complex or prohibitively expensive.

Labelling something as “reassuringly expensive” needs to be a habit that we put behind us as we explore modern approaches to meeting old challenges and assess each one on its merits and not just on its price tag.

I reserve my suit mostly for weddings now. Although it’s getting a little snug around the waist.

Off with their heads — the rise of the modern CMS was originally published in Netlify on Medium, where people are continuing the conversation by highlighting and responding to this story.