What's in a name: "Headless" vs "Decoupled"

c4rl's picture

Naming things! Our favorite pasttime.

Wondering based on some recent conversation on what people think of the word "Headless" vs "Decoupled."

Any objections should the latter replace the former?


Headless is just so much more

mirzu's picture

Headless is just so much more catchy, and captures the imagination, regardless of it's technical accuracy. I'm curious to find out more about why the name inflames so much. Also we have talked about both and more people listen when we talk about headless.


joshk's picture

We're trying to start something of a movement here — both in terms of getting people who engineer Drupal systems to care about this use-case, and in terms of getting Drupal people to put more value on front-end development.

IMHO "headless" has more marketing mojo.

Only local images are allowed.

Only local images are allowed.

I think we're undertaking a social initiative as much if not more than a technical one. IMHO there's nothing wrong with following up a name with a more factual paragraph to make sure people understand what we mean.

My +1 is for keeping the name the same because being catchy matters.

Headless is just so much more

q0rban's picture

Headless is just so much more catchy, and captures the imagination, regardless of it's technical accuracy.

How are we determining what is catchier or not?

I'm curious to find out more about why the name inflames so much.

Here's why I am on the "Decoupled" side: there already is a "Headless" Drupal. It's called Drush. :) Also, we've been talking about Decoupled Drupal for years, and people know it as such, and can search for it as such. Changing the name means all of the great content out there about it becomes that much harder to find.

we have talked about both and more people listen when we talk about headless.

Can we quantify this statement?


joshk's picture

How are we determining what is catchier or not?

There's a mix of anecdote — enthusiasm for the topic in conversation, degree of interest, etc — and quantitative data.

A number of people trying to interest the wider community in these ideas have found greater responses to the "Headless Drupal" concept. That's anecdote.

"Headless Drupal" was the name chosen for this group. There's no "Decoupled Drupal" group, which

"Headless Drupal" has 81,800 hits on Google (as a quoted string) vs 1,710 for "Decoupled Drupal". I'd also note that there seem to be more diverse hits with tutorials and working code for the former, whereas the latter has mostly session presentations and some duplicate content on the home page.

Twitter search seems more active for "Headless Drupal" (as a phrase) vs "Decoupled Drupal".

Based on this mix of data, I think there's a difference in what has popular momentum.

Ah, I see, so we are using

q0rban's picture

Ah, I see, so we are using the community creating the technology as a gauge for what is catchy. The concern I have with this is that the people creating the technology are not the same people that are paying for the technology. While Headless could be catchy and intriguing for the technically minded, it could be confusing and off-putting to the people that are ultimately going to make the call on whether or not the approach is acceptable. That's why I ask how we're determining what is Catchy. I feel like we should be asking ourselves who we care about it being catchy for first. In our experience at Lullabot, the CTOs understand what a decoupled approach is—that's because it's not a Drupalism: http://en.wikipedia.org/wiki/Coupling_(computer_programming). They are used to using proprietary software that takes a similar approach, and most call it by the same name.

Excellent Point

joshk's picture

That's a totally excellent point.

For my part, trying to build momentum through GDO/etc is a developer-centric activity, and the key outcome from this group is greater alignment around the use case from people building Drupal, and greater interest from innovators in the front-end space in using Drupal as a backend for their use-cases. Basically I think the goal is to make Drupal better at this use-case.

If the goal were to promote Drupal to CTO's, a more technical term would absolutely be the way to go. This is probably a project that's worth doing too!

How about t('headless')

RobKoberg's picture

How about t('headless')

Decoupled Drupal could mean

moshe weitzman's picture

Decoupled Drupal could mean hundreds of things, not just the fact that Drupal's response building is decoupled from its theme system. Decouple database layer from views. Decouple entity storage from entity query. And so on.

If we are looking for alternatives to HEADLESS, I would go back to Web Services or REST which is what everyone else calls it.


eaton's picture

I'm not particularly enflamed by it, but in the broader CMS world "decoupled" is generally understood to mean what we're calling "headless" in this group. I think inside the Drupal community it suffers from some terminology collision due to the fact that code decoupling is a big priority as well -- and fully decoupled code doesn't necessarily imply decoupled site architecture.

