What is a CMS?
and why has it lost its head?
Many web developers’ first foray into putting content on the web consists of a Wordpress site. I tried to build one long before learning software development and it was surprisingly easy to get something on the internet, even though I had no idea what a ‘CMS’ was. Fast forward almost a decade and I realized I still didn’t have a concrete idea of what a CMS was, despite being a web developer for 3 years. Let’s dive into the concept.
Traditional CMS
CMS stands for Content Management System — it’s best to think of it as a web architecture. We know the building blocks of the web are a front-end (HTML, CSS, JS) and a back-end (server + database, API, built in many languages). Traditional CMSes can handle both of these, and more.
When a client makes a request to a website backed by a CMS, this is the typical workflow:
- The middleware running on the server processes the request
- The server queries what it needs from the database
- The middleware generates the HTML page and returns it to the client
Pros and Cons
The CMS system is an improvement in organization and accessibility compared to its predecessor — writing all pages by hand and uploading the files to your server via FTP. Pages can be templated and generated making it easier to keep websites dynamic. SEO (Search Engine Optimization) is more managable using a traditional CMS as well.
Ease of use is a large part of why CMSes gained popularity. Content creators can push to the site through an admin portal while developers work on engineering the site’s pages. The separation of concerns makes for better organization and simultaneous work for faster deployment.
This also benefits users who don’t have the coding knowledge but still want to build a site. Wordpress, an open-source CMS, provides templates, hosting, and site monitoring with easy tools for non-coders. However, such users are beholden to those template’s styles, and there is a limit to which they can customize a site without coding skills.
A large downside to the structure is that the markup has to be dynamically generated on the server side, leading to a large TTFB (Time To First Bit). It can take a long time for the user to see anything depending on the workload the server has. You may be able to improve the speed with optimization but there’s a limit, and you might also run into bottlenecks. Once you start adding logging, eCommerce, analytics, the infrastructure can get daunting and there are more pinch points where things could go wrong.
Headless — The Modern Way
You might see this being called a decoupled CMS, which is actually slightly different from a headless CMS. A headless CMS is one where the front-end has been completely separated. The CMS has transformed in to a content-serving machine — it’s broken into components that can be accessed through a central API. This structure has many benefits that improve upon the traditional.
The API allows for less pinch points and easier error handling, while keeping a RESTful system with a single source of truth. The API can communicate with other technologies, allowing for content delivery to RSS Feeds, Smart Watches, and other IoT devices. It’s also built to be easily scalable and future-proof so anyone can pull from it’s content.
The front-end can be rendered on the client-side providing a better user experience with less TTFB. Pages can be custom or templated and made in any framework/language the developer chooses. Developers can use build tools to communicate with the API and generate the markup so a build can be efficient while being dynamic.
Final Thoughts
While headless CMS has been increasing in popularity within the last few years, there are still lots of companies and sites still using the traditional model. Being able to use both and understand the difference will be an important skill for developers to have if headless becomes the norm and older systems need to be ported over.
