The Drupal community has historically been a bit less than bullish when it comes to the relatively recent growth spurt of the Javascript ecosystem. Most of the Javascript libraries that have made it into Drupal Core have been rather conservative choices that were widely adopted and extremely mature – think jQuery, and, more recently, Underscore.js and Backbone.js.
Since Dries started Drupal, Javascript has grown from a weaker have-to-use-it punchline of a language that was the butt of many computer jokes into a want-to-use-it, red-hot powerhouse that moves quickly and empowers web developers everywhere. Where it was once cumbersome to build a simple cross-browser compatible dropdown menu, we can now build lightning-fast, robust applications that scale using one language on both the client and server. That's a pretty powerful value proposition, and it's one to which large companies have responded very positively.
Drupal community leadership has not been blind to this growth spurt by any means. In fact, the Javascript gold rush was part of the inspiration for Drupal 8's API-first approach. More and more businesses are looking to how decoupled applications can make their organizations' IT needs more agile, cost effective and fault tolerant.
Content juggernauts such as NPR have revamped their content strategies to create an API that exposes all of their data, allowing mobile, web and other applications consuming this data to grab only what they need to show their end user. A smartwatch app connected directly to a cellular network, for example, might only want to request the latest headlines, each with a link to the full story and maybe a small thumbnail image – a significantly smaller payload than the text, high-resolution images and videos that would appear on a full web page or a native tablet app. Each end user application requests only as much as it needs.
Drupal's API-first approach positions it at the forefront of content management systems capable of anchoring such enterprise content strategies, and this was a very deliberate move by our community. A company can confidently invest in Drupal as its back end, and use it to serve data to any existing applications – as well as those to come – and front-end developers can choose to use whatever client-side Javascript packages they'd like.
Now that we're set up as the proverbial anchor, it's time to focus on the front-end experience of vanilla Drupal.
Waiting to see who wins
With red-hot industry trends, come trendy (and sometimes fleeting) projects. It can be difficult to tell who will 'win.' But with companies such as Facebook and Google investing heavily in their own Javascript projects (React and Angular, respectively), it's easier for enterprise clients to warm up to some of these newer frameworks and libraries, despite their relative youth.
Having set itself as a comfortable choice for an app's back end, it's time for Drupal to adopt a major front-end Javascript framework. Now, we're beginning to put our money where our mouth is. While React hasn't necessarily won the race to be the Javascript UI framework to rule them all, it's the frontrunner for Drupal for a few reasons.
React is modular
React apps consist of many React components, often nested within one another. This can make a React app easier to maintain, and the stories assigned to developers easier to write and comprehend.
This also means that it can be added to an existing application UI in an incremental way. The current Drupal-React discussion hinges on the idea of gradually swapping out administrative UI with React components, starting with the Watchdog page.
It's also not uncommon that performing an administrative task means many form submissions to get where you want to be. Componentization of such an admin interface can mean a snappier, more enjoyable experience for your Drupal admin users. And because it's modular, you can make these changes at your own pace without worrying about breaking the parts of the experience that already work.
React is unopinionated
React components don't care whether the data they interact with come from a third-party service, a Drupal backend or a rusty sewage pipe. All that matters is that the info gets there.
Part of what makes this so great, particularly for big enterprise, is that you're not locked into a back end. If a day comes when Drupal is no longer the answer for your back end, you could potentially drop in a new one with minimal edits to your React components, depending on how you built it.
This unopinionated nature also means the same Drupal-backed React app can pull data from other sources. For example, if you're building a company-wide intranet and want to build a welcome screen that exposes lots of browsable content from Drupal, alongside a weather widget that gets its info from openweathermap.org's APIs, you could do that with React — and in a modular way that'd allow such a weather component to be dropped into any other React app.
Contributed modules and themes can easily use React
With a known version of React in Core, modules and themes can confidently enhance their UIs with React without having to do a whole lot more than list it as a dependency and start coding.
The ability to bank on a specific version of React makes this a whole lot easier than trying to supply your own, and reduces the worry of running into conflicts or React APIs — and features that have changed with time.
Drupal's back end will likely evolve in the presence of React
As the Core team works with React, shortcomings and shoddy developer experiences will expose themselves, potentially leading to new back-end features and interfaces that support robust client-side experiences.
Whether that happens and what it'll look like is anyone's guess, but perhaps we end up finding a place for opinionated state management within Drupal via Redux, or GraphQL in Core, allowing front-end converts to easily begin working with Drupal powered React via a GraphQL schema. Maybe we end up with a simple pubsub system that makes it easy to expose data for React apps and other Javascript frameworks in the spirit of Meteor.js.
Adopting React will be great for Drupal developers and the community
At the bottom line, React will make a great addition to Drupal Core because of its benefit to the community. Dries will be the first to admit Javascript hasn't been Drupal's strong suit over the years, and he's expressed he wants that to continue to change.
With React in Core, and as it continues to permeate the ecosystem, we can reasonably expect many Drupal developers to become comfortable using React, and React developers to end up arriving at Drupal as a back end for their apps, as well as diving into the deeper aspects of Drupal development.
I see this leading to a broad cross-pollination of sorts. Drupal developers who are newly empowered with React experience are more marketable to React-focused software shops and large enterprises who may have yet to form a strong opinion on a go-to back end. Insert Drupal.
React developers may run into a situation where a client insists on the tried-and-true LAMP stack as a backend. It's inevitable that Drupal's adoption of React would bring lots of online tutorials, examples, articles and probably a Drupal distribution or two. This would raise the Drupal's exposure as a back end for React apps, as well as lower the barrier to entry for a Javascript-focused React developer looking to solve a very real problem.
Drupal is already positioned as a great choice for a back end capable of supporting multiple Javascript apps. But the adoption of React in Core will take it to the next level, spurring more supporting content across the web, increased mindshare and adoption of both Drupal and React — and, more powerful and enjoyable developer and end-user experiences.