Why would anybody want a headless website?

Ok, before we go into any pros and cons. Let’s try and break down what headless is in the most straightforward way. Now, it is always difficult to be both accurate and remain clear and understandable at the same time. So right off the bat, sorry to the developers out there who might think I am generalizing and glossing over and also sorry to the not-so-digital people who think I am making to too complex.

Headless web development splits the process of getting content to a user into separate entities working together.  One is busy with gathering, structuring  and processing data. Another is responsible for presenting the data. These are two sites literally on two different urls. Though often one is a domain and the other a subdomain. Like: example.com and cms.example.com.

There are different analogies that can be used for explaining how this process works. You can see it as a car factory and a car dealership, a bakery and a bread factory or an analogy used in this Medium article by Derek McBurney: as a desktop computer and a screen.
But let’s name it by the two main categories that development work is divided up in: Back-end and Front-end.

Central to all of these analogies is that headless development represents a division of tasks, where one part- the back-end – is responsible for production, the other – front-end – for display.

Bringing it back to what that means for websites. The backend is the part acting as the data source. This can be done through for instance a CMS (content management system). CMS platforms like WordPress or Drupal can act as merely a data source, without having any interfaces visible to the site viewer, only to the site editor.

The Front-end in a headless project this is usually made through a Javascript based application that does not do any of the heavy lifting. It just gets its data and presents it in the most attractive way.

In the old days, there was only one project. There have been people called front-end developers and people called back-end developers for quite a while now. But for a long time, they used to work on the same codebase, just on different parts of it. In the end the code would be stringed together into one beautiful or sometimes not so beautiful spaghetti.

Templating engines such as twig or blade working as an interface between the back-end and the front-end have improved how these two different orientations can work together. But when JavaScript frameworks arrived on the scene, they wanted to be freed from the limitations of this connectedness.

Because if in a not-headless project (also called ‘coupled architecture’) a webpage is built, this is happening on the server instead of in the user’s browser.  A user visits a web address and the back-end starts gathering what needs to be on the page, grabs a template to load in all into and then loads stylesheets to get it all to look properly. When changing a page this process happens again. Every time the server first has to gather its data and then it starts building and sends it to the browser of the user. So you could say this is a backend-first approach.

Headless (or also called ‘decoupled architecture’) allows a javascript framework, that is working in the browser, to set up the template first and then adds the data (or content) by requesting it from the back-end.  When a user changes a page, what changes is the data, without the template always being fully rebuilt. This means that what is happening in the browser can stay uninterrupted. So this is a front-end first approach.

To create a better experience, headless frameworks are more built to create flow. That is not to say, that with you cannot achieve smoothness without decoupled architecture. Micro-animations, transitions, lazy loading can all be done there. A properly built site does not have to feel old fashioned at all.

But the difference is that a front-end app is just made for this. Meaning it is far more easy to make transitions between pages, make animations continue while you navigate and so on. You can even make music or video continually play or make effects stop or continue well into the presentation of different content. The feeling this brings to the user is much more organic like the way an app feels on his or her phone. And why? Because an app similarly first sets up the template and only requests data when it has to. This generally also improves the feeling of speed. As the user can much more gradually be presented content as it comes in.

Another benefit of this way of building is that it creates generally cleaner codebases. Because the tasks and responsibilities are more clearly separated. And modern JavaScript frameworks are often build with a easy to maintain component structure, making it very easy to scaffold new templates once the base components are set up.

Ok, so there are a couple of downsides that should be kept in mind. Now the first is costs. But knowing I have just said a scary word, let me add that these costs are overblown by some. Some development studios are counting in a factor of four times more expensive. But I think this is not accurate. I think if done well you can actually save time.

Creating two separate entities always entails more configuration, scaffolding and maintenance. But benefit of having two entities though is that there is a lot of flexibility. A CMS can be changed for another, or a different frontend can be made based on the same CMS. This is something that was not even covered so far: A front-end can combine even multiple sources or a the data from several back-ends AND/OR the same back-end can be used in multiple front-end applications. So isn’t that just blowing your mind right now.

Anyways, back to the downsides. Another thing is hosting. Hosting a JavaScript framework can sometimes be a bit more costly because certain server configurations have to be made to get it to work. But this is a disappearing problem because even the more traditional hosting is finally catching up with reality.

Another downside is that some functionalities are a little easy to build when a site is made in the traditional way. Because what is older has been around longer. Especially php based platforms have a lot of battle tested functionality that is sometimes hard to emulate with a JavaScript framework. But in the best scenario, the front-end and back-end work in a good tandem, so the front-end offloads the hard stuff to the back-end that takes care of things. With mutual respect. The challenge is that this tandem needs to be crafted by able developers. Meaning custom code.

Generally, if cost-effectiveness is key, and user experience is not, then Headless is not for you my friend. Also, if the project is small, yet the focus is on services that are php based and have no API. Then also: use coupled architecture. But if you want to offer a great user experience, please consider going headless. My personal problem with sacrificing user experience is that while you might get your functionality quicker, you get standard solutions that are often rigid in their setup. And wanting to stand out just a little, or having a consistent look and feel will suffer under it. Which leads to frankenprojects that look and feel cheap and unprofessional. And there is more than enough of that to go around!