Nearly a year after I published my first article about the emerging paradigm in content management that I call universal CMS, the reaction has been overwhelmingly supportive. Veteran content authors and seasoned content architects have shared with me how much the concept resonates with them and how they’ve noticed the same trends, albeit without a name until now. And with year-end surveys of developers showing continuing churn and turnover in adoption of web development technologies, content teams are right to be worried about what 2025 brings.
Every time we turn around, there’s a hot new JavaScript framework or digital device to add to our inventory as content strategists and developers. These days, content teams contend with a wide array of front-end presentation layers with names like Next.js, Nuxt.js, and Astro. At the same time, they’re juggling the growing demands of multimodal content in mobile devices, voice interfaces, immersive experiences, and now AI-enabled chatbots. Typically, content editors and others use content management systems (CMSs) to manage, assemble, and deliver content—rich text, images, videos, chatbot interlocutions, and immersive overlays—to these destinations.
But something’s deeply broken in the way that content editors and other stakeholders work inside the CMS to perform these very tasks. It isn’t just because content teams need to preview, schedule, and build content headed for a JavaScript app, an iOS mobile app, or an immersive headset, all channels that didn’t exist two decades ago. Nor is it because developer teams use front-end practices and workflows that look very different from even a decade ago.
It mainly has to do with violations of the grand compromise forged long ago, between front-end developers tasked with building digital experiences and the content folks and design folks responsible for maintaining what they deliver, how they look, and how they perform.
The CMS has long been at the center of these complex negotiations. But the old paradigm, represented by early mainstays like Movable Type and ExpressionEngine and long-lived projects like Drupal and WordPress, isn’t something that developers love working with these days. That’s because monolithic CMSs are by their very nature systems that allow editors and developers to manage content for single websites or sets of websites; their front-end presentation layers that display that content aren’t separable from the CMS and come with a highly opinionated, and antiquated, developer experience.
By the same token, the new headless CMSs like Contentful, Prismic, and Sanity often leave content folks scratching their heads. Headless CMSs are systems that do without the presentation layer altogether and focus solely on managing content as raw data. In the headless CMS, editorial features that have long been held dear, like visual editing, easy previews, compliance and approval workflows, and layout management, have become more fragmented and less functional. This has been slowing down content teams and engineering teams alike.
We need a new approach that’s already seeing adoption across the content-management industry, and I’ve called it the universal CMS. It’s a paradigm in which content is universally editable on any channel, universally developable on any technology, and universally deployable, lifting up both editorial and developer teams.
Many headless CMSs relegate content practitioners and web designers to brittle tools and disparate systems whose integrations break easily and whose mental models seldom overlap, threatening that carefully crafted Black Friday in-store display or that HIPAA-compliant home page. By the same token, many monolithic CMSs force developers to use old and tired patterns to present content on the digital experiences they build.
The CMS of the future isn’t one that values developers over editors. Nor is it one that delights editors but frustrates developers. It’s a renewed balance that honors editorial teams and developer teams, and it empowers them to do the work they need to do without getting in each other’s way. The universal CMS honors both. Content teams want CMS features that were part of the monolithic CMS, while engineering teams want developer experiences that are part of the headless CMS. And all this while the ground shifts below everyone’s feet when it comes to where content needs to go, whether React or Roku.
In the universal CMS, every presentation layer—whether it’s a responsive website or React, whether it’s a native mobile app or Next.js, whether it’s a voice interface or Vue.js—is a first-class citizen. But universal content management isn’t just about the relationships between content and presentation: it’s about relationships between people. After all, the reason that CMSs emerged in the first place was to let editors edit and let builders build. And the people that most need to be treated as first-class again are the content, marketing, and design teams who work with copy, assets, and design systems every day.
Headless CMSs and the pendulum swing toward developers
The headless CMS emerged in the mid-2010s thanks to what frustrated developers perceived as the fossilized state of front-end developer experiences in then-established monolithic CMSs like Drupal, Sitecore, and Adobe Experience Manager. Both headless and monolithic players offered rich layout editing and content preview workflows, but they lacked the snazzy component-driven approaches that encouraged code reusability, consistent design, and better performance—all of which are needed for modern, agile development.
In the historic monolithic CMS, a strict architectural separation of concerns was forged between the server side and the client side. This let content teams directly control how content was visually presented, and it also helped developer teams delegate webmaster tasks so that they could focus on development.
And these unhappy developers were right. The traditional CMS generation forced front-enders to manage their HTML and CSS in other languages such as PHP, Java, Ruby, or Python. In the view of these developers, traditionally monolithic CMSs were too opinionated about how markup and style were managed on the server side before delivering web pages to the browser. In the browser itself, monolithic CMSs either stayed neutral about how to manage client-side concerns like Dynamic HTML (DHTML) and asynchronous JavaScript and XML (Ajax), or they recommended libraries like jQuery and Dojo for small-scale highly granular client-side updates.
A clear separation of concerns leads to concerns elsewhere
The explosion of innovation in JavaScript in the mid-2010s led to a new approach: universal JavaScript. Reaching maturity as headless CMSs began to emerge, universal JavaScript had an enticing proposal: What if you could manage your HTML and CSS at the component level across both the server and client, keeping all of your logic in a single codebase, so that you wouldn’t need to maintain all HTML and CSS on one side and poke at it with piecemeal JavaScript on the other?
Universal JavaScript’s architectural separation of concerns lets front-end developers manage HTML, CSS, and JavaScript more flexibly and maintainably by enforcing a component-level separation of concerns.
In software, separation of concerns is an architectural principle that teaches programmers to divide an application into independent units, each serving a clear function. At the time, many web designers criticized the notion of JavaScript managing HTML and CSS, and they saw this as antithetical to the architectural separation of concerns between markup and style. They viewed JSX, a paradigm that interpolates HTML elements into JavaScript, as a cardinal sin.
But today, universal JavaScript is now ubiquitous across our industry. Early headless CMSs immediately adopted a new architectural separation of concerns between content as data (text and assets) and content as presentation (the display of and interaction with that content for end users). First, they wanted to enable front-end developers building on any framework and for any channel, not just one, in order to broaden their appeal. They also wanted to avoid being locked into a single rigid approach to front-end development, unlike the monolithic CMSs that came before them. And finally, they wanted to use universal JavaScript’s control over both server-side and client-side rendering as an opportunity to remove the CMS from questions of how content displays once and for all.
The headless CMS, which grew quickly partially in response to the advent of universal JavaScript, facilitated shared JavaScript implementations across both client and server, but it relegated content teams to managing content solely as data without input into content’s appearance in presentation layers.
In response to these three trends, headless CMSs quickly rallied around the separation of concerns between content as data and content as presentation. But they didn’t realize at the time that content is far more than just raw data to be handed off to developers for the taking.
Content is about more than just data and code; it’s about people—the designers, content authors, brand marketers, compliance officers, legal counsel, and accessibility experts who need to make sure that that content remains usable, well-written, compelling, compliant, and accessible. By advocating an architectural separation of concerns in code between content as data and content as presentation, headless CMSs made the strategic mistake of enforcing a new functional separation of concerns. In other words, they built a new wall separating editors who work with content from developers who work with code—both of whom need the CMS in order to collaborate on how content is presented, but no longer could in the headless CMS.
Universal JavaScript can teach us a great deal about CMS
Many of us who came of age in the web-standards era saw what-you-see-is-what-you-get (WYSIWYG) page builders like FrontPage and Dreamweaver as problematic, given their proclivity for melding markup and style in ways that generated unmaintainable spaghetti code. Web standards brought us a clear separation of concerns in the early 2000s: HTML as markup and CSS as style (table-based layouts, begone!).
Both the web standards era and the universal JavaScript era demonstrate that the key reason why separations of concerns move around is because it makes people’s jobs easier. But whose jobs become easier, and at what cost?
Why developers wanted universal JavaScript
Today, we often see markup and style separated anew into distinct concerns in the prescriptive “right way” to build, as represented by discrete JavaScript components that drive both logic and presentation. In part, this was a reaction against jQuery’s and Ajax’s tendency to mix markup and style in ways that violated that time-honored separation of concerns (jQuery’s .css() method is a clear example). But JavaScript developers also wanted easier ways to manage HTML markup and CSS style in component-level ways that didn’t force them into relying too much on the document object model (DOM), like jQuery and Ajax did (and did very well!).
The skyrocketing adoption of universal JavaScript taught us something useful: ultimately, what everyone wants at the end of the day is something graceful and easy. Developers gravitated toward universal JavaScript because it eliminated the need for two code repositories managed separately. No more back-end and front-end code written in different languages—instead, one language straddling them both, making that code more manageable and understandable. Universal JavaScript empowered developers to separate their code into components that contained everything they needed:
HTML markup (imported from markup components such as JSX)
CSS styles (imported from style components, such as Emotion, also known as CSS-in-JavaScript), and
JavaScript logic (in the same component or imported as reusable code from other components)
This freed developers from what they saw as archaic developer experiences too firmly rooted in the server-versus-client separation of concerns and the static website. It also let them leap headlong into what was for developers a newly liberating approach: separations of concerns between individual components, making codebases neater, more legible, and more maintainable.
Why editors want something universal for themselves too
From an organizational standpoint, content isn’t all that different from code. What makes content tick in CMSs isn’t just its nature as data—whether that means rows in a MySQL database or JSON objects. For CMS users who aren’t developers, content is also, at its core, about presentation: how it reads and how it displays, and how it sounds and how it’s spoken. When it comes to editorial and marketing teams, content is more than just atomic units of data; it’s the layouts, templates, and drag-and-drop construction that visually present data in shifting ways based on content teams’ priorities.
By limiting content to be nothing more than just data, headless CMSs have violated a subtler separation of concerns that doesn’t show up in technical architecture diagrams. They’ve told content editors that “content as data” is their sole concern and that “content as presentation” should be left up to the developers. Despite the fact that monolithic CMSs are ill-prepared for JavaScript-driven websites and cross-channel content, content teams that stay on these systems remain loyal to them because they honor a functional separation of concerns between developer teams and content teams.
It’s time to stop limiting content teams to data entry and saddling developer teams with the complexities of reenabling editorial workflows. Instead, headless and monolithic CMSs need to learn from one another about why developers love headless CMSs and why content editors love monolithic CMSs. CMSs can and should maintain a stellar developer experience for engineers and, most importantly, one user interface and one mental model for editors, making their content more manageable and understandable, no matter where it’s headed.
The advent of the headless CMS led to a new functional separation of concerns between content as data, owned by content teams, and content as presentation, owned by developer teams, reassigning many editorial needs having to do with content as presentation from editorial ownership in the previous monolithic CMS to developer ownership in the headless CMS.
JavaScript developers wanted more graceful and seamless ways to interact with their code, and in trying to achieve that, they violated the previous server-versus-client separation of concerns and restored the age-old markup-versus-style separation of concerns. Content teams want a similar form of empowerment. They want graceful and easy ways to interact with their content. Yes, this empowerment violates the headless CMSs’ data-versus-presentation separation of concerns, but it restores the age-old code-versus-content separation of concerns typical of the monolithic CMS generation.
Just as developers restored a markup-versus-style separation of concerns in their journey from PHP and jQuery to JSX and CSS components, content teams want to restore a code-versus-content separation of concerns, not to flail in a functional separation of concerns between data and presentation. This code-versus-content line in the sand was the reason why many organizations implemented a monolithic CMS in the first place, and they rightfully want to keep the level of visual and presentational control they had before.
In the emerging CMS paradigm known as the universal CMS, a functional separation of concerns creates a clear distinction between concerns that developer teams and content teams have within their own functional teams and shared concerns that straddle content and developer teams.
Cross-functional concerns that developer teams and content teams share, such as preview, approval, and compliance, also match the component-level architectural separation of concerns adopted by many JavaScript developers.
Stalwart developers who were more accustomed to jQuery and Ajax’s mental models learned much from universal JavaScript about what today’s front-end developers want. In the same way, currently resistant headless CMSs who believe “architectural purity” trumps honoring the needs of all CMS personas can learn much from content editors. Yes, developer experience still matters. And yes, editorial experience still matters too.
Conclusion: Visual building and preview are still what content editors and designers miss most
The core problem with headless CMSs’ separation of concerns between “data as content” and “data as presentation” is the reality on the ground. Content teams working with CMSs aren’t satisfied with simply entering their data and trusting that those objects and assets make it into JSON for delivery through GraphQL or REST APIs, without any involvement in how that data is presented.
What content teams want is what they’ve always had in the monolithic CMS and what they feel has been taken away in headless CMSs: visual and presentation management tools that involve people on many different teams, each with their own incentives. Layout building, preview flows, templated components, and compliance and approval workflows remain nonnegotiables for content teams that care deeply, and rightfully so, about faithfulness to design systems, accessibility standards, marketing benchmarks, and government regulations.
We’ve seen headless CMSs struggle over the years to reinvent the wheel to restore the editorial workflows that made monolithic CMSs like Drupal and WordPress so successful in the first place. These are key needs like visual editing, preview, compliance, approval, scheduling, and more customizable workflows that interact with other CMS features and other products. All of these concerns were easy when the static website was all that the monolithic CMS generation had to contend with, and that’s why Drupal and WordPress remain so popular. But now, the CMS needs these workflows to be in place for channels like augmented reality, digital signage, and voice assistants, in addition to frameworks like React, Vue.js, and Astro.
That’s why we’re seeing a great “rebundling” in their products and ecosystems to partially reverse the disruptive “unbundling” that catalyzed the growth of headless CMSs in the first place. In the second installment of this article series, I’ll share why the universal CMS paradigm is gaining such steam in the industry and how exactly this “rebundling” can take shape in an optimal way for both content teams and developer teams alike.
Special thanks to Ashley Bischoff, Valeria Brigatti, Aaron Gustafson, Freddy Montes, and John Michael Thomas for their feedback during the writing process.