It's been official for a while now: Drupal will adopt React.js to it's administration interface. This was announced shortly after the Vienna DrupalCon, a last of it's kind held in Europe for now.

In a Drupal.org post the core team said they would be looking at a number of options, but once BDFL Buytaert put down his word, it was clear that Drupal will use React.js.

More news followed in a blog post describing the approach for a radical reimplementation of the administration interface of Drupal:

Having discussed this at length during our weekly initiative meetings, we decided to build an administration interface that is completely separate from Drupal itself, and would only consume it's APIs (aka decoupled). The application would also attempt to generate administration forms for some configuration scenarios.

- Drupal JavaScript Initiative: The Road to a Modern Administration UI

Initially the plan was to adopt React gradually, similar to what the project had done with jQuery and Backbone JavaScript libraries in the past. Fast forward some six months and the plan has changed to rebuild the Drupal administration interface completely based on the Create React App boilerplate. This is a radical departure from what Drupal has done in the past regarding it's admin interface.

In it's current state all of the interface in Drupal will be rebuilt from ground up using the latest and greatest of front end technologies. The latest and greatest of front end technologies. In 2018. This will mean that the interface is now locked into a specific technology in a field that continues to be rapidly evolving. With React.js patent woes now a thing of the past, and WordPress is fully committed to it with captain Mullenweg at the helm, React will be around forever. But it's not the final solution.

Bespoke is bespoke, bulk is bulk - admin interfaces are bulk

While the leap for the core UI is a welcome idea, similar to what WordPress announced in 2015 with it's Calypso admin shell, the problem with a new admin shell is that the whole Drupal community will need to adopt it as well. This is why WordPress is still developed on it's old core technology almost three years after the announcement of the Calypso. This is not to say that there has not been progress, as is shown by the gradual adoption of the Gutenberg editor in WordPress core.

React is a great option for building interfaces, but as it stands it's most suitable for developing bespoke web applications. Content Management Systems, on the other hand, tend to become a platform built on patchwork of plugins/modules/extensions. Each of these needs to attach and have capabilities to modify the administration interface. Currently there are few, if any, projects that would show that a complete SPA build with React.js is the ideal way to go here.

That's not to say React is not the way forward. Drupal's enterprise arch rival, Microsoft SharePoint, has adopted React as it's framework of choice for administration interface customisation:

Obviously customisation [of SharePoint] is still something that needs to be done even in such environments. As a stark change to it's previous approaches where it has tried to push it's own product, Microsoft has decided to adopt React as the recommended UI library for extending Sharepoint.

- React is the UI framework for extending SharePoint

This is very much what the WordPress community has decided to do. Once there is a de-facto framework in place, developers can work with whatever methods they choose best. Parts of the UI remain server rendered, there is no universal convoluted JavaScript web build process when adding new plugins, etc. Whether you want to use Web Components, Vue or React.js is all open to the developers - even if React is the recommended option.

Technology transition taxes the community way beyond the core

The greater Drupal community is still amidst a transition from 7 to 8. While bleeding edge devs have been on Drupal 8 for years, the vast majority of sites continue to be powered by Drupal 7. The promise for Drupal 9 has been to be API compatible with Drupal 8, but if the new UI is being accelerated and pushed as the main option in Drupal 9 - the community will be shocked once again.

The danger here is that for a long time there will be two user interfaces ran in parallel. The Drupal ecosystem is built around reusable modules to add functionality. With the colossal work required to rework existing modules to the new UI it will be likely that many modules will never get supported by the new bold interface requiring 100% REST API coverage. This will likely take years and generate churn and frustration in the community.

It is sad to see that the gradual adoption plan was switched to chase down shiny technology, without good thought on the long term effects on the community. With the original monolithic model of Drupal, falling out of favour it no longer has the module moat it had to protect it will dry up. Soon there might be no particularly good reason to use Drupal, and it will be further entrenched in the Enterprise niche Acquia is chasing. If the brand won't be too tarnished by security issues.

This is a time to observer why WordPress is number one. They are practical and make conscious choices that benefit the user. Also, they've got a helluva better track record in creating user interfaces that people of all walks love to use.