The idea of "separating content and presentation" is sacrosanct in content management. It's considered one of the core benefits of using a CMS at all. It's as close to a universal principle as we have in this industry.

Peer-reviewed white papers have been written about this. The one I linked to there even traces this concept back to Aristotle's ideas of logo and lexis – the content of a speech and the style of rhetoric used to deliver it – proving this idea has literally been with us since the dawn of civilization.

The implied benefit is that your content can stay "pure," meaning free of any applied presentation. Your content is stored as pure data, completely ignorant of how it might be presented.

When you want to deliver content to a channel, you apply some presentation, rendering, or template, and transform it into a form that's easy to consume in that channel:

  • Content bound for a web site gets turned into HTML via some templating language (Razor is common in .NET)
  • Content bound for print gets turned into a PDF, via XSL-FO or PrinceXML
  • Content bound for SMS might get truncated and concatenated with a URL

The possible channels are endless, and still growing. (I cataloged all of the digital channels of my prior company once, just to prove a point: The Slippery Definition of a Digital Channel).

The most common use of a CMS for the last couple decades has been to manage and maintain a website. The idea of content is universal and enduring, but for a long while, websites were pretty much all anyone did. We all talked a big game about "content re-use" and "multi-channel publishing," but for many years, the web was the only thing we were concerned with.

Lots of "web CMSs" (WCM or WCMS) popped up to meet this need in the late 90s and early 2000s. They qualified their names with "web" or "W" to differentiate themselves from the enterprise content management systems (ECM, commonly use for internal company content) and document management systems (an outdated term) that dominated the market prior to that time.

Some systems embraced this role with lots of web-specific functionality. They provided pre-built HTML widgets and built-in web navigation management systems and all sorts of things that were very specific to publishing HTML. Lots of them baked these features in so deep that they became inextricable from the web channel. They didn't manage "pure" content anymore – all stored content was saturated with web-specific features, so it was less useful elsewhere.

Episerver never did this.

Since its founding, and to this day, Episerver manages pure content. It makes no assumptions about what you want to do with that content. Episerver has always believed in the separation of concerns. Episerver's repository can be said to be "abstracted" away from web delivery. (I've been ranting about this forever. See WCM Vendors: It's Time to Abstract Your Repositories from 10 years ago, and Beyond Web-Centricity in Content Management from 11 years ago.)

The relationship between Episerver content and HTML published to the web is loose. In an Episerver instance, content is pure until literally the last moment it goes out the door. Only at that point does Episerver apply a template to turn it into HTML, and this process can be easily side-stepped.

And this was true long before we had a Content Delivery API, or any explicit headless functionality. Almost a decade ago, I was working on Episerver projects that would be called "headless" today, long before that word was on anyone's lips or feature checklists.

(Some nostalgia: back in the Web Forms days, we translated Episerver content into XML from Generic Handlers. This was before MVC, before WebAPI, and even before JSON got heavy adoption. Good times.)

So, if you don't want to render HTML...don't. If not HTML, how would you render the content? Well, that's up to you and your requirements. The sky's the limit.

(I'm now thinking back to the Global Partner Summit in Malmo, Sweden in 2010. Allan Thraen had a CodeMania session where he turned Episerver content into some weird formats based on a querystring argument. I remember an image, a PDF, maybe even a PowerPoint deck? And this was 10 years ago. He could do this because Episerver content isn't any specific format until you tell it what you want it to be.)

(Update: Allan has since provided me with this list:

The most recent article in that list is 11 years old, proving that we were doing headless long before anyone named it that.)

Of course, layered on top of this content foundation are lots of tools to make it easy to create and deliver a website. In a sense, our core content management features are "wrapped" in website management tools. You can work with your content at the pure level, or take advantage of things like URL management, page composition, and other things that only make sense on the web.

To prove this, I wrote some code. I've made it available on GitHub here:

Managing Non-Web Content in Episerver

This is some sample code showing how to use Episerver's API to manage content that might never see the inside of a browser. There's a README file that explains the technical specifics.

(Hint: It's anti-climactic, by design. It looks a lot like the code used to manage all other Episerver content. This is not a coincidence.)

From the README:

Episerver content is based on a hierarchy of classes. The traditional "web" content is actually built on a foundation of more pure content representations.

These objects will never appear in Edit Mode, nor will they have URL – and they shouldn't, because they're not web content.

They're just...well, content.

Not only are these objects easily manipulated with Episerver's API, we now offer a UI to edit them: Content Manager. It's quite simple to configure Content Manager to show you a simple grid or table view of this non-web content, and allow you to create, edit, and delete objects. Additionally, this content is fully available over our Content Delivery API.

Put another way: there's a fully featured headless CMS living inside a more fully-featured web CMS. If you want the best of both worlds, here you go -- use the web tools when you want, and when you need something more generic, well, we've always done that.

As I note in the README:

This is not a new feature. It's not even new code. This functionality has been in the product for years.

In Episerver, not all content is web content. The fact that we use content to generate a website is almost incidental.

It's your content. You decide what you want to do with it.