
We’re excited to hear your project.
Let’s collaborate!
“Should I stay or should I go?” Should you stick to an all-too-familiar traditional CMS and “reap” the benefit of getting loads of much-needed functionality out-of-the-box? Or should you bid on flexibility, top speed, and versatility instead? In a headless CMS vs traditional CMS “debate”, which system best suits your specific needs?
Now, let me try and “guess” some of the CMS requirements on your wishlist:
Needless to add that:
You can't have them all in one CMS, either traditional or headless.
What you can actually do is:
Just see which one of them “checks off” the most requirements on your list.
Then, you'd have yourself a “winner”.
So, let's do precisely that:
A headless CMS vs traditional CMS comparison to help you determine which one's... a better fit for you.
Everything in one place...
That would be a concise, yet fully comprehensive definition for the traditional CMS.
Just imagine a content management system that provides you with all the critical features and functionality, all the needed elements straight from the box:
The back-end and front-end, meaning the code, database, and the layout/design, are “under the same hood”, strongly coupled.
It's all there, pre-built, at hand... “Convenience” must be another word for “traditional CMS”.
Getting all that critical functionality out-of-the-box does translate into... code. Lots and lots of code, lots and lots of files.
Which also means lots and lots of potential vulnerabilities to be exploited.
There could be an error in any of the files in that heavy load of files that you get. Or a query string parameter that could be turned into “free access” into your database...
Therefore, the convenience of built-in functionality does come with its own security risks.
Also, whenever you make a “headless CMS vs traditional CMS” comparison, always be mindful of the maintenance aspect:
Of the upgrading that you'll need to perform with every new security patch that gets released.
Now, as regards the performance “pumped” into your traditional CMS-based website/application, just think: compiling files.
That's right! Consider all those custom files, in addition to the pre-defined ones that you'll be provided with, that you'll pile up for... customizing your website.
All these files, all the new libraries that you'll want to integrate, will need to get compiled. Which can only mean:
Now, you must be asking yourself: “How do I know if a traditional CMS is the best fit for my own use case?”
My answer is:
You go through the here listed “scenarios” and see if any of them matches your own.
“It's a CMS that gives you the flexibility and freedom to build your own front-end — Angular, Rails, Node.js-based, you name it — and integrate it with content management tools via an API."
In short: your headless CMS can then serve raw content — images, text values — via an API, to a whole “ecosystem” of internet-connected devices: wearables, websites, mobile apps.
And it'll be those content-consuming devices' responsibility to provide the layout and design of the content delivered to the end-users.
What's in it for you?
A headless approach gives you the freedom to integrate exclusively the functionalities that you need into your website.
Moreover, you still get a dashboard for easily managing your content. Your headless CMS will have got you covered on this.
With no code being “forced” into your website/mobile app or need to perform a performance “routine” for this. You get it by default.
In terms of security, a short sentence could sum all the advantages that you can “reap” from having an API-based website:
There's no database...
Therefore, there are no database vulnerabilities, no unknown gateway that a hacker could exploit.
Furthermore, in a “headless CMS vs traditional CMS” debate, it's important to outline that the first one doesn't call for an administration service.
Meaning that you get to configure all those components delivering content to your website as you're building it. Except for that, the rest of the dynamic content gets safely stored and managed in your headless CMS.
“But can't anyone just query the service endpoints delivering content on my API-based website?”
True. And yet, there are ways that you can secure those channels:
Now, when it comes to performance, keep in mind that:
It's just assets that your web server will provide. As for the content coming from all those third-party services that your headless CMS is connected with, it will get delivered... asynchronously.
Now, considering that:
… you can't but conclude that in a “headless CMS vs traditional CMS” debate, the first one's way faster.
Now, if we are to sum it up, the two types of CMSs' pros and cons, here's what we'd get:
It comes with a repository for your content, as well as a UI for editing it and a theme/app for displaying it to your website visitors.
While being more resource-demanding than a headless CMS, it provides you with more built-in functionality.
It, too, provides you with a way to store content and an admin dashboard for managing it, but no front-end. No presentation layer for displaying it to the end user.
Its main “luring” points?
It's true, though, that you don't get all that functionality, right out-of-the-box, as you do when you opt for a traditional CMS and that you still need to invest in building your front-end.
In the end, in a “headless CMS vs traditional CMS” debate, it's:
… that will influence your final choice.
Photo from Unsplash
We’re excited to hear your project.
Let’s collaborate!