Kind of stuck here? On one hand, you have all those software development technologies that are gaining momentum these days — API, serverless computing, microservices — while on the other hand, you have a bulky "wishlist" of functionalities and expectations from your future CMS. So, what are those types of content management systems that will be relevant many years to come and that cover all your feature requirements?
And your list of expectations from this "ideal" enterprise-ready content infrastructure sure isn't a short one:
- to enable you to build content-centric apps quick and easy
- multi-languages support
- user role management
- a whole ecosystem of plugins
- inline content editing
- to be both user and developer-friendly
- personalization based on visitors' search history
- to support business agility
- search functions in site
... and so on.
Now, we've done our research.
We've weighed their pros and cons, their loads of pre-built features and plugins ecosystems, we've set them against their “rivaling” technologies and selected the 3 content management systems worth your attention in 2019:
But What Is a Content Management System (CMS)? A Brief Overview
To put it simply:
Everything that goes into your website's content — from text to graphics — gets stored in a single system. This way, you get to manage your content — both written and graphical — from a single source.
With no need for you to write code or to create new pages. Convenience at its best.
1. Traditional CMS, One of the Popular Types of Content Management Systems
Take it as a... monolith. One containing and connecting the front-end and back-end of your website: both the database needed for your content and your website's presentation layer.
Now, just turn back the hands of time and try to remember the before-the-CMS “era”. Then, you would update your HTML pages manually, upload them on the website via FTP, and so on...
Those were the “dark ages” of web development for any developer...
By comparison, the very reason why content management systems — like Drupal, WordPress, Joomla — have grown so popular so quickly is precisely this empowerment that they've “tempted” us with:
To have both the CMS and the website's design in one place; easy to manage, quick to update.
Main benefits:
- your whole website database and front-end is served from a single storage system
- they provide you with whole collections of themes and templates to craft your own presentation layer
- quick and easy to manage all your content
- there are large, active communities backing you up
Main drawbacks:
- they do call for developers with hands-on experience working with that a specific CMS
- except for Drupal, with its heavy ecosystem of modules, content management systems generally don't scale well
- they require more resources — both time and budget — for further maintenance and enhancement
A traditional CMS solution would fit:
- a small business' website
- a website that you build... for yourself
- an enterprise-level website
… if and only if you do not need it to share content with other digital devices and platforms.
You get to set up your website and have it running in no time, then manage every aspect of it from a single storage system.
Note: although more often than not a traditional CMS is used to power a single website, many of these content infrastructures come with their own plugins that fit into multi-site scenarios or API access for sharing content with external apps.
2. Headless CMS (or API-First Pattern)
The headless CMS “movement” has empowered non-developers to create and edit content without having to get tangled up in the build's complexities, as well. Or worrying about the content presentation layer: how it's going to get displayed and what external system will be “consuming” it.
A brief definition would be:
A headless CMS has no presentation layer. It deals exclusively with the content, that it serves, as APIs, to external clients.
And it's those clients that will be fully responsible for the presentation layer.
Speaking of which, let me give you the most common examples of external clients using APIs content:
- static page application (SPA)
- client-side UI frameworks, like Vue.js or React
- a Drupal website, a native mobile app, an IoT device
- static site generators like Gatsby, Jekyll, or Hugo
A traditional CMS vs headless CMS comparison in a few words would be:
The first one's a “monolith” solution for both the front-end and the back-end, whereas the second one deals with content only.
When opting for a headless CMS, one of the increasingly popular types of content management systems, you create/edit your website content, and... that's it. It has no impact on the content presentation layer whatsoever.
And this can only translate as “unmatched flexibility”:
You can have your content displayed in as many ways and “consumed” by as many devices as possible.
Main benefits:
- front-end developers will get to focus on the presentation layer only and worry less about how the content gets created/managed
- content's served, as APIs, to any device
- as a publisher, you get to focus on content only
- it's front-end agnostic: you're free to use the framework/tools of choice for displaying it/serving it to the end-user
Main drawbacks:
- no content preview
- you'd still need to develop your output: the CMS's “head”, the one “in charge” with displaying your content (whether it's a mobile app, a website, and so on)
- additional upfront overhead: you'd need to integrate the front-end “head” with your CMS
In short: the headless CMS fits any scenario where you'd need to publish content on multiple platforms, all at once.
3. Static Site Generators (Or Static Builders)
Why are SSGs some of the future-proofed content management systems?
Because they're the ideal intermediary between:
- a modular CMS solution
- a hand-coded HTML site
Now, if we are to briefly define it:
A static site generator will enable you to decouple the build phase of your website from its hosting via an JAMstack architectural pattern.
It takes in raw content and configures it (as JSON files, Markdown, YAML data structures), stores it in a “posts” or “content” folder and, templating an SSG engine (Hugo, Jekyll, Gatsby etc.), it generates a static HTML website with no need of a CMS.
How? By transpiring content into JSON blobs for the front-end system to use. A front-end system that can be any modern front-end workflow.
And that's the beauty and the main reason why static site generators still are, even after all these years, one of the most commonly used types of content management systems:
They easily integrate with React, for instance, and enable you to work with modern front-end development paradigms such as componentization and code splitting.
They might be called “static”, yet since they're designed to integrate seamlessly with various front-end systems, they turn out to be surprisingly flexible and customizable.
Main benefits:
- they're not specialized in a specific theme or database, so they can be easily adapted to a project's needs
- Jamstack sites generally rely on a content delivery network for managing requests, which removes all performance, scaling, and security limitations
- content and templates get version-controlled right out of the box (as opposed to the CMS-powered workflows)
- since it uses templates, an SSG-based website is a modular one
And, in addition to their current strengths, SSGs seem to be securing their position among the most popular types of content management systems of the future with their 2 emerging new features:
- the improvement of their interface for non-developers (joining the “empower the non-technical user” movement that the headless CMS has embraced); a user-friendly GUI is sure to future-proof their popularity
- the integrated serverless functions; by connecting your JAMstack website with third-party services and APIs, you get to go beyond its static limitation and turbocharge it with dynamic functionality
To sum up: since they enable you to get your website up and running in no time and to easily integrate it with modern front-end frameworks like Vue and React, static site generators are those types of content management systems of the future.
The END!
What do you think now? Which one of these CMS solutions manages to check off most of the feature and functionality requirements on your wishlist?
