In this post, we’ll go through 3 different periods of the CMS evolution. For each period, we’ll explore the most popular solution(s), their stack, and also how the current market trends are looking like for them.Â
The point is to get a good overview of the market as well as what I think the market will look like in a few years’ time. These views might not sit well with everyone and they might be totally off, but I still consider them worth sharing. In case you have a different view, please let me know in the comments below.
Traditional CMS
We’ll go 15 years back in time, roughly to 2004, when the first notable event in the history of CMS happened - the creation of Wordpress.
Wordpress was the first CMS that got massive user adoption. Although Wordpress isn’t technically a CMS, more a blogging platform, due to its open-source nature and the fact that you could easily extend it to fit different purposes, you could call it a CMS.
The stack
In a traditional CMS stack, your backend and frontend are tightly coupled together; there is no API in between to handle the communication. In case of an open-source solution, you need to manage your own web server and database. In case of a SaaS, which is a managed CMS, you won’t have access to the templates or any backend code.
Specifically looking at Wordpress, anyone that started coding 10 or more years ago probably crossed paths with PHP, which was the preferred server-side language at the time. Together with MySQL, it was de facto the stack standard.
Wordpress today, even after 15 years, is pretty much using the same stack and architecture.
Although this was a good enough solution many years ago, new technologies have been created in the meantime, and the way we build web applications has changed.
We no longer bundle business logic with the HTML and CSS code, nor do we write MVC and fetch data directly from our presentation layer. Wordpress doesn’t use an API to retrieve data and there is no notion of a split between the client-side and the server-side, it’s all bundled together.
In recent years, we have learned that this way of building applications has big drawbacks, especially because you can’t distribute your content to multiple devices, including those devices that don’t do HTML, such as your mobile phone (excluding web view).
Another really important thing to mention with regards to the stack is that the technologies that were used to build Wordpress are trending down in their popularity. The younger generation of developers doesn’t want to learn PHP, and, thus, this is affecting the future positioning that Wordpress will have.
The graph below illustrates the PHP trend amongst the developer community. The graph on the left shows that PHP was at #15 as the most dreadful technology in 2017. The situation in 2019 is on the right, where PHP has jumped to fifth place.
Google trends search shows a similar result:
Market trends
Wordpress by far is still #1. It owns close to 60% of the CMS market and powers close to 30% of all the websites on the Internet. This situation probably won’t change much in the next 3–5 years, which begs the question: What will happen after that?
Since Wordpress trends are closely related to the trends of the tech stack it uses, my view is that, slowly but surely, Wordpress will start losing its market share and the reasons why are as follows:
- A newer generation of developers doesn’t want to learn PHP and, thus, doesn’t want to use Wordpress as their go-to CMS.
- Wordpress is the most dreaded platform according to the 2019 stack overflow survey.
- Google trends show that there is a decline in the global interest in Wordpress.
- Wordpress can only distribute content to the web; however, the moment you need a cross-device experience, you are limited by the platform.
- Outdated architecture is holding Wordpress back since you are required to host it inside a VPS or a container. Wordpress is not designed for the serverless environment.
Wordpress — Summary
As a summary, Wordpress, due to its massive adoption ratio and ecosystem, is here to stay for many more years. However, the market trends are showing that there is a need for a modern solution and that Wordpress will most likely start losing its market share as increasingly new and modern solutions enter the market with modern technologies.
Another important thing to mention is that, over time, businesses that rely heavily on Wordpress will have a hard time finding new talent. The reason is that younger developer generations don’t want to learn PHP and older generations want to move away from it to be more competitive on the market as PHP is one of the lowest paid languages on the market.
I intentionally started this post with Wordpress as I see Wordpress a thing of the past when looking at the market in the next 10 years. The period might seem long, but the shift has already started several years back.
Headless CMS
In case you are not familiar with a headless CMS, it’s basically a CMS without a presentation layer or a template. The data is usually retrieved over a RESTful or GraphQL API in a JSON format. A headless CMS allows you to build your own data structure, relations, and then query it using several different search mechanisms.
The advantage of a headless CMS is that you can select any technology stack you want to build the presentation layer. This is important as it opens the doors to distributing content to other devices, such as mobile devices, TVs, fridges, watches, and many others.
Using this approach, the headless CMS overcomes many of the limitations that more traditional solutions like Wordpress or Drupal have.
The one notable downside to a headless CMS is that they are not designed for business logic development. This restricts the scope of their application to the structuring and distribution of content. A headless CMS wouldn’t be a good option when designing an application that requires data to be moved and manipulated based on a predefined set of rules.
The stack
There are actually two stacks to a headless CMS: the backend stack, which is important if you are considering a self-hosted and/or an open-source solution, and the client stack, which is the one where you retrieve and display the content.
For the backend stack, the solution that I managed to find, as a self-hosted one, is Strapi CMS. Strapi uses NodeJs as the server-side language and MongoDB (NoSQL) to store the data.
On the client side, as mentioned, it’s “bring your own stack.” You can develop using Javascript, Python, Swift, Java, or any other language that has the ability to do an API request to retrieve data.
That being said, a headless CMS, with regards to its stack, is one of the best solutions that you can use today as it doesn’t impose any limitations on your technology choice and gives developers full flexibility in case they decide to switch to another stack in a few years’ time.
Market trends
At the moment, the headless CMS approach is on the rise. Developers are influencing the technology choice bottom-up in their organizations and choosing headless CMSes more and more.
Unfortunately, at this time, no researchers have yet published data on the state of the headless CMS market and their effects on the global CMS market. However, there are many other pieces of research showing that both the adoption and general knowledge about the headless CMS solutions are rising, which means over time more and more developers and companies will adopt this technology.
Summary
Headless CMS has a determined and focused future on the market. Ideal for situations when you need to distribute content to multiple devices, especially when there are different technology stacks in question.
I believe that the majority of websites will follow this approach in the very near future as this is a great offering for developers that don’t want to use Wordpress.
You might also ask yourself the question: “Will Wordpress become headless at any point?” My view is that it will not. Wordpress as a product is still primarily a blogging platform, and moving to headless would make no sense as it moves away from its massive ecosystems of plugins and other benefits that are not built in the “headless” spirit.
Serverless CMS
The “headless” approach innovated how we structure and retrieve the data for our website.
“Serverless” in a CMS agnostic way is an innovation in how we run or operate the infrastructure upon which a website runs. A serverless CMS is a CMS that’s designed to run inside a serverless environment. A serverless CMS can also be a headless CMS at the same time.
“Serverless is the future of development” (Werner Vogels — Amazon CTO)
Because of this shift towards serverless, which will be the main go-to approach for the majority of the products we build online, there is a need for a specialized CMS designed to run inside such an environment.
In the majority of cases, porting existing solutions and hosting them “as-is” inside a serverless function won’t work and, if they do, they won’t be performant enough. A serverless application, like a CMS, needs to be specifically built and designed from the ground up in order to run in such an environment.
The stack
In a Serverless CMS, the stack is comprised of two parts: the client part, which is usually hosted inside static storage, something like an S3, and the backend part, which is hosted inside a serverless function. A special router, usually referred to as a gateway, is sitting in front and intelligently routing requests under the same domain to correct parts of the system.Â
The most notable difference between the previous two CMS stacks and a serverless CMS stack is that a serverless CMS allows you to upload custom code for the backend even in cases of a managed hosted solution — this is allowed because of the natural sandbox feature that a serverless function provides.
Other solutions that are running multiple tenants inside a VPC or a container cannot allow that since one tenant can upload malicious code and bring down all other tenants that are sharing the platform. In the case of a serverless function, such a code would only affect that single tenant.
In the case of the programming language, a serverless CMS can run in most modern languages with the exception of maybe PHP in case of AWS Lambda (unless you build your own custom container). The expectation is that the most dominant language will be NodeJs since currently around 80% of all functions are written in that language.
The tricky bit with serverless is the persistent data storage — your database is of the essence. It can’t run inside the function as the function instance is deleted upon execution. Some providers, such as AWS, have an offering called Aurora Serverless. However, when looking under the hood, it’s basically an autoscaling zone around the compute instances that operate inside the cluster. Don’t get me wrong, it’s definitely a handy feature, and I hope to see it soon inside DocumentDb. For now, I would say that data storage is the weak link in the serverless architecture as there is no specialized solution that can run next to your function that handles data storage. Using any of the RDS offerings or DocumentDb is doable, but you will need to write customized layers for connection management and other complex cases that might arise.
Another challenging aspect is the cold start of the serverless functions. In cases when they run inside a VPC, the start times are up to 15 times longer to when they are not inside a VPC.
The last challenge to mention is routing —  how to route static requests to something like S3 and API (GraphQL) requests to the appropriate function? At the moment, API Gateways are partially able to fill that gap, but, unfortunately, not completely, especially when it comes to multi-tenant architectures (more about that under this link).
So, this tells us that building a serverless CMS has it’s set of unique challenges. Solutions like Webiny Serverless CMS have managed to overcome them.
Market trends and why serverless is important
Serverless is replacing virtual servers as it provides a tremendous cost saving to run and manage the infrastructure, improved security, and almost limitless scalability.
The serverless market is estimated to grow from $1.8bn in 2016 to $19bn 2025.
At the same time, developers want an alternative solution to Wordpress. Current SaaS solutions, including the headless offering, constrain what you can develop using them.
Serverless CMS with a headless API eliminates the need to pick between the two. Additionally, a serverless CMS has a much larger set of applications because not only can you build websites, but also web applications, APIs, microservices, and more.
Traditional vs Headless vs Serverless
It’s good to have an understanding of the key features and use-cases of each type of CMS, including their managed (SaaS) and open-source offerings.
Note: Solutions on the list are graded from the perspective of what is the need that the solution was designed to fulfill. Some solutions can be “stretched” to fulfill more needs, but that results in poor developer experience as well as hacky and unmaintainable code.Â
Here is a list of the mentioned solutions in the list:
Grand Summary — How will the market look like in the next 5 to 10 years?
Wordpress is still number #1, but it’s losing market share. Wordpress will be in a tough spot as it can’t innovate enough, due to the outdated stack and technology, to impress modern developers. It’s still going to be one of the top solutions due to its massive ecosystem of plugins, targeting users that are tech-savvy and know how to install a plugin or two on their own — but those are not developers. There will be additional pressure from website builders like Wix and Squarespace, targeting specifically DIY users.
Headless CMS is gaining increasing traction and is becoming the preferred option for building websites and managing content distribution. There will be more and more solutions in this space that will be open-source, and the market will get even more competition, hopefully pushing them to create better and more quality solutions for the benefit of the overall community. This will also fuel the creation of additional static generators, such as GatsbyJs.
Serverless CMS will be the go-to solution for developers and organizations that need to build more complex websites, applications, and microservices and want a more unified technology and know-how across the board. Developing microservices will be really important since serverless will become how all web applications will be hosted by that time. Most likely, one or two of the serverless solutions will be able to create a larger community and eventually an ecosystem of plugins and contributors large enough to eventually challenge Wordpress in the later future.