Decoupled Drupal: from an Ember maintainer's perspective

Drupal project lead Dries Buytaert recently launched a community discussion by asking "should we decouple Drupal with a client-side framework?".

My high-level takeaway from the discussion is that the Drupal community is serious about finding shared solutions to common problems. Which is great, and matches the Ember community's philosophy. That might sound trite and obvious, but much of the wider Javascript ecosystem is only slowly catching on to the value of comprehensive community solutions. I see a lot of organizations incurring long-term technical debt because of the misguided belief that things will be simpler if they hand-curate their entire Javascript stack out of micro libraries and "pure Javascript" -- a phrase you'll hear depressingly often that really just means "written entirely in-house instead of leveraging community-supported abstractions".

Drupal users can achieve an awful lot without writing a line of code, and a big piece of that is the wonderful module ecosystem. That kind of success is only possible through a lot of community building, shared conventions, and thoughtful API design. The Drupal community should definitely evaluate Javascript communities through that same lens. To get the benefits of standardization, consider what the Drupal-standard solutions would be for Javascript build & deploy tools, dependency management, data fetching, state management, and template rendering. A lot of popular libraries only solve a few of those pieces and have no community consensus around the others, which makes plug-and-play module ecosystems much harder to achieve. My pitch as an Embereño is that we work together to find or build the best possible standard solution in each of those areas, and provide it as the default choice -- without foreclosing the possibility of customizing any area when its truly important to your app.

Regarding progressive and full decoupling: there are two important competing forces to balance. The first is that I'm a big believer in steady evolutionary improvement over radical rewrites, which is an argument in favor of progressive decoupling. Drupal's community and technology are both built on PHP-driven rendering, so it's very clear that PHP-driven rendering needs to be first-class.

However, the second competing force is that maintaining two separate rendering systems adds friction and complexity. This is why Javascript is inexorably swallowing so many applications -- it's much easier to move your Javascript to the server than your PHP to the client. The optimal place to render any given piece of content may change even within a single user session. So over the long-run, I am betting strongly on architectures with predominantly Javascript-driven rendering.

Overall I agree with Dries' assessment that progressive decoupling is the best path forward for Drupal. There are elegant hybrid approaches, and I have shipped examples of them for organizations who wanted client-side interactivity & persistence without sacrificing their existing investment in traditional CMSs. In the Drupal context, I think we could take advantage of the existing block abstraction to build a nice bridge between the Javascript and PHP worlds so that existing PHP-driven blocks can happily coexist with Javascript-driven blocks.

Tactically, I think the best way to discover what's going to work for the Drupal community is to build one or more prototypes of Drupal's own admin interface as decoupled apps. The admin interface is very clearly an application (as opposed to a content page), and its complexity makes it a great test case.

Finally, one piece of a related content that may be interesting: John O'Nolan's reaction to the Calypso announcement goes into some detail on how the Ghost team went through a similar process of examining demo versions of their admin interface in multiple Javascript frameworks before settling on Ember.