I got my start on server-side web development in the mid-‘90s. 

I got my first computer in 1995, gradually taught myself web development, and by 1999 was working as a developer in a corporate IT shop. Law school was but a fond memory.

One year later, my team would build the website for an NFL team. 

The web was a crazy place back then.

What the Cutting Edge Looked Like in 1999

Back then, content management systems were still pretty rare. We were just excited about web programming in general. We were nowhere near solidifying practices and norms to the point where we could bundle them into a system.

The only things on the market were the "old guard,” massive platforms like Interwoven, RedDot, Stellent, Vignette and FatWire. They all cost well into the six and seven figures.

Open-source existed, of course, but it was less than approachable for any developer who didn't grow up on command lines. Consider that Midgard wouldn't be released until 1999; Drupal, 2000; and WordPress, 2003.

So we wrote little programs as web pages. We talked to our custom databases through ODBC or embedded mysql_query calls, and FTP'd files around. 

Looking back, it's quaint and perhaps even adorable, but it worked and we didn't know any better. We were pretty much all self-taught and we were genuinely cutting edge (as dull as that edge may look today).

Headless CMS: An Advance and a Retreat

Fast forward to the present, and the CMS world is gushing about the "headless" paradigm. 

I’ve found it fascinating to watch and write about

Lately, I'm beginning to wonder if my fascination doesn't come from a place of comfort and nostalgia. Because headless is both an advance and a retreat — which makes it a wonderful opportunity for reflection on our industry.

Eleven years ago, in a blog post called "Content Publishing Models,” I had the revelation that there were different ways to get content from a repository to the end consumer. I posited these were the Big Three:

  1. Template Pull
  2. Full Stack
  3. Data Push

The names seem ridiculous now, but here's where I was going with it, starting with #2:

Full Stack 

Full Stack is what we now call "coupled." At the time I wrote this, we had just started playing around with eZ Publish, which "owned the request." It intercepted the inbound URL and did some voodoo to get content to respond to it.

I wrote:

“In this case, your CMS ‘owns’ every inbound request. It's usually accomplished via goofy URLs or cleaner rewrite rules. Every request is fielded by the CMS, which maps it to content and templates and spits out the result. Content and presentation are managed in the same system.”

Can you sense the astonishment? 

MVC frameworks would eventually muddy this line even further. The history of web development reached a weird point where URL-to-file mapping disappeared (blame Rails?), which led to the ascendancy of the coupled CMS.

Data Push

Data Push is what we now call "decoupled." This is where systems push data assets into a delivery environment. When I wrote that, my experience was with Movable Type, which actually wrote out flat files.

“In this instance, your CMS essentially becomes a big code and/or data generator. During the publishing process, it creates files and writes them to the file system (or a remote server), via the file system, FTP, or other process.”

And now, after years and years of decline in the face of the coupled model, decoupled CMS is making a comeback.

But the final model is really interesting: Template Pull. 

Template Pull

In 2006, Template Pull was by far the most common model, and the basis for all the custom content-managed websites we created.

Learning Opportunities

"Templates" were simply scripts combined with markup which would execute and "pull" data into themselves. You'd build a database, write a custom admin, then create some executable web files (ASP, PHP, ColdFusion, whatever) and start reading in querystring arguments.

The key here — and the thing that reverberates through the headless models of today — was that your database and "admin interface" were one thing, and your delivery templates were another. 

The two sides essentially met at the database: one side put stuff in, and the other side took it out.

Even earlier than that, in 2004, I wrote about this in a post called "CMS Administration vs. Presentation Languages”:

“The presentation of content is usually pretty easy, while actually getting content to the 50-yard line of our situation — through creation, adding of metadata, approvals, various workflows, etc. — is the real value-add of content management.

“I say use whatever language you need to program your CMS, but don't feel compelled to use that same language for presenting the content.”

Wow. The cringe is real. But it demonstrates how Headless CMS has brought us full circle, the modern embodiment of what I wrote about in 2004. 

The Next Big Thing in Content Delivery

Headless systems handle editorial workflow — content creation, editing, approval — and store the content in highly accessible form to be retrieved and templated by other systems (using other languages). They don’t present content to the end user. They just manage it and stage it some environment, waiting to be retrieved.

Sure, the details have changed, but the basic architecture is the same: a CMS manages our content and "publishes" it to the "50-yard line." Our custom code pulls it from there and displays it to the end user.

My budding assertions all those years ago might have been prophecy:

  1. Data Push = Decoupled
  2. Full Stack = Coupled
  3. Template Pull = Headless

Decoupled was The Thing. Then we needed agility in the presentation layer, so coupled became The Thing.

Then client programming began its rise. Decoupled started to creep back because of its myriad core advantages and the Javascript-driven mitigation of its core disadvantage. For a moment, it seemed like it was going be The Thing again. But then smartphones exploded, social media descended on us, the multi-channel era truly dawned, and now headless is The Thing.

What’s Old Is New Again

What's driving these shifts? I believe that it's clearly changes in client technology. Browsers became better and we started doing more programming inside them. 

Then social media became its own sort of "browser" by forcing us to deliver on the multi-channel promise and treat content as objects rather than pages. Then apps and mobile came along and undercut the idea of an HTML client altogether.

The industry continues turning around in circles, adapting to whatever the consumer does next. The basics haven't changed. No matter the specific methods on either side of the 50-yard-line, content still has to be modeled, aggregated, edited and delivered.Any delivery model that can do that has a shot at becoming The Thing. For a while anyway.

How we deliver content has shifted multiple times, to the point where it seems to have turned back on itself and ended up right where it started. Despite all that, the core questions of content development, editorial workflow, and content management remain roughly the same.

Perhaps this just proves that content is really The Thing, and delivery is just, well, details. 

fa-solid fa-hand-paper Learn how you can join our contributor community.