The CMS is dead. Long live the CMS!
I was never really fond of the concept of CMS, content management systems. All this time I wasn’t really sure why I felt like this, as if the likes of WordPress, Drupal and others were just not for me. But I think I’ve finally figured out what I feel is fundamentally wrong with the way the traditional CMS approaches web development.
The heart of the problem turns out to be, as a matter of fact, right in the definition: content management system. I think that these self-proclaimed CMS go far beyond the scope of what a real CMS should be.
Do they really manage only content? No, they don’t. They want to manage everything. You can’t escape them. They should be called something like WMS, or Website Management System. They don’t just limit themselves to managing content, they force-feed you instead a whole system you have to constantly fight against in order to manage just that, content.
My experience is mostly with Drupal, so I’ll use that as an example. Drupal is an exceptional piece of technology, especially in its most recent iterations. However, it appears clear to me how it is a result of a different time in web development, one when the needs were extremely different from those that we have today.
Does anyone remember what web development was like a few years ago? There was mostly low-quality PHP 4 around, little to no version control, Internet Explorer was still the main browser you had to develop against, and all the fancy HTML5, CSS3 and high-performance JavaScript were still nowhere to be seen. No 4K monitors (not even full HD), no smartphones, no tablets. User Interface and User Experience were infinitely less important.
At a time like this, the needs of a website developer were vastly different from today’s. In order to have a system which was pretty much ready out of the box, giving up some freedom wasn’t a problem, as there wasn’t much freedom to begin with: the constraints of web development were strong and clear. Therefore you were happy to have a system that gave you a dashboard where you could create content, decide how to display it, and make all kinds of tweaks to your website.
That was web development.
But now, our little world has turned upside-down, and we have beautiful interfaces, all kinds of HTML5 goodies, and overall we are definitely shifting away from a model where a website was basically a bunch of data stored in a database, vomited up on the screen. We as developers have different needs, we need to be in control of many moving parts that make up a website. We need the freedom to experiment, to let our fantasy run wild… We need the freedom that a traditional CMS isn’t willing to provide.
Of course, a CMS can be bent to act the way we want, but is it worth it? The usual development workflow of a Drupal project is to start with a working website which you then deconstruct according to your needs. You may want to add a piece of functionality which would be trivial to implement in a custom project, but within the realms of Drupal there are so many constraints that building the functionality from scratch isn’t an option, so you look for available modules, which work only in the Drupal ecosystem, and this leads to abandonware, code that never left the beta (or even alpha) stage and was abandoned years ago. But you are forced to use it, because that’s better than the alternative of doing it yourself and entering the deep caves of Drupal Hooks, all this while paying attention to doing things The Drupal Way™:
- It turns out that showing a list of unrelated items in a page requires you to create a view which generates a block, then configure that view, choose a formatter, add a few CSS classes hoping that’s enough to style it according to your needs, or else you need to either write a custom preprocess function or handle everything in a template which has a name so long that old Windows versions probably would crash just by looking at it.
- Don’t ever take a look at the database. Drupal comes with ~200 tables just in its base form, and every module you install will add more. Many more.
- If you are working on a feature on a local development machine, good luck deploying it. The Drupal brand of CMS stores everything in the database. Every last bit of site configuration is there, so forget about a proper environment management with automated deployment. Sure, there’s the Features module. Sure, there have been improvements in this area. But the system is just too database-centric to be properly managed. Data and configuration are one huge blob (which coincidentally is the field type used in many tables, usually employed to just store ridiculous amounts of serialized stuff).
- Development tools are basically non existent. There’s the devel module, but then? Why can’t I easily see where a certain bit of HTML is coming from? More often than not I feel like the page I’m seeing is a result of some black magic, rather than my own intentions. Symfony’s profiler/debug toolbar is amazing, why is there no equivalent?
- Speaking of which, more often than not I feel like I must resort to CSS or Javascript to fix Drupal’s mysteriously generated markup. But hey, don’t think that it doesn’t want to manage them too.
- Overall, it results in high development times and costs, especially on little-to-medium projects. This is also the result of the lack of well trained Drupal devs, because one can’t just be a good frontend developer or backend developer. He/she must be a Drupal developer.
- Speaking of devs, most CMS don’t really enforce best practices, leading to often unmaintainable code. They often employ ad-hoc standards instead of adopting ones (like PSR-2 for coding), and often push you towards writing tons of boilerplate code that gets the job done as soon as possibile, but just is not really good.
- Arrays of arrays of arrays of objects with arrays of arrays of objects with arrays, etc.
- It also appears that devs will also have to sit on the Drupal bench while Content Authors and Site Builders will be the focus for the next development features.
What’s that? You only wanted to manage some content?
Yes, here’s the catch. Drupal doesn’t manage the content only. Drupal manages every little inch of your website, and more often than not it does so via the Web dashboard. What we have, then, is a tool which is good mostly for content managers and site builders, which provides many solutions to the user willing not to go off the beaten path.
But that user is not a developer.
If you are a developer, you want to be in control, because you don’t want a system you must fight against. You want a system that truly manages content only, maybe helps you with some boilerplate code, but that’s it. You should want something you can version control, something that can be easily deployed and rolled back. Something that draws a clear line between what a content editor can do through a dashboard, and what a website is supposed to look and how it’s supposed to behave, as decided by designers and developers.
Traditional CMS helped create a hybrid figure, a jack of all trades of sorts, someone who could create a whole site from the ground up, decide on its features, looks, and contents. Someone who had the option to rely on preconfigured systems and prebuilt modules and themes, because their needs could be adapted to those of the chosen tools.
But this figure made us forget the benefits of separation of concerns, that is, doing just one thing and doing it extremely well. We’ve let developers fight against systems that instead of giving them the freedom they need, provided them defaults hard to overrule and libraries needlessly complex and complicated to use, let alone fully understand.
I’m advocating the freedom of content, freedom from the tight grips of Website Management Systems. I think that projects like Contentful are definitely a step in the right direction, because they establish a clear boundary between content and everything else. A system like Contentful provides you the tools to create, shape and manage content, without any of the restrictions of a regular CMS. Only your skills and your fantasy can then limit you. But of course, relying on a third party API-only service can be too extreme for someone, especially considering that features such as language management are behind a pay wall, but I think it’s a product worth at least checking out.
I dream of an actual Content Management System, one with a beautifully simple interface to manage content, one that is Git-friendly, and one that just wants to get out of my way. Because I’m a developer, and developing free of boundaries is what I do best. So in my view, the CMS as we knew it is dead. Long live the CMS!
