Subscribe to a Premium Development Newsletter by TheDevCouple! What is TheDevTakeaway?

The news about Facebook dropping the patent clause and re-licensing of React under the MIT license brought some sort of relief to the WordPress community. But the much-heated debate isn’t over yet. People are discussing round the clock about the JavaScript Framework Gutenberg is going to adopt. I’d say we’re sticking with React.js from an engineering point of view. Too much effort will go waste if we move away now.

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.

We Interviewed the React.js Team at Facebook About WordPress & Gutenberg! 1 Community

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:

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.

Every two weeks, we update the version of React used on Facebook.com to the top commit on the master branch on GitHub. This runs about 60 thousand JavaScript product unit tests, many of which rely on React. They help expose trickier conditions that occur in the real apps. We also perform manual testing of several large-scale React apps (such as advertising products with deeply nested forms and data tables), and run Selenium integration tests in different browsers.

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.

Start-up time is another important problem, especially for sites with lots of static content, as is often the case with WordPress. We want to build sites with rich interactivity and engaging features, but we also want to avoid clogging the main thread with loads of JavaScript work. Techniques like code-splitting already work with React today, but we think we can do even better. In the future, we’ll be introducing an asynchronous rendering mode to React. The idea is to increase responsiveness by cooperatively scheduling rendering work over multiple frames.

⚡️ 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.

React requires some knowledge of JavaScript. This is in contrast to template-oriented libraries that build a custom syntax around HTML. The advantage of using JavaScript is that once you learn its constructs, you can apply them everywhere. But the downside is that it’s harder for folks who have only been exposed to HTML and CSS in the past.

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.

▶︎ Andrew: In contrast to other JavaScript frameworks, React doesn’t provide first-class solutions for things like routing, animation, or data management. Our philosophy has been to keep React itself small and focused, providing the core primitives on top of which our users can solve higher-level problems.

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/hello-world.html. Then, you can take your time to slowly learn the ecosystem, perhaps through the choices of a toolkit like Create React App. React has been a continuous learning experience for me since then, but that didn’t stop me from using React in almost all my hackathon projects!

⚡️ 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.

Now, historically, popularity in the JavaScript ecosystem can be fleeting. There’s always the risk that, despite React’s current position, it could be supplanted by some hot new framework within the next few years. I don’t expect that to happen anytime soon; I’m enthusiastic about the direction of the project and our ability to keep innovating. But if that’s something that concerns you, keep in mind that React is a crucial part of Facebook’s infrastructure, across pretty much every platform. (Including VR!) Regardless of which way the tides shift, we’re here to stay for the foreseeable future.

When considering which framework can most positively impact your career, you should also take into account the skills and knowledge you gain while using it. What’s great about learning React is all the other stuff you pick up along the way, like immutability, declarative programming, data flow, and JavaScript in general. If some mind-blowing new framework that obsoletes React is unveiled tomorrow, the experience you have building apps with React will transfer to whatever comes next.

▶︎ 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.

⚡️ Q #9: Can A WordPress Developer With A Strong Background in PHP Code Learn JavaScript and Go on to Apply for Huge Companies Like Netflix, Facebook, etc.?

▶︎ Andrew: Absolutely. In fact, I made that exact transition. I got my start building WordPress sites at an agency when I was in college, about four years ago. I knew a fair amount of HTML and CSS, but had minimal experience with PHP or JavaScript, aside from snippets I was able to cobble together from tutorials. Even though I was the only developer at the company and had no idea what I was doing, hacking on WordPress sites provided a great education for me.

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.

Web Components are often hailed as the solution to interop, but in practice, we’ve had an interop solution for all these years: it is called plain JavaScript. On top of that, you can always add something else, including Web Components. Since you can create DOM elements from plain JavaScript, I would consider it to be lower level, and thus more powerful.

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?

Meet Ameer Dagha the man behind ReviewsPK Rank Math Plugin For Your SEO Needs WP Engine Smart Plugin Manager – One Plugin For All Your Plugin Updates
  • Excellent interview to pick the brains of the folks involved with React to share their thought. Thanks Ahmad and Maedah for doing this.

    I am inspired by Andrew’s transition from WordPress/PHP to JavaScript/React to working at Facebook.

  • 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.

🙌 You must have something to say here...