The only downside I can see to using "headless" in this context is that it implies that the delivery layer is someone else's concern. A well-engineered site may enforce decoupling, but there still needs to be collaboration and a good feedback loop between the front and back end teams.

I agree.In fact we should

tkoleary's picture

I agree.

In fact we should follow this line of reasoning to it's logical conclusion. If headless Drupal is synonymous with decoupled site architecture then focussing on the server-side part and hand-waving the client side code to be handled "however the front-enders want to" is leaving out half of the equation.

So decoupled is definitely the right term but it implies a direction which may not be the one everyone wants to take, which is fully removing rendering from Drupal into an entirely separate, but interoperable, piece of software that is concerned only with composing and rendering a presentation layer on the client side that can consume data from (back-end) Drupal.

If I understand their documentation correctly, this is precisely what Typo3 has done, and what others are moving towards.

Just to clarify, I am not suggesting departing from the stated desire of the group to support many different ways to feed content from Drupal to single page apps, but making the the theme and render system the core of a fully decoupled presentation-layer management system.

@eaton yep - I mentioned a

scottrigby's picture

@eaton yep - I mentioned a "Decoupled Frontend" in a few other posts because as you said that's what other communities call it… but also to disambiguate it from another kind of setup where Drupal is only interacted with through the services layer (the actually headless scenario). We've been working on the first scenario, where we still use Drupal's admin backend, which isn't really headless.

Framing expectations

stevector's picture

I think this question comes down to what is this group expects to be the focus of its work.

It could focus on documenting and cleaning up the way one can use Drupal 8 with tools like Angular and Backbone. The todo list on this groups front page lists such work. If that is the goal (working with Drupal 8 without the provided GUI) then Headless is a fine term (http://en.wikipedia.org/wiki/Headless_software). Though Moshe rightly points out that we already have some overlapping terms.

I think the goals of the group might be broader though. I understand the the goal of this group to be something like: "I want to replace the provided 'head' with one of my choosing and the rest of Drupal shouldn't care." As the Horseman repo puts it: "The first step towards creating a system where a Drupal generated front-end and an API driven front-end is to make both of them driven by an identical, presentation independent data model."

We won't reach that goal just by improving and documenting REST module. The goals listed in Horseman require overhaul what happens between calling drupal_render() and printing the contents of a twig file. Horseman seems to say that doing Headless Drupal will remain overly painful as long as Headed Drupal is overly painful.

For what Horseman describes (easy swapping between the provided 'head' and a custom 'head') "Decoupled Frontend" seems like a better literal fit. Todd Nienkerk recently posted a slide deck in which he used "Decoupled CMS" extensively. https://twitter.com/ToddRoss/status/495245469543849984 I just wish those terms sounded as catchy as "Headless."

Beheaded Drupal

Bevan's picture

"Beheaded Drupal"?

I do not really think "Beheaded Drupal" is a good name. It gave me a good chuckle though!

"Headless" is indeed catchy (maybe because it is provocative).

I was not certain that "Headless Drupal" and "Decoupled Drupal" were in fact talking about (almost?) the same thing until I read this thread. That is why I felt the need to provide so much context when starting "What role does Drupal play?" and even ask "Is this headless Drupal?".

I think "Decoupled" is even less clear though. Perhaps we need to work on a simple short explanation of what "Headless Drupal" is to help educate others more effectively (and clarify to ourselves).

I suspect people may be inflamed by "Headless" because it implies;

  • "beheading" which is very negative and implies complete death, and people love Drupal
  • not using large parts of Drupal, that people have put so much care and energy into creating

In my opinion, the term

q0rban's picture

In my opinion, the term "Headless" is misleading and incorrect. The real Headless Drupal is Drush—people that are not familiar with Drupal who first encounter Drush are often introduced to it as, "it's a headless interface to a Drupal site." In addition, the term Decoupling Drupal or Decoupled Drupal has been around longer than this term Headless Drupal.

Headless vs. Decoupled might miss the point

krlucas's picture

I believe that this group was created in response to Carl's Austin talk:

Thus, "headless" vs. "decoupled" misses the point.

If you want to consume "pure" un-rendered data from Drupal using some client, that is pretty much already possible in Drupal 8 core and possible in D7 with contrib.

If I understood Carl's presentation correctly, he was suggesting that we ought to be able to provide rendered bits to a full on page or to a REST request more selectively. We also ought to be able to organize and create our templates with a little more freedom than having to use Drupalisms like "node--content--type" or "field-foo" or "views-view-whatever" or "field-collection-thisorthat" and instead use more semantic and atomic naming patterns.

It wasn't necessarily about freeing ourselves from the Drupal render/theme API as much as it was about making those APIs better.

My company's front-end team is CMS agnostic and generally Backbone.js centric. Nonetheless they don't want or expect to render all HTML on the front-end. They just want to be able to get at the rendered bits in a straightforward and consistent way. That's far from decoupled or headless.

(No subject)

krlucas's picture

Does it matter what we call it so long as we define it?

BLadwin's picture


Regardless of name, what are we doing? Are we building a new theme layer that renders data from any external source [not just Drupal]? Are we using a decoupled system to process data entered elsewhere? Did I just ask the same question, twice?!?

Everywhere else, this type of decoupled system is called "Web Services" or "REST" or "RESTful Web Services." If we're going to leverage RESTful Web Services, we shouldn't be ignoring the basic fact that REST is there to allow CRUD to happen. Even if we're only focusing on the R[etrieve] part of CRUD, I still think that we need to align our efforts in a way that doesn't just solve our individual needs.

I think one way we can more easily define what it is we're doing with headless/decoupled Drupal will be easier if we define which version of Drupal we're focusing on. With D7, it seems that AngularJS [or other MVC] mixed with either RESTws or Angles [contrib module] or Views Data Sources [contrib module] is the way to go - I would agree. In D8 however, we have REST built in. This means that we could potentially leverage a ton of what Drupal's theme layer already does, but outside of Drupal. In place editing, now more easily transferred from the theme layer to outside. Rendered pages, and their layout, now easier to assemble outside of Drupal.

tl;dr: Maybe deciding which version of Drupal we're planning to build a decoupled system for will help us decide a way forward. Personally, I feel that trying to shoehorn this "external data fed by D7" thing into a decoupled theme layer is [almost completely] pointless. REST already works in D8, let's move forward.


I'm a bit late to this party,

ldpm's picture

I'm a bit late to this party, but I've been using D7 as the workhorse for processes that are mostly about machines talking to other machines, but also require a logging component. So there are basically two stages:

1) Drupal converses via REST (or AMQP, or whatever) with other machines, transforming data as it goes.

