About two weeks ago, I had the opportunity to visit Nashville for the first time and attend my second DrupalCon, the U.S. conference for Drupal. Nashville is a fantastic city with a lot to do and see, even if country music isn’t your thing (it isn’t mine). Pro tip? Your Lyft drivers can tell you all of the best things to do while you’re in town.
There were a few themes running through DrupalCon this year, but the two most prominent that I saw were layout building and decoupled architecture. I attended the core conversation on the page builder that was released as an experimental module in Drupal 8.5, and there are really interesting things ahead for this project (and I still think Drupal is handling this better than WordPress). What grabbed me as being most memorable, however, were some of the great conversations around progressive de-coupling,
The web continues to move full-steam ahead toward a completely API-driven model for content management systems, giving front end developers the ability to be free of back-end architecture and work exclusive with a set of JSON endpoints and whatever frameworks they choose. Or, at least that’s the theory. In practice, both WordPress and Drupal have made the decision to adopt core JavaScript frameworks (a good thing), but appear to both be drinking Facebook’s Kool-Aid. Both are making the unfortunate decision to use the over-tooled, overly-opinionated, bloated monster that is React. I’m deeply concerned about how much this alienates and forces over-specialization onto developers. That’s a conversation for a different post, however.
At DrupalCon, I attended a core conversation called A Farewell to Twig. You can check it out here, but I’ll also summarize below.
What Exactly is Twig?
For those who don’t know, Twig is a PHP template pre-processor. It’s baked into Symfony, which is the PHP framework upon which Drupal 8 core is built. Drupal 8 introduced it as the driving force in the theme layer, and, in doing so, implemented an excellent example of what a solid MVC architecture should look like. Twig is very easy to work with, even for non-PHP developers (the syntax is remarkably like Vue.js or Angular 1), and is extremely performant on the front-end. This is something that I really, really wish WordPress would implement in core, especially as there is a viable plugin option out there, because it makes the presentation layer very easy to work with and forces the developer to adhere to the best practice of keeping business logic out of the template.
The Drupal community received Twig very positively, and most WordPress theme developers that use it react positively, as well, in my experience. The learning curve to the template language is very short, and I think that this was a great decision on Drupal’s part.
How This Impacts Progressive Decoupling in Drupal
In the core conversation above, you’ll hear that there is a discussion ongoing about the possibility of shipping Drupal 9 with no theme layer at all. That is, it would be “headless” out of the box, ready to have a front-end developer apply whatever stack they want to build the front-end of the site. This provides more flexibility than having the content management system be “monolithic”, and is a positive evolution in how the CMS functions in today’s web landscape, or so the argument goes. And I don’t disagree, at least not completely.
I just don’t think that a monolithic CMS is necessarily a bad thing.
The issue that I see is that what is really good for part of the web isn’t necessarily good for all of the web. I think the mistake that the Drupal core team is making in considering this option is speed…they’re rushing into this in an effort to be bleeding edge with their technology, and, in doing so, failing to consider everyone that Drupal serves.
A completely de-coupled architecture solves a lot of problems for enterprise clients. It also involves significantly increased development time, but this isn’t an issue for most enterprise clients. It is for small businesses, many of whom would otherwise benefit from Drupal. There’s a lot of Drupal users out there who want a more out-of-the-box solution, something that they can make their own with the smaller development budget that an individual or a small business would have. Should Drupal 9 be completely headless by default, options are removed (something that seems strangely counter to Drupal’s reputation for flexibility) and a large portion of the market share would yield to another CMS, likely WordPress.
Not A Competition
I’m not approaching this as a competition between WordPress and Drupal. I like both for different reasons, and they both solve the same set of problems in very interesting ways. I think of these “competitors” as different tools with different strengths that are useful in different scenarios. Should Drupal choose to eliminate a theme layer entirely, however, then the set of scenarios in which it is useful shrinks dramatically. I hope that the core team slows down, considers the landscape, and realizes that options are great, and shipping a fantastic headless CMS doesn’t necessitate removing a fantastic theme layer.
The web has a vested interest in both Drupal and WordPress succeeding and being the best CMS each can be. Here’s to hoping for continued forward momentum from both.
Also attended this session – very interesting discussion. I didn’t walk away thinking that ‘completely headless by default’ was the likely scenario (although it was discussed). Making Drupal decoupled by default, but also shipping with a Twig frontend was proposed as well. In theory that would address the needs of smaller projects that need an out of the box option (or even just those who know and love Twig.) It is an early discussion though, so we’re all kind of making guesses at this point 🙂
Hi Brian,
Agreed, these are the very early stages of the discussion, and this was only one option addressed. I felt like there was disagreement on the core team…one person felt like there was no need for a theme layer, another felt like having the option was the best move. There’s a lot more internal discussion going on, I’m sure. It was certainly the most involved core conversation that I attended 🙂
Thanks for reading!