DrupalCon Baltimore, Heads or Tails?

Every few years at DrupalCon, a new theme sweeps through the community. It’s a conceptual theme—a motif, a forward-looking glimpse into the future (not the kind with a .info file). The topic tends to dominate conversations and fill sessions. People have varying ideas of how to best approach the new frontier.

When I first began attending DrupalCons in 2011, I remember the hype about responsive websites: the difference between responsive and adaptive layouts, which grid system to use, and how to best add and target classes to efficiently apply media queries.

In 2014, there was a natural and communal shift in interest to Drupal 8’s frontend. Twig was the new kid on the block and everyone wanted a taste. Developers aimed to learn the new syntax and eagerly compared the new D8 techniques to their tried and true D7 counterparts.

This year at DrupalCon Baltimore, the hot topic has been headless Drupal. Decoupling Drupal’s frontend has been buzzed about for years, but in the past it seemed to be just that—a buzz word—a conceptual, potentially problematic, but exciting idea. Today, on the last day of DrupalCon, it’s clear developers are not just buzzing anymore, they’re building headless Drupal sites and loving it. Amazee Labs is building headless Drupal sites and loving it.

Amazee’s history with headless Drupal is a complicated one. In fact, our own Michael Schmid pointed out during his and Brandon’s React, GraphQL and Drupal session, how Amazee Labs was both skeptical and dismissive of the decoupled/headless vision when the idea initially emerged. In the last quarter of 2016 however, Amazee’s stance on headless changed. I’d encourage you to review Michael and Brandon’s Wednesday session for a deeper explanation as to the reasons behind that shift. 

Technology is a rapidly changing thing and always will be. As developers, it’s natural to feel more or less acceptance towards some changes than others. As a frontend developer who’s grown to master and enjoy working in Drupal’s theme layer, the shift to headless is a tough pill to swallow. I’d equate the sensation to experiencing some kind of loss—there’s a kind of mourning for all the hard, long hours put into building expertise in a complex, yet rewarding theme system. I’ve grown to love Twig, transforming Drupal’s notoriously bad markup into something simple and semantic, and creating truly beautiful Drupal experiences “the old fashioned way.”

Dries published an article Tuesday during the conference, Drupal is API-first, not API-only. In the post, he discusses the benefits of preserving the coupling between Drupal’s front- and back- ends, at least in part. His summary on headless CMSs has validated many of the thoughts I have regarding a fully decoupled Drupal. There are reasons to remain coupled, reasons to go headless, and reasons for a middle-of-the-road approach.

We are certainly future-looking at Amazee Labs. As a company, we are committed to enhancing our team’s skills and providing clients cutting-edge solutions. My takeaway from DrupalCon Baltimore is to embrace and learn new skills required to build innovative headless frontends while simultaneously working to improve and educate others on Drupal 8’s theme layer. The best of both worlds. Let me hear from you, fellow frontend Drupal devs—what’s your take?

April 28, 2017

Get our Newsletter


Deep down, there's a nagging feeling about where Drupal is ultimately heading in the long run. A main driver for the decoupling craze -- and the underlying fear of becoming an "API-only" player -- is Javascript itself.

Drupal was born in an era where the backend mangled data then blindly spat out HTML to a thin client, to which we eventually -- and awkwardly! -- attached Javascript enhancements. As Javascript is maturing, there is a power shift to the frontend, which is becoming what could be qualified as HTML-formatted Javascript. And once you factor in the potential of universal/isomorphic applications, you soon start to reconsider the use of PHP altogether (and Symfony and YAML and Twig and...).

I love Drupal, i wouldn't be where i am today professionally without it. But being relegated to API duties seems like a cancer diagnosis. And Drupal shouldn't fear becoming "API-only", that will probably be left to a thinner entity; it should start worrying about becoming "backoffice-only", until a pure Javascript CMS comes along.

By Droop
4 months ago

Drupalcon Baltimore has been solid prove that Drupal 8 is catching steam. Good to see everyone adapting to it rapidly!

By Hamza Zia
4 months ago

I agree with Droop. Once you go headless (in some flavour) the next step is serverless (in some flavour). The Drpualcon presentation about Amazeelab's work was for a very specific use case. Yes, it is an inspiring acheivement. Nevertheless we need to keep some perspective.

One question is how much Dries's thinking is swayed, perhaps unconsciously, by trying to square the offering of Drupal with the needs or perhaps the headless expectations of Acquia customers. The needs of the biggest Drupal agencies are of course an important part of the Drupal world, considering how much Acquia and other big suppliers contribute. The risk here is that their commercial needs may skew the thinking which informs core development into trying to adapt Drupal a use case where it is unlikely to be a winner.

By John_B
4 months ago
What is Amazee Labs?