2) a human being logs in to view a report about the results.

So 99.999% of the traffic is API-driven, and I don't need to build a separate GUI for admins. I've been calling it "headless", but "decoupled" works just as well as far as I'm concerned. To me, the main point is about identifying that there are "users" who are machines, and that Drupal can work just as well for those users as it does for people.


@bladwin's point is good. We

krlucas's picture

@bladwin's point is good. We should clarify which versions of Drupal we care about. Also, thanks for implicitly calling out the use of "bikeshedding". Caring about the major version is not that at all.

@ldpm I think this group is probably not about one server talking to another over REST but about using client-side (browser) frameworks (like Angular or Backbone) to communicate with Drupal. Probably in a way that allows the client-side developer to know as little as possible about Drupal itself.

Fair Enough.

ldpm's picture

@krlucas, it's a fair point and I only heard about this group at Drupalcon Austin, and I'm certainly not going to try to hijack it. The description of this being from the point of view of the client (e.g. Angular) is very descriptive, and you're certainly right, that's not what I'm doing.

I'll add that "what we call it" is pretty important if you want to help other people like me not get confused and come wandering in here. @q0rban's comment is rather on-point; "Headless" implies "no browser", at least as it is used as a term of art within, say, the "Headless Webkit" community. "Decoupled" is probably more apt.


A client got a little uncomfortable (blame ISIS)

burningdog's picture

I'm late to this conversation, and don't have any technical opinion about "decoupled" vs "headless." But last week I did a presentation to a client about the technology I'm going to use to build their site: angularjs on top of "headless drupal" and she got very uncomfortable, saying she'd just got back from the Middle East and what with all the beheadings going on there, could we change "headless" as soon as possible? Which I did.

So, something anecdotal and once-off, but worth mentioning in the context of this discussion. No-one wants a tech presentation derailed because of something semantically loaded.

Fair point

joshk's picture

Renaming a group on GDO isn't something I can do, but this could be something to consider in terms of getting more widespread adoption.