Hybrid is the new headlessVegard Ottervig on
Why is a hybrid CMS better than a headless CMS?
Headless CMS has exploded in popularity due to several factors. It is fast and lightweight, it grants your developers much coveted freedom, and it distributes your content to any required channel and device.
So, if a headless CMS is great for editors who want to work in an interruption-free environment, can scale easier than traditional, “monolithic” content management systems, can operate faster with instant updates, and have enhanced security, why consider another alternative?
If a headless CMS can be used for websites, web applications, native mobile applications, and e-commerce sites, why consider another alternative?
If a headless CMS provides editors with an interface for efficient content management, and gives developers flexible APIs to build applications—and thereby making it fast and easy to store, edit, and publish content in any channel, why consider another alternative?
How to choose the right headless CMS:
Hybrid CMS can do it, too
A hybrid CMS is a headless CMS and a traditional CMS in one. Hybrid is one of the very rare instances where you can actually have your cake and eat it too. A true hybrid CMS is content-oriented, meaning it is structured by content first principles, followed by a presentation layer. A true hybrid CMS also lets you use it exclusively as a traditional CMS or as a headless CMS—or both in a mix.
Let us see how a hybrid CMS has the exact same benefits as headless:
Headless is all about structured content. A headless CMS is in essence a database with structured content and an API for distribution to any required channel. The content is unchained from the standard website presentation, and is put on the throne.
Structured content means that every item of a specific content type shares the same data fields and metadata logic—i.e. the same structure. Structured content is made for reuse, both on your website and in other channels, as the client can treat the data in the same way every time.
For instance, a content type for books can include fields for title, cover, author, genre, year, and synopsis, thus enabling the fields to be understood in the same way regardless of whether it will be shown on a website, a native app, or at a screen in your local library. In the old, traditional CMSs, the content would be stitched firmly together with its website presentation, making it hard if not impossible to distribute it to other widely different channels.
A true hybrid CMS features this content first approach, where every content item must have a defined content type. This effectively makes the hybrid into a headless CMS if required.
One of the major selling points of headless is its seeming ability to distribute content to any channel—whether it is websites, mobile applications, or APIs for wearables, digital signage, IoT, AI and voice interfaces, podcast feeds, and so on ad infinitum.
A pure headless solution is not optimal for complex websites, as it lacks features like page editor, tree structure, previewing, and URL management. But omnichannel implies every channel, including websites. Thus, a hybrid CMS comes to its right. Providing structured content, a true hybrid allows editors to build complex websites, while developers can build services in any channel where an API distributes said content.
See also: Headless CMS: Expectations vs. reality »
Low operating costs
Depending on your configuration, a lightweight headless CMS can prove more price-efficient than a monolithic CMS from the past. In many cases the price tag is based on traffic requests, and the number of requests can inadvertently be doubled by developers who simply choose to code differently. Also, a pure headless solution includes only a database and an API, while solutions to present your content come in addition—possibly increasing the price in the process.
A hybrid CMS includes the presentation layer for websites, eliminating this factor from the price calculation. Otherwise it features the same lightweight advantages of a headless CMS, but still with the same factors you have to consider.
Ease of use
In a world with an increasing number of distractions and clutter, what editors and content creators really need is to focus on editing and producing content in a focused environment. A headless CMS offers this, with far fewer options for the content creator than in a traditional CMS.
While a hybrid can indeed offer the good, old plethora of choices in classic website building, it can also offer a headless mode where the emphasis is on content, and content only—if this fits your requirements.
Learn more: 5 reasons to go headless with Enonic »
Most pure headless vendors offer their solutions as a SaaS, meaning you log into a cloud service to edit content or write code. With this comes the advantages of cloud hosting, with blazing speeds and cloud scalability for traffic peaks.
By their very nature, hybrids offer a variety of hosting solutions. Some are SaaS, while others may be PaaS or even on premise. The general trend is however that more and more vendors are moving to the cloud for increased user experience and speed.
An API is a computing interface that lets different systems communicate with each other. Several pure headless vendors offer a solution with a database and a ready-made API, that consequently allows you to distribute your content to other channels.
However, in these cases the API is fixed and standardised by courtesy of the vendor. In a hybrid CMS you are given the flexibility to tailor the vendor APIs according to your own requirements. You can for instance customise the API to deliver book metadata to a wearable for quick reference on the go, and another customisation to deliver all the contents to an e-commerce site.
Headless is especially suited to build applications and populate them with content. In app development the developers prefer their own building tools, while they code APIs to deliver structured content to the apps.
As a hybrid CMS includes the same mindset of database and API, in addition to offering classic CMS functionality should you need that as well, it is safe to say that application development will be in just as good hands as with headless.
Richer web experience
Headless fits neatly into the new developer front-end frameworks, like React, Angular, and Vue. Developers no longer want readily chewed HTML and markup, they want raw content to build upon. This is where headless enters the frame, with its offering of structured content from a database.
In a hybrid CMS, you get the exact same option, to distribute content to a front-end where the developers can build with whatever framework they prefer.
With most headless vendors being cloud native, this means increased security. The cloud professionals assume the responsibility of handling security issues (among others), while the headless architecture often provides a read-only API, as specified by Practical Ecommerce. In addition, the API can be stored behind one or more layers of code—for instance an application layer and a security layer—thus making it less vulnerable to attacks. Finally, the admin of a headless CMS is often on a different server and a different domain.
As always, a hybrid CMS is able to feature the same functionality as its headless brethren. It all boils down to what specific architecture you and your developers agree on beforehand. Being just as flexible as a headless CMS, it is always possible to change the model later without being bogged down in monolithic limitations.
… and often better than headless
As we have seen, a hybrid CMS can do anything a headless CMS is able to, and then some. But here is what a true hybrid can do, but a pure headless usually cannot:
- Page builder
- WYSIWYG editor
- Formatting issues and templating
- Native previewing
- URL handling (internally and externally)
- Tree structure / inherent content organisation
- Caching and lazy loading
- User roles and access management
- Error handling
- Avoid “forced” updates from the cloud vendor (if PaaS)
- No multiple services to manage
- Channel-specific support
- Editors less dependent on developers to build websites
To give a brief example of what this means in practice: A quality-controlled and managed headless CMS comparison has existed on the web since 2018, detailing and scoring several headless CMS vendors. When we added the hybrid CMS Enonic XP recently, it ended up with one of the highest scores (68.66%), despite being a hybrid CMS and not a pure headless CMS.
As a comparison, Sanity is one of the startups within the growing community of headless CMS vendors. Being more or less a pure headless vendor, they still received a bit lower score of 59.70%.
The bottom line is that a hybrid CMS can fill the same requirements as a headless CMS, with the added (and fully optional!) benefits of classic CMS functionality.
Tony Byrne of Real Story Group sums it up nicely:
“I believe larger enterprises in particular will want flexibility, and this is why traditional CMS vendors are (sometimes slowly) finding their way to "hybrid" options, where you manage and deliver full-screen experiences as well as expose a robust content API.
It's also worth remembering that in the past, every major decoupled CMS platform vendor ended up pairing their core offering with an optional delivery environment. Contentful appears to be anticipating this (no firm news yet), and I suspect the other headless vendors will get there as well.”