‘Going headless’: What does it mean and what's the big deal?

Note: This article originally appeared on the Great State blog.

Let's start at the beginning. What does headless mean? The name comes from talking about servers originally -- referring to one that doesn't have a monitor, keyboard, or mouse and is therefore lacking its “head”.

In a data centre or server cupboard where space is at a premium you wouldn't want to have a monitor attached to every server -- so instead you install them without monitors and use remote desktop or command line software to set them up instead.

Headless content management systems follow the same principles: instead of creating the website directly on the server where you can see it straight away, they just expose your data through a series of APIs and you use another piece of software to create the website.

So, head or no head? Which is better?

Both have advantages and disadvantages, depending on what you're looking for.

Headless systems tend to be leaner and more flexible -- because they aren't responsible for rendering the page, they can normally be smaller, lighter systems -- perfect for cloud hosting. You are then also free to choose the rendering engine or front-end technology of your choice, and if you need to redo your front-end in a year or two you don't have to change the back-end at the same time. It's also easy to consume your data in multiple places -- so you can use the same CMS to power a website and a native app, for example.

Traditional systems on the other hand lean into their integrated nature, often offering rich editing experiences that allow you to see what the page is going to look like in real time. Because every request is going back to the server, you can use analytics to change and personalise the page before it ever leaves the server, or request and integrate data from upstream systems. The downside is that you are locked into whatever templating language the backend server supports.

Why is everyone talking about headless?

Exposing your data through APIs isn't a new concept, but WYSIWYG (what you see is what you get... pronounced wizz-ee-wig) web site builders have ruled the roost for a long time because they make it so easy for editors to understand what the finished page will look like.

Low-cost hosting and the industry trend towards micro-service architectures have all contributed to the rise in headless content systems. Given the speed of development of end-user browsers and the rapid rise and fall of front-end frameworks that accompany them, separating your front-end application from your back-end content management system to give you more flexibility in how and when you choose to upgrade or redesign seems like a sensible move.

Headless systems also easily let you consume your data in multiple places. This multi-channel mindset is even more important as voice assistants, smart watches, and smart TVs get added to the wide range of systems that need to pull and access content to deliver premium experiences to users.

How do I know which is right for me?

It's tricky -- and it depends on a lot of factors, including what your aim and audience is, what type of site it is, whether it needs integrations with other systems, what your hosting and infrastructure requirements are, and where your content already is.

Luckily, we have loads of experience to help you make the best selection. We are Gold Partners with both Sitecore and Umbraco, two of the leading Content Management platforms, both of which have headless features.

Sitecore's headless module allows your front-end engineers to design and build UI elements independently using a component-based model, without worrying about specifying what individual pages look like. The built-in integration packages for a number of leading front-end frameworks means that Content Editors can still seamlessly edit and personalise content, create new pages, and change the layout all from within Sitecore's Experience Editor.

Umbraco has a dedicated SaaS headless offering called Heartcore, which delivers lightning fast sites by packaging your content and distributing it out through Cloudflare's Content Delivery Network so it can be accessed and queried “on the edge” by front-end sites running directly in the user's browsers anywhere in the world.