What is a traditional CMS?
A traditional CMS is a content management system where the backend content repository is tightly coupled to the frontend presentation layer.
Traditional CMSs force teams to be highly dependent on the vendor's preferred frameworks, databases, and technologies. They do so while only being able to render on one frontend, i.e., a single website or mobile app.
In the long term, once overheads like training, maintenance, and security updates are accounted for, the ROI of traditional CMS begins to come into question, and teams are left with unmanageable content silos across several CMS and services.
Headless CMS contrast
In contrast, aside from the ability to deliver content to multiple channels and offer ways to boost ROI, a headless CMS also stores content differently from a traditional CMS.
As a backend CMS, a headless CMS houses all the content teams need to produce for all digital entities as structured content, including text, images, videos, files, and other content assets in the backend.
Developers can query this content via API while working with modern and preferred technologies and distribute them to any digital frontend from a single source. In the long run, the ROI of this approach leads to a more scalable architecture and removes content silos.
How traditional CMSs work
WordPress is the most popular option for a traditional CMS, which we'll use as an example to illustrate the differences. Traditional CMSs like WordPress are primarily built for managing websites. They have graphical user interfaces (GUIs) that allow content creators to create content and publish it to styled "templates," choosing from endless themes and plugins.
The content created is stored within a database and displayed to the end-user or reader based on this pre-defined template.
Everything is packaged together, and the architecture of the CMS causes heavy codependency between the frontend and backend. For example, when downloading WordPress, what you're actually getting out of the box and building upon is:
- A pre-defined theme (like Twenty Nineteen by WordPress) with HTML, CSS, and Javascript.
- An optional further customization of that theme with a page builder like Elementor or WPBakery.
- A pre-defined MySQL database with a pre-defined schema, changes to which require manually modifying the database itself.
- PHP that powers the usability of your site and links your theme to the database, constantly pulling entries (posts, media, etc.) from the database into your front end, where the theme defines the placement.
- Further enrichments and customization via plugins.
To visualize this content, the raw data for a blog post is pulled from the MySQL database by Wordpress's PHP application and pushed to the theme. The theme then converts the content into HTML and styles it based on the specified CSS so the visitor can consume it.
Managing, creating, publishing, and designing your content is, therefore, entirely within WordPress itself. Content is stored in the database and pulled whenever the site needs to be rendered for a new visitor.
This tight coupling can lead to usability and security issues. For example, if a developer wants to make a change to the frontend, they may need to update the backend code as well to accommodate the change. Additionally, traditional CMSs are more susceptible to distributed denial of service attacks as there is a greater surface area to attack than with a headless CMS.
How headless CMSs work
On the flip side, a headless CMS completely defies the logic of a traditional CMS. By fragmenting the flow and decoupling the front end from the back end, it focuses on content creation and storage, with little to no restriction on how content gets rendered on the front end.
In this scenario, a typical setup might look something like this:
- You create content based on self-defined schemas in a headless CMS like Hygraph.
- You connect your API endpoint from Hygraph to your website through a data-fetching library like Axios or even the native Fetch methods supported across server and browser environments.
- You query your content to your website, app, or another platform with GraphQL, in the case of Hygraph.
- You render the returned data in a way that makes sense for your application.
Therefore, when creating content in a headless CMS like Hygraph, you're simply focusing on the content itself and not the layout or design. This is then delivered anywhere through the API, so a developer and a content creator can define how and where the content shows - regardless of the platform, design, style, or format.
See headless CMS vs. traditional CMS side-by-side comparison in full resolution