Sometimes it feels like the Internet is growing faster than the universe is expanding. During the global COVID pandemic, businesses that had never even considered how to operate online were forced into the digital world to survive. More than ever, hobbyists, bloggers, and solo entrepreneurs are creating websites to compete for attention in a noisy world.

With this proliferation of new websites, it may be an opportune time to ask, "Are our content management systems actually serving these ever-expanding needs?" Maybe they're not. It often seems like CMS platforms have been busy chasing trends rather than focusing on solving the problems of specific types of users. This is especially true in the open source world.

In this post, we will look at the origins of modern content management systems, their technical challenges, and their evolutions. The post will conclude by exploring what CMS platforms might be able to do to better serve their users in the future.

From humble beginnings

Many of the major open source content management systems were built in the early 2000s. The digital landscape looked very different than it does today. Easy-to-use visual website builders like Squarespace hadn't yet become household names. Social media hadn't yet gained its foothold.

If you wanted to share your ideas online, installing a PHP website builder on shared hosting might be the most practical option. Countless open source projects like b2/cafelog empowered non-technical users to build personal blogs. As b2/cafelog evolved into WordPress, it transformed into a full-blown content management solution with a theming system, plugins, custom post types, a REST API, and visual page builder.

WordPress's expanding feature set led to increased developer adoption. Yet many of the features that made platforms like WordPress practical for non-technical users became major pain points for developers. UI-driven plugin updates could break websites. Configuration that was stored in the database made it hard to keep development and production environments in sync. Custom fields–most often implemented with the Advanced Custom Fields plugin–had UI-driven configuration that also must somehow be kept in sync between production and live sites.

WordPress's legacy

WordPress was designed to empower non-technical users to manage a website almost entirely through the UI on a single, stateful server. The inexpensive virtual private servers of today didn't exist when it was released in 2003. Nor did object storage or affordable managed databases. Continuous delivery pipelines weren't in the psyche of developers–after all, Git wouldn't even be invented for another 3 years. Because of this, the UI-driven configuration paradigm is at the heart of WordPress. It often must be carefully sidestepped when using the CMS to build heavily customized sites.

Having so many features built into WordPress can create a heavy mental burden for non-technical site administrators who manage hyper-customized sites. WordPress's menu builder was built before mega-menus became a design standard. Sure: it's possible to download a mega menu plugin, but this often creates confusion for administrators who have 30+ items on their admin sidebar and multiple screens to configure menus. Custom themes often use custom queries in their templates that have the number of results hardcoded, which can create a confusing experience when a site admin tries to change the "Blog pages show at most" setting. Changing the permalink settings can wipe out a site's SEO and break every link to the site. Many of these sharp edges can't be removed from WordPress.

Other built-in features come with considerable security risks and potential to leak sensitive data. While it's possible to password protect a post, the title of the post may still show up in the search results. I've seen newsworthy information accidentally exposed in the titles of protected posts. A knee-jerk solution would be to make sure that there are no search boxes on the site, but you can search a WordPress site by tacking ?s to the end of a site's domain (like https://example.com/?s). A site admin may think that their identity is protected because their author information isn't displayed on a single post page template. However, it can still be displayed on the archive page, RSS feed, or in the REST API. Leaked author information has the potential to cost the lives of activists who post anonymously in oppressive countries. Yet most users are unaware that their content management system is leaking so much data.

While content management systems like WordPress and Drupal were built with decade-old architectures and assumptions, the Internet was evolving around them. Powerful JavaScript UI frameworks like Angular, React and Vue were starting to take hold.

The age of JavaScript

JavaScript's origin is a peculiarity amongst programming languages. In the height of the "browser wars," both Netscape and Internet Explorer were adding features at a rapid rate in the battle to win users. In 1995, Netscape decided to build a lightweight scripting language as another weapon in their arsenal. They tasked Brendan Eich to build a scripting language for the browser in ten days. What Eich created in his 10-day sprint was an unholy amalgamation of esoteric languages like Self and Scheme that used Java-like syntax. Netscape named the monstrosity "JavaScript," hoping to capitalize on Java's hype.

Not to be outdone, Internet Explorer implemented JavaScript in their own browser. Despite the language being a half-baked project that was thrown together in ten days, it became a pre-packaged feature of all major browsers moving forward. Because of this, JavaScript became one of the most popular languages in the world.

And the web was growing. Application developers started to recognize the benefits of building for the web platform. Targeting the browser meant you could build and distribute applications without needing to worry about the underlying operating system. The proliferation of social media platforms like Facebook led to a need for more powerful tools for managing interactivity. Building JavaScript-based tools, despite the language's hairball nature, was basically the only choice. UI Frameworks like Angular, React and Vue began to dominate the web. A server-side implementation of JavaScript called Node.js was created, and Node Package Manager contained packages for everything from web servers to Sass compilation. Over the course of a few years, JavaScript seemed to take over the world.

The headless CMS experiment

Open source content management systems like WordPress and Drupal took notice of JavaScript's meteoric rise. Both developed REST APIs for their respective platforms. Leaders in these communities started promoting the idea of a "headless CMS," where the CMS would only be responsible for storing and retrieving data. The HTML markup could then be rendered by JavaScript on the front-end. You could even go as far as to build a completely new admin experience on top of the platforms that would smooth out their rough edges. This push was embodied by WordPress founder Matt Mullenweg's State of the Word speech, where his parting call-to-action was "learn JavaScript deeply." The race began to rebuild the Internet with the 10-day scripting language.

