Earlier this week Dries Buytaert, creator and project lead for Drupal, opened up a discussion on his blog about the future of Drupal architecture in a post titled Should we decouple Drupal with a client-side framework?
Buytaert contends that users have come to expect application-like experiences from websites, given their experiences interacting with the Facebook news feed, Gmail inbox, and Twitter’s live stream.
“Many of Drupal’s administrative interfaces and Drupal sites could benefit from a similarly seamless, instantaneous user experience,” Buytaert said. “As Drupal’s project lead, I ask myself: how can our community feel enabled and encouraged to start building rich user experiences?”
The discussion to decouple Drupal with a client-side framework comes at an interesting time, as Matt Mullenweg’s State of the Word address heralded JavaScript as the future of WordPress and the web. His closing remarks encouraged developers to learn JavaScript and start building WordPress-powered apps for the future.
A commenter on Buytaert’s post draws a connection to Automattic’s release of Calypso:
It feels like this post is at least in part a reaction to WordPress’s announcement of Calypso. Hopefully we can focus on making the decisions that are right for Drupal’s future rather than reacting hastily to what another CMS is doing, particularly when you have talked over and over how WordPress is not Drupal’s true competition.
Buytaert maintains that his considerations for Drupal were independently motivated, and this isn’t the first time he’s written about decoupling the back and front end(s).
“As for WordPress’ announcement of Calypso — I actually started writing this blog post before Calypso was announced,” he said. “I don’t believe my position was influenced by Calypso.”
Buytaert prefaced this discussion with the fact that users have come to take application-like experiences for granted as the baseline for interaction on websites. The entire web is moving in this direction and CMS’s like Drupal and WordPress are now forced to climb this mountain if they want to remain relevant. Both projects are playing from behind, trying to catch up to users expectations.
The Challenge of Standardizing a Framework
In many ways the discussion on Buytaert’s post is pertinent to where WordPress is headed, especially the consideration to standardize on a particular framework.
Buytaert advocates for a progressive decoupling for Drupal’s admin and end user experience while also enabling fully decoupled experiences to be built on top of the platform. He proposes that the best way to do this is “to formally standardize on a full-featured MV* framework (e.g. Angular, Ember, Backbone, and Knockout) or a component-based view library (e.g. React, Vue, and Riot).”
As he is not a front-end developer, Buytaert is soliciting input from the Drupal community on what framework would work best for progressive decoupling. He also acknowledges reasons why standardizing a particular framework might be inadvisable in the long run:
Despite the potential benefits, there are also good reasons not to embrace a single client-side framework. New front-end frameworks are being created at what feels like an unsustainable pace; every nine months there is a new kid on the block. It’s hard for a project as large as Drupal to embrace a single technology when there is no guarantee of its longevity.
Nevertheless, Buytaert believes that a thoughtful selection and periodic reassessment of the framework can overcome these drawbacks.
When encouraging WordPress developers to learn JavaScript, Matt Mullenweg did not identify a single framework but left it open. Since Automattic’s Calypso is built on React, it seems to be an early favorite.
If WordPress core ends up adopting the technology behind Calypso (or a Calypso-like alternative) to deliver a better publishing experience, will core standardize a framework/library or will it continue to enable and encourage extension developers to use any framework?
One commenter points out potential problems with Drupal selecting a framework, which some may perceive as an official endorsement:
There are already a lot of enterprise projects using a decoupled Drupal approach and naturally they use a lot of different frameworks, but the one I see used the most is React. In fact on the project I’m working on right now, the organization is going all in with React. If Drupal settled on Angular, for example, how would it affect the organizations that are making big investments in other frameworks? Maybe I don’t understand completely how it might work, but the choice of a single framework seems like it could be divisive and disruptive – disruptive in a bad way, not the SV way.
I think making decoupled architectures easier is great and should be something Drupal does, but it should do so in a way that is agnostic about the FE framework used.
Buytaert identifies a few alternatives to shipping a client-side framework with Drupal core, including recommending a framework but not shipping with it, or including it in core but making it easy to replace with the developer’s choice of another framework.
His post and the comments that follow are the beginning of a lively, thoughtful discussion that will help shape the future of Drupal development. Today Buytaert is calling for proposals that would outline a prototype for a working version of progressive decoupling.
Would be interested in reading a proposal on how to prototype a working version of progressive decoupling: https://t.co/tJxT66cKoy #drupal
— Dries Buytaert (@Dries) December 11, 2015
Both WordPress and Drupal are currently engaged in the struggle to make the technological leap to provide more application-like experiences for users. The conversation surrounding decoupling Drupal’s architecture is an important one for WordPress developers to follow and learn from.
Loved the choice of the featured image on this one