The idea of a “headless CMS” is gaining momentum lately. If you’ve not heard of it, the concept is that of a decoupled CMS in the sense that content storage and management is handled entirely separately from the presentation.
The idea, which is truly a re-hash of a debate that also occurred a decade ago – is that today’s optimal content management system isn’t one that also handles the display of the look and feel of the content it manages. It simply manages the raw, structured content in a unified repository. It then makes the content available as a “service” through an API and it is up to the developer to create and develop the presentation layer; be it in a web site, web app, mobile app etc… And, now, there are some that are passionately arguing for this model to be the new standard.
This is wrong.
Now, it may be that some of the people weren’t around when we debated the agility, flexibility and ultimate scalability of this model ten years ago. But, the argument remain the same.
- It doesn’t necessarily make you more agile or speedy. In order for this model to truly be more efficient, or create more agility – it requires front end developers to come up with re-usable design components that either look or behave the same way in displaying the content. Cut it any way you like – but that’s a template. So – the only question remains is will the CMS manage the template, or will your developer team - using some common framework.
and….
- This is a product issue, not a reason to default to a development approach. Going headless can actually provide a good number of benefits. This is especially true for those looking for custom types of presentation layers that many CMS’s simply can’t support. Or, it can make sense for the (rarer) need to manage a single repository with multiple editing tools. Many CMS’s – such as WordPress or Drupal - have long forced the template and look and feel to be managed within it. And a good number of other “enterprise” CMS’s have templating requirements that are so arcane that custom development can actually be faster. But these are product issues – not a reason to force a singular type of approach to content management.
Ultimately, by completely (and irretrievably) separating the idea of display and management – we risk creating yet another silo in our content development process. There are times when both headless and head-full content management approaches make better sense.
I’m tempted to say that having both capabilities is really a “hybrid” approach. But, really this is just a fully featured approach that a company should simply expectfrom a modern content management system. Any modern, enterprise CMS should have the ability to manage content in a normalized, structured repository, and make that content available through standard APIs and development frameworks such as AngularJS. And, any modern CMS should also have templating abilities, and inherent behavioral controls that can help a company display and publish personalized, beautiful, custom designs.
That’s truly the CIO and the IT leaders in the organization that should make the call about whether and where design and display is developed. Your CMS should be able to keep both in the right headspace.