The future of Drupal front-end development
Adopting new technologies or ways of working in existing projects is never easy. In this article, I will explore some of the challenges that the Drupal community faces in the adoption of React as a front-end technology.
One of the things that I've noticed as a member of the Drupal community, is that the skillset of a front-end developer is a lot different within Drupal than outside of it.
One of the points raised in a BoF at DrupalCon Amsterdam is Drupal's focus on the JSON:API. With the inclusion of the JSON:API in Drupal core it has become the standard for Drupal installations. It's now the first thing that people exploring decoupled Drupal will see. Even though there is great support for GraphQL in the contrib space, the inclusion in core means that the most resources will now be allocated to the JSON:API.
This decision is in sharp contrast with that of the React community. Pushed by Facebook, GraphQL is the de-facto standard with multiple libraries that offer great support. Any innovation that is done in the space of data fetching and data management with React will first and foremost be implemented using GraphQL.
This split of direction, with React focused on GraphQL and Drupal focused on JSON:API, means that any advancements made by the React-GraphQL community will have to be remade, in large part, by the Drupal community.
One of Drupal's goals has always been to allow sitebuilders to do as much as possible without writing any code. This could be considered a precursor to the no-code movement that is rapidly gaining in popularity. Through extensions such as the Field UI and Views, a lot of the flexibility of Drupal can be wielded by non-programmers. These systems benefit greatly from Drupal's tight coupling between front-end and back-end. This coupling is what allows each element to describe how it will need to be displayed once configured.
Although it is a tremendous strength for Drupal, this flexibility that is offered to sitebuilders also poses a barrier for moving to a decoupled set-up. Decoupling means moving to a system where Drupal only serves as a data layer that exposes an API. This change then only covers one part of the tools that sitebuilders require. To fully embrace React and say goodbye to Twig, a lot of work will have to be done to make React just as flexible as the current Twig set-up is.
To support a system where Drupal and React can still offer its full potential to sitebuilders a lot of work will need to be done. This need increases the time that Drupal will require in fully embracing a decoupled-first set-up.
The landscape of the Web is ever-evolving. This newest change poses a lot of opportunities to create even more engaging user experiences. However, it also poses challenges for incumbent users of Drupal and its ecosystem. Businesses will have to figure out how they will deal with the shift in required skills. Drupal will need to evaluate whether it is worth embracing a technology that is different from what a majority of other React users are using. Finally, we'll have to work hard to ensure that we don't leave behind an important target audience for Drupal as a Content Management Framework.
What do you think of the move to React? What are the biggest challenges that you face? Discuss this article with me on Twitter.