Drupal Community Considering a Decoupled Architecture

Saucer separation - photo credit: Memory Alpha
Saucer separation – credit: Memory Alpha

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.

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.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

3 Comments


  1. To be clear, what Dries is proposing is that we standardize on a framework for the *admin experience* of Drupal. I don’t think anyone would deny that Drupal 8 modules decoupling their administrative UIs using a variety of different frameworks could quickly devolve into something hopelessly unmanageable.

    There is no plan to standardize on a framework for the *end-user* facing parts of Drupal. Of course a standard framework on the admin side would be a core library available to the end-user facing side as well, but that wouldn’t stop developers from progressively decoupling end-user experiences with a different framework in the same site or indeed fully decoupling via REST to a single-page app.

    To my mind this is really a best-of-both-worlds solution that balances harmonization and flexibility. Even in a worst case scenario where the Drupal community settled on a framework that did not grow or that proved inappropriate for our needs, innovation on the end-user side will provide us with a rich well of experience to course-correct.

    Personally I don’t think we need to worry about that since our community process for making these types of decisions is very rigorous, open, and has a great track-record, for example the choice of Jquery for inclusion in Drupal 7 at a time when it was far from as ubiquitous as it has since become.

    Report

Comments are closed.