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.
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
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.
Adopting React will be great for Drupal developers and the community
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.