A hybrid CMS empower devs to deliver content across multiple channels, while offering marketers some of the interfaces they're familiar with. It's the best of both worlds... … But there's still a long way to go.
What happens when you are at that moment when you need to manage content for multiple websites, apps and smart devices, but your CMS only handles standard web content? 😒
Perhaps you are part of the group of companies that do not have the set of technologies necessary to engage with your audience through this multiplicity of channels.
In this case, the situation aggravates when you are stuck with a ** traditional CMS** (also known as monolithic CMS), seriously lagging behind in terms of technology. At the same time, there are situations where the best alternative is to stick with the traditional approach.
After all, is there a CMS architecture that can be considered the “ideal”?
In this article we will take a good look at the advantages and disadvantages of traditional, decoupled, headless and hybrid CMSs.
But first of all, let's summarize what a CMS does.
CMS stands for Content Management System. As the name says, CMS is a software responsible for managing content, which includes its creation, editing and organization.
According to the App Developer Magazine, traditional CMSs "were widely perceived to be insufficient to fully enable and fuel the digital transformation needs of the modern company."
The technical explanation for the limitations of these CMSs is that the back end (where the data is inserted) is hosted along with the front end (where the data is presented). This is what we call coupled architecture.
Nevertheless, according to App Developer Magazine, traditional CMSs (like Wordpress) are still popular today, but started to lose space about a decade ago, when “consumers started to adopt smart devices, which competed with traditional websites regarding how the content was consumed”.
Since traditional CMSs were not able to offer the flexibility needed to reach the public on these new channels, content companies created this demand in the technology market.
Before these smart devices, a CMS needed to handle content delivery primarily for desktops, for notebooks, and, after a while, for mobile devices too.
Until then, traditional CMSs were the standard. The fact that they were coupled was no problem at all. Anyway, they got the job done.
But the increasing number of different devices has brought a problem to be solved: the need to separate the content from the delivery layer, so that the content could be delivered anywhere.
To achieve this versatility, it is necessary for the CMS to present itself without a frontend system, which determines how the content is shared with the end user. In other words, it must not have a pre-defined “head” (frontend)...
… and then Headless CMS appears
Since the headless CMS imposes no limits on the presentation layer, developers can deliver the same content either to a cell phone, a mall kiosk, a web browser or a smartphone application.
Without the frontend, a headless CMS ends up acting as a content repository - storing it in its raw format -, and the ability to deliver that content to any device on the market is achieved through the alliance with some APIs.
In headless architecture, the backend and frontend are decoupled. The CMS is solely responsible for storing and managing the content, without a predetermined structure for presenting it.
The content is modeled first and then comes to life on different channels, which ensures great scalability.
Anyway, the thing with the headless CMS is that it can manage the same content for more than one application (or a website + an application). That is, it is perfect for any project that requires delivery to a variety of applications, websites and devices.
In terms of productivity, the separation of content and presentation allows content producers and developers to work independently, which speeds up the time to launch applications on the market. This is what salespeople like the most. 😉
The difference between decoupled and headless CMS
Every headless CMS is, in essence, decoupled, because the backend and the frontend are separated, but not all decoupled is headless. There is a category called simply decoupled CMS.
According to dotcms, a decoupled CMS is similar to a headless CMS because it provides more flexibility in sending content to various frontends.
But there is an important difference: unlike headless, decoupled CMS provides the tools, the templates and other rendering options that an organization will need to build a website (such as visualization features, for example).
Therefore, a decoupled CMS restores some power to the editorial teams, who want to control how their content appears as much as possible. But it is still far from being comparable to the usability presented by traditional CMSs…
Headless CMS = developer dependency
According to Omayi Walker, Senior Software Engineer at Brightspot, there is no way to implement a headless CMS from the front-end without the presence of developers, as they will be responsible for the APIs and for building the front-end across any downstream channels required.
On the back end, according to Walker, a good CMS will likely offer APIs for common types of ready-to-use editorial content, but it doesn't end there: any additional business logic or customization will also require a developer.
Traditional and headless CMS: the best in each
Traditional CMS still beats headless in terms of usability. An example of this is the WYSIWYG functionality (What You See Is What You Get): you can edit the content directly on the page and see the result, something that no headless CMS has managed to do so far.
On the other hand, headless CMSs are winning the battle with traditional ones on 4 other important issues:
more freedom for IT teams, which can develop their front end applications in the framework of their choice (React, Vue.js and Angular, for example), on which traditional sites or single-page applications can be built.
But with the non-existence of WYSIWYG, headless CMS creates a big problem for content producers and marketers. In headless, this is what they find ahead:
there is no WYSIWYG editor;
there is no drag-and-drop;
there is just code everywhere.
In the case of the headless CMS, it is up to the front end developers to design and organize the content, so that it can be displayed and transmitted on websites, apps, voice-enabled devices, and wearable technology.
The marketer's role in this publishing process is limited as there is no editor, live previews, or drag-and-drop interfaces. For those who don't understand coding, this is like dropping a blindfolded person into an unfamiliar environment.
Our opinion is that there are pros and cons on both sides. Depending on the intention of the project, one of the approaches is totally unfeasible for its execution.
If you need to deliver the same content to a variety of applications, websites and devices, a headless CMS is the best option.
But if you can't rely heavily on developers, and at the same time you need to empower content producers, it's a good idea to grab a traditional CMS.
But there's one thing: currently, what the market is looking for is actually the combination of the two things - or the best of both worlds.
Hybrid CMS: a headless CMS with a front end
Image: core dna
A hybrid CMS is a headless, decoupled CMS, but also a front end CMS at the same time. It is a traditional monolithic CMS, but with a Content as a Service (CaaS) API.
Although decoupled from the back end, a hybrid CMS includes a presentation layer similar to a traditional CMS while also using a headless architecture for content delivery.
Hybrid CMS is a middle term solution. It gives developers a certain level of freedom (powered by APIs) to deliver content across multiple channels, while offering marketers some of the interfaces they're familiar with from the traditional CMS for delivering content to web channels.
A hybrid system architecture can take shape in different ways. If you're running multiple sites, you can take a headless approach with some of them, but specify a front end for others. Or maybe you maintain a front end for your website and at the same time choose to be headless in mobile apps, rendering them with downstream systems.
The decision is up to you. It all depends on your team and business goals. There is no need to adopt pure headless and miss the traditional features, and vice versa.
It's the best of both worlds, literally.
Now we’re gonna dive a little deeper into the hybrid CMS, presenting the advantages listed by Brightspot.
Advantages of a hybrid CMS architecture
A hybrid CMS has the advantages of decoupled and headless CMSs, offering both application and platform.
Like the headless system, the hybrid system architecture promotes content reuse.
It is usually cloud-based or cloud-ready.
You can get WYSIWYG functionality for authoring, template management, site navigation, multi-site management, accessibility, compliance, SEO, link checking, version management and administration, and workflow.
The system promotes collaboration between the marketing and development teams across a full range of digital experiences.
Although we raise the banners of JAMstack, serverless, edge computing, and other cutting edge technologies in web development, we admit that, in terms of usability, headless CMSs have a LONG way ahead.
Our content team used Forestry's CMS for a while, which is headless. Turns out that we really missed the usability of good old WordPress…
We ended up surrendering. Technologically speaking, it can be said that we took a step back by going back to WP. On the other hand, we are more satisfied with the production of blog posts in the monolithic system.
At first, hybrid architecture came to solve this kind of dilemma. What the market currently needs is a solution that addresses the needs of developers, content producers and companies' business strategies, all at the same time.
But hybrid CMSs are still in their infancy. No company has managed to master the construction of a tool like this. So this avenue remains open.
In the meantime, you need to identify your priorities and to compare them with the characteristics of traditional and headless CMSs, while the hybrid architecture is not yet mature. Embrace the format that best meets your needs, and wait for the solution that, in our point of view, will be ideal for virtually any type of business.
Melissa Webster of International Data Corporation agrees with us:
“We think the ultimate solution is really a hybrid approach that brings forward all the benefits of web content management that we've accumulated over the last 25 years and adds to it the ability to support developers building headless applications”.
So, while the hybrid CMS architecture continues to improve, the answer is to know how to choose the best available option.
And what about you? How have your experiences with CMSs been so far? It is super important to exchange ideas and experiences about technologies that are in development.
Do you want to join this debate? Leave a comment!
If you want to go beyond this content and chat about other technologies, join our server at Discord. 😊