Today I read a great blog post from Dries: Should we decouple Drupal with a client side framework?. As usual, Dries puts a lot of thought into his writing, and braves a shitstorm of responses by laying his thinking bare while he’s still mulling it over. I couldn’t resist adding to the storm.
I completely agree that Drupal would benefit from figuring out a standardized approach to decoupled front ends. I think Dries is spot-on in supporting a “progressive decoupling” model as a great best-of-both-worlds response that can happen within 8.x. I would frame the problem a little differently, though.
The thing is, we already HAVE embraced a framework and shipped with it in core: backboneJS. And we’re dealing with the development cycle delta already: backbone is now quite outdated; in order to keep up we have to consider ditching it in favor of options like react and angular. I don’t think this is a “how do we architect a new part of Drupal” problem, so much as a “we already have this issue and we know it will recur” problem. Rather than trying to decide upon a single framework that will remain relevant for the entire lifecycle of Drupal 8, the goal should be to provide a structure that makes it easy to respond once angular/react/whatever are out-of-date, too.
I advocate taking exactly the PHPTemplate route we took in 4.6 (was it? 4.5?): ship one engine with core, but make it replaceable. There are a few reasons behind this. First, I think Dries’ rejection of this approach misses some key elements: the landscape of PHP based template engines in 2005 is very different than that of front end frameworks in 2015, and the task of replacing a Drupal 4.6 templating engine is very different from that of replacing a Drupal 8 front end framework. Second, I think we’ve stumbled upon a reasonably successful model for adapting to development cycle deltas in how we’ve worked with JQuery in Drupal 7. Finally, I believe that making our front end framework replaceable fits with Drupal’s overall architectural philosophy, and will help D8 stay relevant for longer.
Dries is right to point out that when we did this with PHPTemplate, effectively nobody took advantage of the ability to replace it. But think back to the development landscape of PHP based templating engines in 2005, and compare it to JS frameworks in 2015: the pace of development was was much slower, every PHP project rolled their own system, libraries to extend capabilities were effectively nonexistent, the total number of developers was lower, and the amount of innovation between alternatives was lower. The arguments that make AngularJS compelling, for example (tens of thousands of developers, hundreds of tutorials, thousands of ngextensions, etc), bear little resemblance to the arguments for - what even were the alternatives to PHPTemplate in 2005?
Further, the task of replacing PHPTemplate in Drupal 4.6 is not analogous to the task of replacing a JS framework in D8. We only use backbone to handle interactions and “big pipe” style includes (rather than page rendering out of whole cloth). Dries proposes continuing this approach (and I agree). The task of replacing Backbone with Angular or React would be a big one, but nowhere near as big as building an entire templating engine from scratch for Drupal 4.6. It’s still hard work of course, but you’re not rebuilding a third of the platform, or architecting your own library with a unique approach.
We made PHPTemplate replaceable as a hedge against Adrian Rossouw getting hit by a bus, and because if Adrian wanted to roll his own engine, surely other developers would, too. It turns out that wasn’t necessary; no other templating system gained enough traction to make a dent in the default. That was an effect of the development landscape and the size of the task. This is just not the case with front end frameworks.
In 2005, we were confident that if PHPTemplate was a great choice in 2005, it would probably still be a great choice in 2006, and with care it could remain a reasonable choice for 5 years or more. Replacability was for allowing alternatives. In the case of externally developed front end frameworks in 2015, we can say with certainty that a great choice this year will be an old choice in 2 years, a bad choice in 3, and a liability in 5. That’s a different problem space.
I think we have a better analogy with JQuery than with PHPTemplate. That was also an external library with a development pace delta problem. Within 3 years of including JQuery in Drupal 6 core, the JQuery Update module climbed into the list of most-used modules. For Drupal 7 we architected to make this a little easier, anticipating that it would be necessary. That’s worked out well for us. Fortunately there aren’t a lot of mutually exclusive alternatives to JQuery, so all we’ve needed is updates. Still, I think there are good lessons here for introducing a standard front end framework in Drupal 8: people will need updates faster than core can provide them, and the contrib space is a reasonable place to get them - even (especially?) when the updates are so common they become de facto parts of core.
Finally, a key philosophy for Drupal 8 is that builders can replace or override entire subsystems. Making the front-end framework similarly replaceable fits right in line with this architecture. If I want to replace Backbone with React, I should be able to do that relatively easily. In a dream world we could abstract out the whole thing, and make core front end framework agnostic. THAT would be a monumental task, indeed!
I advise changing the implementation and documentation of backbone in Drupal 8.x to be (more easily) replaceable or augmentable in contrib. I’m convinced that we would see an AngularJS contrib module within a year, and probably a ReactJS one as well. The power law predicts that the community will standardize around one framework at a time, which means that we really only have to be concerned about transition periods. Even then, front end frameworks don’t have to be exclusive. Site builders could include the ReactJS library as a dependency of module X, the AngularJS library as a dependency of module Y, and backbone from core. The people developing sites where an extra 36kB (the size of AngularJS 1.4.8) of page size matters are also the ones best positioned to fully replace one library with another.
TL;DR: Contrib is a great place to handle the ever-changing, rapid landscape of front end frameworks. All Drupal core has to do is make it easy.