Headless content management has received a fair amount of hype in the last year. 

For anyone who’s managed to avoid the whole headless controversy, “headless” is the idea of decoupling the front end and the back end of content delivery. Sebastian Siemssen, senior developer at Vienna, Austria-based Zensations wrote that “instead of generating a themed representation of your website, you are providing an interface for extracting pure, uniform data, e.g. JSON, which can then be transformed and rendered independent from the backing application.”

As Mark Polly, digital solutions strategic advisor at St. Louis-based Perficient wrote, technologies like REST and javascript frameworks have played a big role in the growth of this headless content movement. The mobile revolution and, in particular, apps have driven the movement. Front end developers, faced with the question of what back end to use, have increasingly opted to use data stores, allowing them to separate content and presentation. 

Some of the companies behind the hype claim that headless CMS is the best choice for anyone who feels limited by the front-end restrictions of a standard CMS. 

I would argue such restrictions do not exist for modern enterprise CMSs out there, whereas the limitations of headless CMSs are very real.

Why Headless Content Got So Much Hype

Modern CMSs provide incredible flexibility and functionality. Typically, this requires developers to learn a lot about the product before they become effective. As time-to-market grows evermore critical, that isn’t always an option.

Headless CMSs get developers excited because they claim to offer more freedom, with many seeing it as the gateway to increased agility and speed. For front end developers, they get the possibility to use front end frameworks like Angular and React.

While the explosion in multichannel content has downgraded the importance of the company website (which was the first client of content management), people have considered different ways of working with and delivering the content needed.

The front end capabilities of most CMSs are just not adapted to today’s skills and practices. In particular, the need for a heavy skillset, in addition to the time required to develop interfaces, makes it difficult be agile and get to market fast. There’s a real lack of flexibility for both developers and marketers. 

Frustrated with the inability to use their skills and work quickly enough, many developers feel that they don’t need a traditional CMS, and have started looking for alternatives.

Don’t Throw Out the CMS Baby with the Bathwater

I disagree. 

The CMS industry has made so much progress, with multiple CMSs available that allow clients to create multilingual personalized digital experiences while at the same time offering the freedom to play around with the front end, and the option to include whatever integrations the organization might need in the future. 

Please, let’s not throw out the baby with the bathwater. 

Where Things Get Complicated with Headless CMS

Front end developers might be happy with their new found freedom, but headless CMS delivers the freedom and flexibility of “I can do everything I want” at the price of  “I have to write, debug and maintain everything I need myself.” In many cases, you will end up writing and maintaining the better part of a full-blown CMS, adding multiple layers of complexity to gain the advanced features that you’ve lost by rejecting a full CMS.

Learning Opportunities

A CMS typically provides things like asset management, navigation, security, workflow, access control, caching, categorization and link management to name a few. These and many more are not immediately available with a headless CMS approach.

Headless CMSs raise issues of security, as it’s difficult to define which users get which access, creating a risk of delivering confidential content to non-authorized users. Delivering multi-language content requires a lot of development work to re-implement this feature. And with the separation of content and delivery, editors no longer have a way to preview the content they want to publish. 

Another issue is personalization. Once you decide to separate the content from delivery, you need to rewrite a full personalization content engine. In many cases, form builders are also on the server, so integrations with marketing automation and other tools are lost as CMSs no longer have the capability to build the forms dynamically.

Today’s Solution May Cause Tomorrow’s Problems

It's always tempting when you're facing a problem — in this case, the lack of agility in delivering content — to believe in a new wonder product that looks like a possible solution. 

Most of you know that if it seems too good to be true, it probably is. 

It’s just like when Wordpress started, and people felt that it was all they needed. But it didn’t turn out like that for many. There are limits to how much you can extend simple solutions. You'll reach a point where that ‘simplicity’ leads you into more complexity than before, as you try to solve issues the product wasn’t made for.

In many cases, a headless CMS can result in increased complexity for developers and marketing teams. Your job is to look beyond the immediate attraction and think about the future.

It’s Not ‘Headless or Nothing’

Headless content management can solve specific issues well. Except that these are not really content management issues, they are more “form field storage and retrieval” issues. Businesses can use it successfully and there is an increasing trend towards hybrid approaches. 

The problems arise when companies decide that headless is the answer to everything. There’s no reason why you shouldn’t get a CMS that allows you to handle both headless content and the delivery layer. 

The most important thing is ensuring that you have the flexibility to face the future, knowing that it’s impossible to predict.

fa-solid fa-hand-paper Learn how you can join our contributor community.