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,
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.