Index
Edit

Why Headless?

What's a Headless CMS and why should I care?

It used to be that content management systems came in a big box: A service running on dedicated hardware where editors wrangled content, a simple database stored the results and a templating engine cranked out fully formed web pages.

For a few websites this might still be just fine. It's not very complicated. You create pages that people can come to look at. The pages have a hierarchy. They have breadcrumbs. One of them is kind of at the front. It's called index. Many of us feel comfortable now with this way of thinking about digital content.

The drawback though, is that your content is bound to a single context. Editors will put markup in a document, which in turn messes up the presentation of that document on other pages. The biggest problem, however, is that everything will be structured around pages. Pages. Pages. Pages. «What goes on the front page?» the designers ask in the first meeting. «What do we put on the employee page?»

There is no way of expressing how content is structured that cuts across the page metaphor. It's rigid. And when you want to change something, you need to restructure all your pages manually.

This used to be just fine, but it's error prone, expensive and increasingly making everyone's day worse. The reason for this is that today we know less about where our content will be used and how it will appear.

A timeline is super illustrative:

  • 2001 – Responsive design (audi.com)
    You no longer know the size of the screen
  • 2005 – Front-end Javascript Apps (Google Maps)
    You no longer need your content as HTML, but as structured data
  • 2005 – Microformats, RDFa, JSON-LD
    Your content becomes more useful if its accompanied by rich metadata
  • 2008 – Mobile apps
    Apps don't want your HTML, they want structured data
  • 2014 – Multiplication of touchpoints, devices, services
    Perhaps it's a chatbot or Amazon Alexa, an automatic translation services or other third party services. Flowing content as data across services should be easy, well defined and expected.

So even though the web was conceived as a collection of linked documents, most websites shouldn’t just be a bunch of pages. Theres’s always an underlying logic you could capture, a model to discover and apply.

Therefore, a headless CMS presents editing interfaces for structured data and makes your content available over an API. They don't do templating for web pages. And this should make you rejoice because you get a clean separation of concerns. The CMS structures your data. Editors create content. Developers make it appear on any service or platform. Designers get full freedom in how to present it to people.

If your data is well structured it will be forward compatible and you should be able to re-target it to new touch-points and services. Swap out your website without touching your data. Distribute to in-store screens. Integrate with other systems over APIs. Pipe in data from legacy systems and let editors work on presentation.

And this is why you should care about the headless CMS.

Just to be clear, this way of thinking about content isn't new. People have been building bespoke relational databases with custom forms on top since forever. But it has been time consuming and also pretty hard to get totally right. It's free form in data structure, but expensive to change.

Sanity lets front-end developers quickly describe complex data structures in JSON and instantly get a real-time editing interface. This interface can easily be customized in React. That's the totally new part.

Next: Introduction