A whole ecosystem soon emerged around headless content management systems, with proprietary and open source tools being created at a rapid rate. But cracks in the headless CMS dream quickly became apparent. Tooling for building client-rendered JavaScript apps was too complicated for most developers to implement themselves. User experience issues that were normally handled by the browser (such as loading and error states) needed to be reimplemented from scratch in JavaScript front-ends. And foregoing server-rendering negatively impacted SEO and initial load times. Server-rendered frameworks like Next.js were created to ease the SEO impacts of client-rendered pages, but using them meant setting up and running a Node server alongside the CMS and keeping the two applications in sync. And even with Next's optimizations and SEO benefits, loading Next JS pages on low-end Android devices dramatically increased load times and deteriorated the user experience.

Some developers were determined to keep the headless CMS dream alive and concocted "the JAMstack," a methodology for building websites where all of the pages are pre-rendered to HTML. JAMstack frameworks like Gatsby.js could pull all of a site's content using a CMS's REST API, then pre-render every page as an HTML file. While this is an interesting approach that improves initial page load times, it meant that any change to a site would need to trigger a rebuild that could take several minutes. Ultimately, the JAMstack failed to gain the adoption necessary to realize the dream of headless content management systems.

Despite Mullenweg's rallying call to "learn JavaScript deeply," relatively few development teams use a headless CMS in production because of the enormously increased complexity and questionable benefits.

Gutenberg

While development complexity exploded with headless content management systems, proprietary platforms like Squarespace and Webflow created powerful visual page builders targeted at non-technical users. These tools allowed those with about $20-a-month to manage fully modern websites without the substantial overhead of learning WordPress, Drupal or a front-end JavaScript framework.

WordPress has long had third-party plugins that enabled page-builder capabilities, but the WordPress team decided to bring the functionality into the platform's core. They built a page builder called Gutenburg.

Years after Gutenberg's release, its success has been mixed at best. The page builder doesn't show what the actual page will look like: it's a rough approximation. Once a component has been added to the page, its template can't be changed programmatically because its markup is generated on the client then saved to the database. Server-rendered blocks that enable programmatic markup changes are possible, but they're strongly discouraged by the Gutenberg team. The blessed path for building your own custom blocks is using React JS, which is a dramatic departure from the way that most WordPress sites are developed.

Despite Mullenweg's rallying call to "learn JavaScript deeply," most WordPress developers did not. That's not to say WordPress's push toward JS was a total loss: plugin developers build Gutenberg blocks and leverage the REST API. But much of this functionality is inaccessible to a large proportion of WordPress developers. JavaScript's unusual langue quirks, configuration-heavy tooling, and ever-changing ecosystem kept it out of reach.

Drupal 8: a story of rearchitecting a CMS

After revisiting the past decade of content management, it seems like the best course of action for open source CMS platforms may have been to simply focus on bringing their platforms up-to-date with modern development practices.

That's exactly what Drupal did for its version 8 release. Drupal replaced its legacy procedural code with object-oriented code, and it replaced many of its core components with components from the Symfony framework. It began implementing modern package management with Composer. The hope was that by leveraging tools from the greater software development ecosystem, it could reduce the amount of Drupal specific knowledge needed to build websites and encourage more developers to adopt the CMS.

As you may have expected, the results were mixed. Drupal's Symfony components added complexity beyond what many developers were willing to tolerate to build content-driven websites. Many important Drupal packages took years to migrate their code from Drupal 7 to Drupal 8. Updates to Drupal were split between the UI and PHP's package manager, forcing admins to upgrade in two places. Many organizations chose to rebuild their Drupal sites in WordPress rather than incur the cost of the upgrade to Drupal 8.

In his address to DrupalCon North America 2021, Drupal creator Dries Buytaert reflected on the history of Drupal and why users originally fell in love with the CMS. As he asked the community, he found a common thread: people fell in love with Drupal because it empowered less technical site builders to do ambitious things through the UI. He recognized that while Drupal's modernization efforts brought significant advantages, they disempowered the platform's less technical users.

The state of content management systems

Content management systems are in a peculiar place. Open source platforms like WordPress are still compelling options for individual users to make a blog or build a small website. But as custom development platforms, they tend to suffer from enormous complexity. The causes of this are numerous: ranging from legacy procedural code to usage of dense modern frameworks. It can be caused by build steps and distributed architecture. It can be caused by an administrative interface that lets non-technical users break their site with the click of a button. It can be caused by an impedance mismatch between what the tool was built to accomplish and what users actually want to accomplish with it.

Proprietary systems like Webflow and Squarespace offer a much simpler and more administrator-friendly experience, but it comes at the cost of lock-in and a limited ability to add custom functionality.

The root of the problem may be that we have too few tools that are trying to be too many things to too many people.

WordPress currently powers 43% of the sites on the Internet. These include Fortune 500 company websites, local restaurant sites, and health food blogs. The people building these sites include top-tier development teams, freelance developers, designers who drag-and-drop sites together, and bloggers who don't even know they can change the theme. It's hard to imagine that this single content management system could be perfectly ideal for all of these types of sites, much less all of the types of people who build them. Drupal and others have also had the same struggle of providing the best experience to all of their different types of users.

If the problem is that content management systems are trying to be too many things to too many people, the solution may be to disentangle them from this responsibility. We can do this by building more CMS platforms that cater to more narrow use cases. Webflow has done a great job of this by creating a visual content management system that caters almost exclusively to designers. I'd like to see simple CMS platforms geared towards the design illiterate, and others geared towards non-technical bloggers. I'd like to see content management systems that allow configuration to be committed to code and have a better ability to opt-in to features instead of forcing developers to opt-out. There's more work to be done here.

Forward

Today, people building websites have more focused needs than general purpose platforms are able to support. Years of effort was wasted experimenting with modern architectures that may have unnecessarily complicated the development process. But there is enormous potential. If developers can focus that same engineering effort into building platforms that solve narrower sets of problems for specific types of users, the future of content management will be brighter than it's ever been.