What exactly are we trying to do here? And is there another way to do it?
Headless/decoupled Drupal has received a lot of buzz in the last year. But the rise of decoupled Drupal has also been met with due skepticism, as there are significant challenges. We’re not here to further that flame war; you can find the details elsewhere. In some specific cases, taking the decoupled approach can be worth the cost of dealing with those challenges. But in many — if not most — cases, that list of challenges outweighs the novelty of decapitation.
At Advomatic, we’ve been exploring how to achieve the same goals of decoupling, while avoiding that hefty list of challenges.
The direction that we’ve been heading is to use styleguide-driven development (SDD).
First, what do people typically mean by decoupled/headless Drupal?
Let’s also define what we mean by styleguide-driven development.
We’ll go into more details in the next article in this series, but for now, when we talk about styleguides, we are talking about a set of fully functional, reusable elements and components, built and themed outside of Drupal, using idealized markup. This includes all generic HTML elements, (headers, lists, blockquotes, etc.), native Drupal components (pagers, menus, alerts, etc.), and site-specific components (carousels, listings, features, etc.)
So what are the goals of decoupling? And can SDD accomplish them just as well?
Recently our colleagues over at Lullabot published an article describing the underlying goals of the decoupled approach. Some items on their list are related to APIs. Styleguide-driven development does nothing for your APIs. If you know that one of the primary content delivery methods for your project will be through an API, maybe decoupled Drupal is for you. If you don’t need to have an API, or if the API is going to be a second-class citizen, then decoupling could be a case of YAGNI.
I would argue that one of the goals in the Lullabot article — abstraction and constraints reduce individual responsibilities while promoting content reuse — while an important topic, actually has nothing to do with decoupling.
I’m adding another of my own, so that leaves us with this list of goals and how decoupling and SDD address each:
Less reliance on Drupal specialists
More self-contained upgrades
Want to upgrade to Drupal 8 without a redesign, and only a minimal theme upgrade? Want to revamp the look and feel with minimal changes to the back end? That’s now easier with both decoupling or styleguide-driven-development. Because the front end and back end are less tightly coupled, you can make a major overhaul to one with less impact on the other (compared to if both are a single system). We should note that at this point this is entirely theoretical. The movement is still too new¹ to see many (any?) examples of this in practice. I anticipate that in reality stakeholders will almost always want to make changes to both at the same time.
Allowing front-end and back-end teams to work simultaneously
This is where both decoupling and styleguide-driven development really shine. In the olden days the back-end team would start building the website while the front-end team would be sitting on their hands waiting until there was something to work with. Similarly at the end of a project the back-end team would finish up while the front-end team frantically pulled all-nighters to fix all the cross-browser bugs. In our next article of this series we’ll delve deeper into how a parallel workflow with styleguide-driven-development can look.
Ultimately, we believe that the styleguide-driven approach has the potential to meet the same goals as decoupled/headless CMS development, but it does so in a way that bypasses many of the challenges. In the next post in this series we’ll get into the details of what exactly this looks like for a typical project.
In closing, let’s back up for a second and talk about how we should go about making decisions about which tools to use when building websites.
“Right tool for the job” – another abused one. The intention here is reasonable: who wants to use a tool that isn’t appropriate? But a rare perspective is that this can be detrimental when taken to the extreme. A carpenter doesn’t arm herself with every variation and size of hammer that is available, even though she may encounter hammering tasks that could be ideally handled by each one. Why? Because lugging around (and maintaining) a gazillion hammers incurs a cost. As such, decisions on this axis have trade-offs.
— John Allspaw
It’s both too expensive to try and build everything with the same tool, or to learn a new tool for every project. At the same time, some tools only work for a very narrow use-case, while some tools can be used for a broad range. Are we hitting the limits of what we can do with small chunks of HTML, CSS, and (minimal) JS? How far can we take the styleguide approach? We see the future looking very bright, both in terms of where the web community at large is headed, and at Advomatic we have some ideas for how we can make components more reusable across Drupal projects (look for a future series of articles on this topic).
1. The idea of a decoupled website had some degree of popularity way back in the late 90s, but the flavour that we see now is different enough that it’s difficult to draw many meaningful comparisons.
Other posts you should check out
- Decoupling Drupal Without Losing Your Head — Part 2: From Styleguide to Final Product
- Styleguides in Drupal
- Automating Living Style Guides in a Drupal Theme
- Views in Drupal 8: Improved Displays
Looking for a central resource for all things decoupled? Pantheon just launched an awesome resource for decoupled CMS.