Bringing Decoupled CMS Back

By Deane Barker on December 2, 2012

There’s sort of a retro-ish movement afoot to return content management to its decoupled roots.  (No idea what “decoupled means”?  Read Decoupled Content Management 101 for a long-form primer.)

Henri Bergius has written a good post summarizing why he feels coupled CMS comes up short, and making the case that there are several new technologies around right know which mean we could decouple more easily and still retain all of the great benefits of coupled.

He’s fighting the component lock-in he finds with coupled CMS:

Want to use a cool new editor like Aloha, or a different templating engine, or maybe a trendy NoSQL storage back-end? You’ll have to convince the whole CMS project or vendor to switch over.

Things like create.js and backbone.js could conceivably give us the best of both worlds: decoupling, enabling us to pick and choose which CMS components we want, plus the immediacy of editing right in the presentation tier (the browser itself, these days).

The web editing tools have traditionally been part of the web framework, the framework serving forms and toolbars to the user as part of the generated web pages. But with modern browsers you could throw forms out of the window and just make pages editable as they are.

I like the idea of these tools.  They’re designed to enhance CMS in general, without regard to the actual platform.  Glue enough of these together adeptly, and you could create a “new” CMS which is really just a combination of great parts.

There’s already quite a bit going on in the repository space – things like JCR and CMIS – though adoption has been slow.  The presentation components have been slower to catch on, but we’re getting there.

There’s even a website representing the movement:

Decoupled Content Management is a movement to bring clean separation of concerns into CMSs. With it, Content Management Systems can focus better on their core functionalities, and get the missing pieces through code-sharing and collaboration.

When you think about it, decoupled CMS fell out of favor because of limitations which may have been obviated by new technologies.  Decoupled has advantages – has the technology moved to a level where we can make it work better this time?

Comments (3)

Jeff Eaton says:

I’m bullish on the continued growth of decoupled systems. Device and display channel proliferation is improving the business case centralizing actual content management while spinning up lighter, nimbler endpoints.

I have to say that I’m concerned about the excitement around create.js, though. I’m about halfway through a magnum opus on it, but I’m unconvinced that the WYSIWYG edit-in-the-design approach scales beyond very simple content models...

The good news is that tools like create.js do force the hard work of decoupling. And even if more complex projects require tailored/dedicated administrative screens, it’ll be much easier to build them on the back of the APIs that create.js and similar tools need.

Jeff Eaton says:

Man, that first paragraph got mangled by editing. I’m totally not a spam-bot.


Larry Garfield says:

You’re my favorite spam bot, Jeff. :-)

I have a missive on the subject of in-browser editing percolating as well. In the near term, I’m a strong advocate of Create.js in Drupal for the reasons Jeff mentions: Even if it’s not appropriate in all, or even most, situations, the changes and refactorings that supporting a decoupled model require are themselves good and valuable to do in the first place. For me, Create.js’s main value is as a wedge to force a clearer separation between content and presentation/use and to force more attention on APIs that exist independently of forms.

I likely won’t use Create.js myself all that often. But I’m very glad for the changes we’re making in order to support it.