Three years ago, I developed several convictions related to "headless Drupal" or "decoupled Drupal". I believed that:
(For the purposes of this blog post, I use the term "framework" to include both full MV* frameworks such as Angular, and also view-only libraries such as React combined piecemeal with additional libraries for managing routing, states, etc.)
Focusing on Drupal's web services instead
The end result? Drupal's web service APIs have progressed significantly the past year. Ed Faulkner of Ember told us:
- It made it harder to accelerate certain improvements to Drupal's authoring and site building experience.
One trend we are now seeing is that traditional MV* frameworks are giving way to component libraries; most people seem to want a way to compose interfaces and interactions with reusable components (e.g. libraries like React, Vue, Polymer, and Glimmer) rather than use a framework with a heavy focus on MV* workflows (e.g. frameworks like Angular and Ember). This means that my original recommendation of Ember needs to be revisited.
My recommendations at DrupalCon Vienna
- Invest more in Drupal's API-first initiative. In 2017, there is no denying that decoupled architectures and headless Drupal will be a big part of our future. We need to keep investing in Drupal's web service APIs. At a minimum, we should expand Drupal's web service APIs and standardize on JSON API. Separately, we need to examine how to give API consumers more access to and control over Drupal's capabilities.
There was unanimous agreement that:
- We want to have sufficient real-use experience to make a final decision prior to 8.6.0's development period (Q1 2018). To start, the Watchdog page would be the least intrusive interface to rebuild and would give us important insights before kicking off work on more complex interfaces.
- While a few people named alternative options, React was our preferred option, by far, due to its high degree of adoption, component-based and unopinionated nature, and its potential to make Drupal developers' skills more future-proof.
- This adoption should be carried out in a limited and incremental way so that the decision is easily reversible if better approaches come later on.
We created an issue on the Drupal core queue to discuss this more.