WordPress community has been quite vocal, and people have posted some strong recommendations and opinions regarding this issue. I started a conversation on GitHub which (sadly) apart from a few comments have had been a very healthy discussion.
Knowing that React is a very strong contender for Gutenberg I decided to get the other side of the story as well. i.e., how does the React team feels about it things that we (WordPress Community) care about?
I had an incredible chat with the React team — Dan Abramov, Andrew Clark, and Sophie Alpert. They were keen enough to share thoughts about React.js and WordPress.
Have at it.
⚡️ Q #1: Who Is on the React Team?
Currently, the React team that works full-time at Facebook consists of:
- Andrew Clark (co-author of Redux and Recompose)
- Brian Vaughn (author of React Virtualized)
- Dan Abramov (co-author of Redux)
- Dominic Gannaway (author of Inferno)
- Flarnie Marchan (maintainer of Draft)
- Sebastian Markbåge (member of TC39)
- Clement Hoang (intern from the University of Waterloo)
- Sophie Alpert (first open source contributor to React, and now our manager 🙂
We are also lucky to have a few external contributors on the core team who have helped us a lot:
We are very grateful to them and are looking forward to onboarding more external contributors in the future.
⚡️ Q #2: How Do You Choose What Features to Work On?
▶︎ Sophie: Our goal is to make it easier for people to build great apps. That can come from a lot of places—whether that’s making better tools for debugging, improving performance, or adding features that save time during development. We try to listen to what people are asking for both at Facebook and in the community. We also try to find new ways to help people develop apps even if that means bringing more capabilities into React for things that we’re not currently responsible for.
▶︎ Dan: As people build larger apps with React, they often raise the same problems with us, so we usually have a good idea of the pain points we need to solve in the next releases. We don’t have a multiyear roadmap because we try to stay sensitive to both new challenges and opportunities. However, as we get closer to planning a specific release, we always share our checklists with the community to get feedback on them and provide a sense of progression.
▶︎ Andrew: One of the nice benefits of working at Facebook is that we have access to all sorts of interesting, difficult problems. It eliminates much of the guesswork from figuring out how React can be improved. If we can make React work for the teams at Facebook, chances are it’s going to help solve problems for the wider community, too.
⚡️ Q #3: How Is React Being Tested?
▶︎ Dan: Despite a small API surface, we have more than two thousand unit tests, and we are constantly adding more. These tests help us catch regressions before we merge changes on GitHub. We consider master to be relatively stable, and even though the APIs on master might change before a release, we do our best only to land the changes that are well-tested.
Some problems are impossible to detect from unit or integration tests, even if we ran them in the browser. To address this, we have built a DOM fixture suite with dozens of manual tests for browser quirks. The code that directly interacts with the DOM in React is scoped to a few modules, so whenever we change them, we run through the fixtures in different browsers and verify that we did not break anything.
Finally, we have a sophisticated continuous deployment system that catches regressions early. We heavily use Facebook products for work communication, and all changes are rolled out to employees first. If we introduced a bug, we get reports and can investigate the problem before the changes are deployed to our users. There are also automated systems that monitor the number of crashes or drops in metrics, and correlate that back to the commits.
▶︎ Sophie: In practice, in the rare event that regressions ship to production, we find a matter of hours or days, at which point we’ll fix them and add a test to help make sure we won’t regress again. At Facebook’s scale, even an uncommon bug can occur for millions of people, so this testing gives us confidence in the open source releases of React.
⚡️ Q #4: How Does React Approach Breaking Changes?
▶︎ Dan: We do major releases roughly once a year, and they usually include some breaking changes. However, we always provide a straightforward migration path. At Facebook, we have more than 30 thousand components, so we can’t afford to do large API-incompatible changes. Outside of Facebook, React is trusted by companies like Twitter, Airbnb, Pinterest, and hundreds of thousands of other developers. We take this responsibility very seriously and often collaborate with them to ensure smooth upgrades.
If the change is mechanical (like renaming a method), we release codemod scripts that you can run to convert your whole codebase in a few seconds. If the change is more complex, we typically introduce new behavior side by side with the old behavior and warn for a single major release cycle before changing it. This gives our users about a year to opt in and upgrade their code to the new patterns. If a change is non-trivial, we can keep a warning for more than a single release so that we don’t leave anyone behind.
The recent React 16 release is a good demonstration of this approach. It features a completely rewritten core to unlock powerful new features, but it is almost entirely API-compatible. Instead of working on a new version in a vacuum, we ran the new engine side-by-side with the old one on our existing products and fixed all the issues we could find. In case you’re interested in how we did it, our manager Sophie wrote a post on the Facebook engineering blog about this.
When a major React update is out, there is some churn in the ecosystem. The libraries affected by the changes might also need to be updated. I think this is unavoidable if we want to keep innovating. But in my experience, most popular libraries get updated within a week or two of the new release, and the longer trail of small packages takes about a month.
The library churn is less of a problem at Facebook because we don’t rely on open source components as much, and so we run the migration scripts in a single pass. I’m curious whether this would also be true for WordPress. If WordPress provides some base components to be used by plugins, they could all be updated at the same time. But I don’t know WordPress well enough to tell.
▶︎ Andrew: Here’s my favorite way to illustrate our commitment to stability: when we make a change to React that necessitates changes to the thousands of React components in production at Facebook, it’s not the product developer’s responsibility to fix it. It’s ours. And our team is less than ten people, for more than 30,000 components that must not break. So we don’t change things on a whim; we know exactly how easy or difficult a migration will be, and do our best to minimize the pain involved for ourselves and our users.
A big reason we’re able to do this is that the React API is pretty small. Relative to other projects, there just aren’t that many things in danger of breaking. That’s by design: we’re very intentional about adding new APIs. If you look back at the earliest versions of React and compare them to today, we’ve added some features, renamed a few methods, and swapped out certain APIs for better alternatives. But fundamentally, the way you write React components is the same.
⚡️ Q #5: In What Ways Is React Suited for A Project Like WordPress?
▶︎ Andrew: React was designed to fit into the web infrastructure used by Facebook: a mix of server-rendered static content and client-rendered dynamic interfaces. It’s not so dissimilar from how WordPress sites are built. Our servers even run PHP!
▶︎ Dan: Facebook has all kinds of React apps. Some are single-page apps built completely with React; others are small components embedded inside larger server-rendered apps. Some are built for the web, and others are built with React Native. Some are pretty simple, and others include complex navigation, data tables, and highly interactive forms. This gives us a first-hand experience of how different apps live together on one page and work together.
The problem of different apps coexisting on the same page is not trivial. I’m sure you can relate to it after working for so long with WordPress plugins. Code becomes fragile if two plugins can hook into the same mechanisms and conflict with each other. This is why having a strong component model so is important to us. Different parts of Facebook pages are maintained by completely separate teams, so we need to make sure they can make changes without breaking each other’s code. In our experience, the React component model already provides that isolation, but we have not yet exhausted its possibilities.
For example, before React 16, an error in one React component could break the whole page. This is still the case with many UI libraries. But this is unsustainable because as your app gets larger, someone is going to make a mistake. It is also unfair that an uncaught error in one product can break a different product maintained by a different team. This is why we built error boundaries React 16 to let you catch crashes in your components, and display a fallback UI without taking down the entire page.
▶︎ Andrew: In WordPress, I imagine each plugin could surround its views in an error boundary. That way, if one plugin breaks, the rest of the page isn’t affected. Instead, you can display a graceful error message, or perhaps nothing at all.
⚡️ Q #6: What Are Some Downsides of React?
▶︎ Dan: I think React is mostly useful for rich, dynamic applications, and makes less sense for something like a landing page.
We find that React performs well for most apps, but there are some cases where templates perform better: for example, stock trading apps where hundreds of cells update every few milliseconds. In these cases, something like Angular with ahead-of-time compilation is faster. Facebook products are mostly focused either on social interactions or managing advertisements, and we find that virtualization when necessary solves our performance issues well.
Thanks to React’s popularity, there is a lot of content about React, but this also means not all of it is good. Sometimes it can be hard to find good articles or examples in the sea of noise. I’m sure this problem is familiar to WordPress users as well. Generally, we advise that people start looking for answers in our documentation first, but it can be hard to convince people to do this, and it is not perfect either.
So far, this strategy has been pretty successful. The React open-source community is incredibly active and churns out innovations at a remarkable pace. The downside is that for developers new to React, sorting through all the various open source libraries can be overwhelming. On the whole, I think the trade-off is worth it, but I wouldn’t blame anyone for disagreeing.
▶︎ Dan: While this approach produces some churn if you switch to every new library, it has longer-term benefits for everyone. For example, the Flux architecture used by Facebook wasn’t a part of React, so it inspired a wave of innovation in the ecosystem, including Redux. I believe these ideas have already influenced other communities like Angular and Vue, and they also inform the future direction of React itself now. This might not have happened if React forced people to adopt a certain solution and discouraged experimentation.
⚡️ Q #7: Is React Hard to Get Started With?
▶︎ Dan: React has certainly acquired the reputation of being difficult to set up, but in my experience of talking to people, it is not React but the build tool configuration that is intimidating. I certainly empathize with that. Nobody wants to spend a day configuring a build tool before they can start a project.
I think, however, that there are clear solutions to this problem. Nobody experiences it at Facebook because the build tooling is preconfigured and “just works.” And we can do the same in open source.
For example, I have been trying to replicate the same zero-configuration experience in a tool called Create React App, and 96% of more than 5,000 people we surveyed said they would recommend it to someone getting started with React.
If WordPress were to adopt React, it would make sense for it to also provide a zero-configuration build environment. We are happy to offer some of the packages we developed as part of Create React App for reuse: for example, our interactive build error overlay with editor integrations.
▶︎ Clement: Adding to what Dan said, React has a huge ecosystem of plugins, libraries, and whatnot. Although this can be very intimidating at first, it’s also powerful and awesome to have so much pre-existing work done, so you don’t need to re-invent the wheel. When I first started learning React last year, I found it very useful to focus on the basics—this means ignoring libraries such as GraphQL, Relay, Immutable.js, etc. to begin with and just learning pure React from https://reactjs.org/docs/
⚡️ Q #8: What Does the Job Market for React Developers Look Like Compared to Other Frameworks?
▶︎ Andrew: Most of the data I’ve seen suggests that the job market for React developers is strong and getting stronger. StackOverflow reported earlier this year that hiring demand for React is the fastest growing of any technology or developer type. It’s being used by companies such as Microsoft, Apple, Netflix, Airbnb, Pinterest, Yelp, Twitter, and thousands of smaller ones. And Facebook, of course.
▶︎ Clement: As an intern from the University of Waterloo, I can tell you that the demand for React developers is pretty big—three of my internships in the last two years involved some React work, in addition to a contract position that I had during the school year to developer a React application. Like Andrew said above, the skills that you pick up along the way learning React won’t be wasted. I’m confident that if React is obsolete tomorrow, I’ll be able to transfer my skills over.
After about a year of this, I tried out React for the first time. The app I built was nothing fancy; it occupied a small part of one page of a larger website. But it was easily the most fun I’d had in my career up to that point. I started looking for excuses to sneak React into all my projects. One of my last projects was a single-page React application with a WordPress backend via WP-API (which was pretty new at the time).
A bit later, I got involved in open source, which eventually landed me a job as a front-end engineer at a start-up building React apps. Then, about a year after that, I joined Facebook. So, yes, it can happen, and anecdotally, I don’t think it’s that uncommon either. I can’t speak for every company out there, but at Facebook, we have engineers from a wide variety of backgrounds. You don’t need a fancy degree or many years of experience. In fact, only one person on the React team has a degree in Computer Science.
⚡️ Q #10: Do You Think WordPress Should Use React?
Dan: I don’t have enough insight into the problems WordPress is solving on the client side, and how its community feels about different libraries. But I have a hunch that a strong component model is going to be important. Thankfully, most modern libraries agree on this.
I’ve heard an argument that WordPress should not pick any library, and instead offer an interop layer so that people can choose for themselves. This makes some sense to me, but it does seem to go against the “Decisions, not Options” principle in the WordPress philosophy document. This position also fails to acknowledge the fact that interop is a long solved problem. For example, if WordPress adopts Vue, it won’t stop people from writing React components for it, and vice versa.
If WordPress doesn’t pick a primary library, I think providing low-level JS hooks would be the best choice for everyone. People who like React can use React, people who want Vue can use Vue, and people who prefer Web Components can use them too! But then again, let’s not forget that interop is entirely possible even if WordPress follows its philosophy and makes an opinionated decision, whatever it may be.
Overall, as people build larger apps with other libraries, I think it is likely they will bump into the same problems that we are trying to solve. So whether WordPress chooses to React or not, I hope that we will continue this exchange of ideas, and learn from each other’s experiences.
🔥Thank You, everyone, for taking part in this whole thing! If there’s anything, you’d like to ask these awesome people, post in the comments section below.
SUBSCRIBE TO DEVELOPERS TAKEAWAY!
A Premium Development Newsletter by TheDevCouple! What is TheDevTakeaway?
Excellent interview to pick the brains of the folks involved with React to share their thought. Thanks Ahmad and Maedah for doing this.
Awesome interview, & glad to here from the folks behind React.
Awesome Ahmad! Thank you so much for this great interview. I started learning react a few weeks ago and I was smiling for what Andrew said ‘I started looking for excuses to sneak React into all my projects’ its me now at my current job 😀
Exactly what I have been doing lately. BTW Glad you liked it! 💯
Great insight into the minds of the people at React, I hope to start picking up and learning more React especially if WordPress does decide to go with it. Have they already or not?
Glad you liked it. 💯
Yes, WordPress Gutenberg core is using React. Best tuts out there for learning React is a course by my friend Wes Bos called → React For Beginners. Go learn some React.