I’ve heard too often from the enterprise companies that I advise that they’ve leapt headlong into headless architectures in content and commerce implementations, only to reverse course as they realize key editorial features need to be rebuilt from the ground up, often with shaky interactions or confusing interfaces. Recently, I spoke with an enterprise that was sold a headless CMS solution to resolve their developer experience ills, only to discover that after they had bought the product that they would have to rebuild visual editing, preview, approval, and compliance workflows from scratch—at a huge expense. The resulting editorial issues led them to abandon their subscription altogether and return to a monolithic approach.
For engineering teams, this is a nightmare. Now, instead of focusing on adding new features that the company needs, they need to divert their attention to restoring key editorial workflows in CMSs that don’t include them out of the box, slowing everyone down. For content teams, it’s an unmitigated disaster. They have to wait for developer teams to build, enable, and configure homegrown integrations and interfaces that should’ve come packaged with their content management system, as they’ve always expected.
So many organizations have shared with me that they don’t have the resources internally to build these things themselves, as many headless-CMS vendors suggest that they should. These organizations use pricey development consultancies that they want laser-focused on value-adds. Or they simply don’t have the engineering resources internally to figure out how all the pieces fit together. And of course, more relevant in today’s industry uncertainty, many in-house development teams have seen layoffs stymie their ability to do internal-facing work unless it involves an external customer.
Honoring approval, compliance, and design system fidelity
I understand why headless-CMS vendors want to get out of the business of “content as presentation” altogether, not just from an architectural perspective. After all, this sort of faithfulness to editorial requirements and loyalty to design systems is only getting more complicated by the day. Today, content doesn’t just get displayed in Next.js, Angular, and Svelte. It’s also presented in multimodal ways in in-store displays, kiosks, Vision Pros, and Amazon Echos.
But rather than ejecting content teams from the visual editing, preview, approval, and compliance processes that they’ve long held dear, content management systems need to do a better job of reenabling them. Many of the headless CMSs widely used by developers have preview plugins that fall apart easily or aren’t understandable. In some, editors with multiple concurrent preview flows aren’t given a clear, live preview of content they’re looking at, since preview URLs so often open in a new window with a gobbledygook URL—a staging environment’s calling card that leaks its abstractions to the surface. In others, marketing requirements like content scheduling and content embargoing are simply impossible to enforce cohesively for headless architectures and omnichannel delivery.
This is especially true of visual editing and layout management, a cornerstone of the monolithic CMS feature set. Even if drag-and-drop visual building is possible in headless CMSs, there are costs borne elsewhere: extreme opinionatedness about how front-end developers need to write their JavaScript components, for instance, or a layout builder that simply displays “black boxes,” obscuring what content the editor is actually placing where.
Granted, this stuff is hard. Add digital experiences beyond the web to the mix, and things get even harder. For many years, I’ve asked the same questions both committed purists and overstretched marketers are posing: What happens to preview, approval, and compliance workflows in immersive and voice channels? How do you schedule, embargo, and A/B-test content destined for an aural rather than visual destination? And what happens to accessibility compliance where the Web Content Accessibility Guidelines (WCAG) are just one of many new emerging standards to respect, like the World Wide Web Consortium’s maturing XR Accessibility User Requirements?
The universal CMS
The answer is a renewed equilibrium: the universal CMS. In the early 2000s, as CMSs first began to make their mark, the only presentation layer we had to worry about was the humble static website, written only in HTML and CSS. As long as CMSs could exert control over both markup and style, content teams were free to manage content and build layouts, and developer teams were free to add functionality on top. But the world today looks very different from those halcyon days.
Headless CMS vendors critique the old “legacy” way because, as they rightfully claim, the static website is just one member in a myriad of digital channels. Alongside the static website stand JavaScript apps, mobile apps, in-store displays, and voicebots as possible conduits for content. But this is only the tip of the iceberg. A data-versus-presentation architectural separation of concerns satisfies developer teams at the expense of content teams. It only erects a new, functional, code-versus-content separation of concerns that’s less visible and more subtle. And that carries the risk of intensifying cross-functional friction across content and engineering departments.
The universal CMS, already here in limited ways, doesn’t extend the status of first-class citizen just to the static website, as storied CMSs did before, nor just to developer teams, as headless CMSs do today. It grants first-class status to all presentation layers in both JavaScript and beyond the web—and, perhaps more crucially, all teams that work with content whether as developers or as CMS users. The universal CMS restores our prior balance: a clean architectural separation of concerns thanks to universal JavaScript (and other web-renderable technologies), and a clean functional and organizational separation of concerns thanks to editorial flows that work regardless of the channel or framework content ultimately ends up in.
Developer ecosystems took the first step
Developer ecosystems that emerged around both more established CMSs and headless CMSs are now engaging in convergent evolution. More CMS vendors are publishing software development kits (SDKs), tools for developers to cater their own applications to a particular product. In addition, ready-made code examples empower everyone to do their best work by getting out of the way of front-end developers while still letting content editors manage content on and off the web.
While at Acquia, I authored the initial version of the JavaScript SDK for Drupal, Waterwheel.js, and released a headless Drupal distribution, Reservoir. I worked with a squad enabling developers working with new front-end paradigms alongside Kyle Browning’s Waterwheel.swift for native mobile application development and Mateu Aguiló Bosch’s Contenta ecosystem for decoupled Drupal. Today, every major CMS, in a “race to the middle” and to a reforged equilibrium, has a vibrant set of SDKs and other tools that keep key tethers to editorial features intact while accelerating the work of developers.
Graceful visual integration with CMSs is the second step
But simply serving content data and layout information to front-end frameworks isn’t enough. Editors need more. They want the ability to build their own layouts, preview their own content, manage their own workflows, and assess their own compliance—all without saddling engineers with that cognitive load or distraction. They want to do everything they were able to do with the static website, and to do it all with JavaScript and cross-platform frameworks, immersive and voice interfaces, and AI-generated components and layouts.
On the headless CMS side, new players like Builder.io, Uniform, and Stackbit (which was acquired by Netlify in 2023) are focusing on ways to enable visual control for content teams, agnostically across all JavaScript frameworks. No more React-only or Vue.js-only CMSs, and no more CMSs that offer a great developer experience for Next.js or Gatsby developers but leave Nuxt.js or Gridsome users behind.
A screenshot of the Universal Visual Editor in dotCMS, which lets content teams visually edit and manipulate Next.js (and other) applications.
On the traditional CMS side, established products like dotCMS and Adobe Experience Manager, and upstarts in the Drupal ecosystem (Blökkli and NodeHive), are opening new doors for developers to interact with upstream content, and they’re also building new visual editors that work agnostically across front-end frameworks too. At dotCMS, Freddy Montes is hard at work on our Universal Visual Editor, a unified editorial experience that powers drag-and-drop building and preview agnostically across JavaScript frameworks.
The next step, of course, is to do all of this for more than just JavaScript, especially as JavaScript continues to hold sway as the de-facto language for developing on and off the web. As I predicted five years ago, exciting times are ahead for prospects like voice interfaces and WebXR-driven virtual-reality previews in the context of the editorial experience.
Granted, architectural purists see these visual building features as a betrayal of their principles and oppose this convergent evolution. But as CMS customers and CMS vendors know, content teams saw the erasure of these features as traitorous too. And that’s regardless of whether those layout management features were architecturally defensible at the turn of the millennium in the first place. After all, there’s no way to rewind history.
The universal CMS respects the reality on the ground today. Yes, we need CMSs that don’t pay lip service to architectural purity and the data-versus-presentation separation of concerns. But let’s learn from the ubiquity of universal JavaScript, which led to many developers violating a prior separation of concerns simply because they wanted to make their lives easier. By setting aside an architectural separation of concerns that only emboldens a functional separation of concerns, we’re letting the people who are at the core of content do their best work.
Conclusion: The best of all worlds
If you ask what developer teams and what content teams want, you’ll always get a flurry of answers that have nothing to do with one another. That’s why, after all, they typically sit on different sides of the back office. To suggest otherwise would lead to chaos. The content management system grew out of an organic need for both developers and content editors to do what they do best without stepping on each other’s toes.
In today’s world, where new delivery channels like voice and augmented reality are in the mix with new JavaScript frameworks like Svelte and Astro, we need a paradigm for content editing and content management that honors this timeless divide and empowers people, not just things like content and code, to do what they do best.
The universal CMS elevates everything and everyone to the level of first-class citizen: not just React and React Native, not just voicebots and Vision Pros, but also the people and teams that build content, whether programmatically or visually. Because the people working with our content are just as important as the people who read and hear it. After all, isn’t that the whole reason that we work with content in the first place?
Special thanks to Ashley Bischoff, Valeria Brigatti, Aaron Gustafson, Freddy Montes, and John Michael Thomas for their feedback during the writing process.