Inside the React Core team

6 min read


By Rachel Nabors


December 24, 2020

Drawing of a plant with its roots, illustrating that a flower of success has tons of roots of failure

When I first came to work on the React team at Facebook, I wasn’t sure what to expect. From the outside, the React Core team seemed huge! But it turned out that folks like Eli White and Sebastian McKenzie were on React Native. And most of the famous trainers whose names spring to mind when you think of React have never been anywhere near Facebook or the Core Team. Throw in the maintainers of all of the open source libraries that enable the React community like Chakra UI and Framer Motion, and suddenly “React Core” looks like it could fill a stadium! But the reality is quite the opposite.

The React Core team is small—Sebastian Markbage, Luna Ruan, Dan Abramov, Andrew Clark, Brian Vaughn, Rick Hanlon, Seth Webster, Christine Abernathy, and myself. While Dan is the person who springs to most folks’ minds when they think of React, Sebastian is one of the last remaining “founding” team members. Though Sebastian didn’t invent React, he remains the team’s compass pointing the way forward—meticulously considering how each feature fits into the greater React story. Dan and Andrew built Redux together. Brian builds React DevTools. Rick is an advanced maths evangelist. Luna works on our data story with Relay—and is the only person on the team who majored in computer science! Christine has worked with universities to bring React Native education to the underrepresented. Seth supports us as the team’s manager. And, I work on our docs and educational materials.

But if you get to know the team, you might be surprised to learn that Andrew slays at karaoke, Seth used to be a performing musician and Brian actively records music (bonus points—his cat is also the unofficial team mascot), Rick is an active participant in social justice campaigns, Dan can dance the night away, Christine has seen every film in the Marvel Cinematic Universe, Luna shares my love of good puerh tea, and Sebastian has spent lockdown learning carpentry!

Internally at Facebook, React is a part of an ecosystem of many amazing projects that constantly influence each other, some open source, some not. Facebook’s engineering culture is like a solutions reactor. React itself was one of several libraries created internally to solve the same UI challenges. React stood out from the pack and soon burst into opensource! Now, even though React inspires other UI frameworks, libraries, and solutions at the company, the React Core team functions like an independent, lean R&D lab. While a it’s not quite the same as working with a standards body, working with React Core reminds me of working with the W3C. It is almost like a working group dedicated to making it easier for developers to write consistent, responsive, reusable UI.

When standards bodies think about introducing new specifications to the browser space, specification authors work cautiously before finalizing the API. Every API is a huge commitment for multiple browser developers to support—possibly in perpetuity. Similarly, the engineers on React Core impact many codebases with their work and must be cautious. Feature development starts with deep discussion and healthy debate. Once fleshed out, ideas get tested across Facebook’s “living lab” of a codebase. This way, every feature that makes it into an RFC (Request for Comments) has been road tested before it ever reaches the community, weeding out dead ends and bad ideas into a React junkyard few ever see. Of course, while a new spec could “break the Internet” (see also the ill-fated XHTML 2), upgrading to new React versions is entirely voluntary for maintainers. The emphasis is on ease of migration and compatibility with existing libraries.

Even though an idea may “fail” behind the scenes, it can still bear fruit in the long run. In 2015, the team tried moving React into a Worker to boost performance. It didn’t work out—passing the data back and forth had more overhead than anticipated. Although the experiment ultimately failed, it inspired something more. If components could be divided into ones that execute on the main thread and the ones that execute in a Worker, why couldn’t they split execution between the server and the browser, too? Five years later, this idea formed the basis of the Server Components proposal that the React team has announced a few days ago.

Similarly, in 2018, the React team was collaborating with the Prepack team. The hope was to automatically optimize React components by removing any calculations that can happen at the build time. This collaboration took months of effort from both teams! In the end, the tradeoff wasn’t right, and the experiment has “failed”. However, the learnings from that experiment have informed the design of Hooks later that year. It also showed that compilation alone is not enough to optimize performance. Much of the code you’d want to optimize depends on dynamic conditions that a compiler can’t possibly know — but the server can! This was another insight leading to Server Components two years later.

That’s something people don’t realize when they see Dan on stage or read Luna’s release notes about the new JSX transform: for every polished feature like Hooks that makes it into a release, there are so many that don’t even reach the RFC stage. Things are held back until they’re ready. Others are left on the cutting room floor after ruthless prioritization. Some don’t emerge until everything else has been removed.

In an industry that places so much emphasis on shipping, and shipping at ever increasing velocity, it can feel demoralizing when you can’t deliver the things you promised to yourself, to others. But a lack of motion doesn’t mean a lack of progress. There’s a time for thinking and for planning; a time for experimenting and learning. Even dead ends are worth ruling out, and attempts that aren't successful aren't failures. They are signposts, pointing to the solution.

Even if you haven’t accomplished the things you expected to at the start of this year, trust that setbacks and disruption are the norm rather than the exception, good times or bad, even on React. The React Core team places importance on doing the right thing in the right way. And sometimes, that means being patient with each other when pushing through a dip, be it emotional or technical. It means asking for assistance and second opinions rather than trying to do everything alone. It means having faith that just because you aren’t shipping, doing, releasing doesn’t mean you aren’t providing value.