Drupal logo inside React logo
Image caption
Worst logo ever.

Dries (the Drupal project lead) recently announced a proposal to the community regarding the question of integrating Drupal with a specific frontend library. He is proposing React. In this article I will try and analyse the possible motivation for this move as well as give my own two subjective cents on the matter.

Submitted by martin on Wed, 10/11/2017 - 11:02
Some kind of decoupled illustration.
In theory this is what decoupled looks like.

Why a decoupled backend?

This question has been discussed since "decoupled" and "app" became buzzwords in their own right within the industry (depending on who you ask this happened 7–2 years ago). Before this announcement by Dries it was always clear that Drupal should be decoupled and should have a backend written in a modern frontend library but there was never a final conclusion regarding the exact framework.

Implementing a fully decoupled backend for Drupal makes sense: Not being tied to the classic browser request-response feel will make the editing experience much nicer. Wordpress.com has been doing this for some time with their decoupled admin app calypso.

Also I personally hope that implementing a fully decoupled backend as a community effort will enable developers to implement decoupled frontends much easier in future since the problems that undoubtedly still exist will have to be fixed to have working decoupled backend. (And these fixes will also apply to the soon-to-be-decoupled frontend)

Drupal logo with lots of arrows
Decision-making involving a lot of shareholders is always difficult.

Why did this take so long?

Reaching a decision regarding which frontend technology to use is always difficult:

  • Frontend is young, Just like the web itself. So there is a pronounced lack of old-hands to guide the decision making progress.
  • Frontend technology is fast moving (and short lived): Great stuff is happening at an almost alarming rate. This makes it difficult to commit to one specific way of doing things since that always means missing out on future developments in some way.
  • Shareholders of frontend are numerous: Frontend is what people *see*, everybody can see a website so the amount of shareholders and people who want to be a part of any decision is much greater than with backend-related decisions of the same magnitude.

… In this case all these problems were greatly amplified by the magnitude of the question. In addition: Drupal is a software written in PHP and running on the server, frontend is merely the "front" for this core. It makes sense that most members of the community are very experienced with PHP and the Drupal stack and conversely not so much with Drupal-unrelated frontend-y tech.

Another weird Drupal logo illustration
I'm sorry I did this to you, Drupal logo.

The proposal

The following approaches were the main contenders, according to Dries:

  • Angular
  • Ember
  • React

I don't want to do a framework/library comparison at this point because it has been done before. A thousand times. Or more.

According to Dries the main factors to propose an official integration effort React were:

  • Unopinionated view libraries have become more popular than fully-fledged frameworks
  • Facebook, the company behind React has dropped its controversial BSD+Patents licensing, which was the main problem with this option
  • React is the most popular frontend technology right now.

At 1xINTERNET we are currently implementing several complex decoupled apps built on Drupal. (For various reasons we have also chosen React as our main view library at this point.)

I think this is great news! I don't care so much which particular library will be used officially because I think implementing the backend in a decoupled manner in any way will even the way to do the same with any other method/technology. I think the blocking issues at this point are caused by certain issues that Drupal has exposing its internals as an API. These will all need to be fixed and rigorously documented for any progress to happen. But once this is out of way decoupled backends/frontends can be implemented easily (I say easily: of course it's a complex ardorous thing to do, but that's up to the implementation to solve and no longer due to the Drupal plattform itself)

Having said that, members of the community have complained that React does not embrace web components in the same way that Vue does, for example. (also Vue is much more a community effort than React). I think this is a valid point but as I noted above I think at this point any implementation is better than no implementation.

One of the difficulties I see facing this project is the need to be able to incorporate all the thousands of modules and specific module administration screens into the decoupled backend. I assume Drupal will expose the forms API as an declarative forms API for the decoupled backend to render. I think the exact architecture of this point in particular will be very important for the quality of the resulting interface.

Also: Even if the community does decide to go with React there still remains the question of state management. Since React is basically only a rendering library the state management (= "controller") of the backend will need to be implemented using some other solutions. Commonly this is done with Redux in the React community, but there are also a lot of other solutions which could and should be considered.

The proposal is currently being discussed on Drupal.org – So if you want to join in on the discussion, go ahead!

In general I am very happy that the discussion is moving forward and a possible prototype is imaginable. A lot of issues can now be adressed and at the end of the day Drupal will be a more feature-complete software. Also the community will be more attractive to frontend developers who don't want to learn PHP coding (or even a server side template language like Twig*)

* I know Twig can also be used on the client but I don't think anybody really does this.

Add new comment

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

Baddý Breidert

»Let's talk about your project and how we can help!«

– Baddý Breidert M. Sc., CEO

Phone: +49 69 976 711 50
Email: office@1xinternet.de