Sophie Alpert

React Podcast: Inside React

May 29, 2018

I recently had the opportunity to appear on the React Podcast and be interviewed by Michael Jackson and Michael Chan about my work on React.

Listen here.

Transcript follows:


Introduction

MJ: This episode of the React Podcast is brought to you by React Training: in-person hands-on training for development teams from React community leaders and experts – visit reacttraining.com to learn more.

MJ: Hello everybody, and welcome back to another exciting episode of the React Podcast. I am your host Michael Jackson, here with my co-host Michael Chan.
MC: Hello everyone!
MJ: …and we have a very special guest with us this week. Sophie Alpert, who is the engineering manager for React at Facebook.
SA: Hi, it’s great to be here.

MJ: Thank you so much for joining us on the show this week. Sophie, are you at work right now?
SA: Yeah, I am. I’m in a conference room, with a name from a Seinfeld reference I think, although I don’t follow Seinfeld so I don’t get any of them. But you know, we name our conference rooms fun things, and I guess people thought this was fun.
MJ: Are you in the new building?
SA: Um, we have a lot of buildings. Right now I work in what we call building 23, which I guess is the 23rd building by some count, although we don’t have any buildings less than 10. I’m moving in a couple of weeks to a newer new building that’s about to open.
MJ: Now, does the whole React team sit together in building 23 right now?
SA: Yeah. Well the folks of us who are in the U.S. do. We also have two in London and they sit in London.

MJ: That’s right. So how many people now on the React team these days?
SA: The React Core team is what we call my team. That’s me plus six other people so four here in California and two in London. We’re responsible for what you think of as React and React DOM, so that’s basically the entire web version of React as well as the parts of React that are shared between web and native.
SA: We do have a separate React Native team that I’m not counting and also a team that works on Relay and some of our other related projects.
MJ: And that’s your full-time job. Is that right? To work on React and bring us all joy and happiness.
SA: Yeah, the seven of us, we just work on making your life better.
MJ: That’s awesome.

Starting with React

MJ: You know, I saw on your website, sophiebits.com – by the way, Sophie is @sophiebits pretty much anywhere you go, on Twitter and GitHub, and she also has this website. She says, “I’m a software engineer. I build things to help people.” and I thought that was pretty cool way to describe what you do. You haven’t always been at Facebook, Sophie – you used to be at Khan Academy. And in fact, that’s when I first met you. When I first got into React, you were already there, and you’d been there for a long time. Can you tell us a little bit about when you first started working with React and when you first discovered it?
SA: At the time, I was working at Khan Academy; it’s an educational nonprofit, if you’re not familiar. And I was working on this interactive math question editor where you can build your own math questions. I was building in Backbone with a bunch of Backbone views and struggling a little bit because it was a pretty complex project and I couldn’t make everything fit together all the time.
SA: But then, React came out. I remember I saw it on Hacker News. I believe this was in the end of May 2013, almost five years ago – we’re a couple of weeks short of React’s five-year birthday, in open source at least. I looked at React and it just seemed like an absolutely perfect fit for the project that I was working on, so I went home that weekend and rewrote all of my code in React and it ended up being faster, less code, and easier to understand. So I looked at it and was like, well, maybe there’s something here.
SA: And uh, I ended up deploying that to production about a week later. Something like 10 days after React was open sourced, I had it running in production, which in hindsight is a bit ludicrous and maybe not the best decision, but it worked out great.

MJ: I’m going to use another word for that. How about: awesome.
MC: That is pretty amazing.
SA: I mean, at the time I was super excited by React because it seemed so great. I read all the docs in one night. There weren’t very many talks at the time, and I was like, I still don’t really get what’s happening, and then I read all the source code, which there was also a lot less of at the time. I was like, you know, I think there’s there’s something here, and I really just jumped on it. But in retrospect I’m like, did I really deploy that to production less than two weeks after it was released? – and the answer is yes.

Building React

MC: As someone who’s now managing that project, do you go back to those memories of your early experiences making Khan Academy in making decisions for the product that is React and React DOM?
SA: Absolutely. One of the most important things when doing the job that I do is to think about the experience that people actually using React and building these products are going to have. Basically, on the React team our goal is to make it easier to build high quality user interfaces, and it’s a lot easier to do that if you know what building user interfaces is like. So, for that reason basically everybody we have working on React has built products before, because it’s really helpful to have that experience. We’re always trying to look at finding ways to make it easier and take things that might be challenging today and make them a lot simpler.
SA: That can come down in a lot of ways. It can be making React run faster so that your apps are more performant, or it can be building better debugging tools so that when your apps fall apart, you can figure out why quicker.

MJ: Now, can you describe a little bit about what the dynamic is like on the React team? I know a few people on the React team, and I haven’t met everybody, but I’ve met most of the people. I saw Brian the other night tweeted something about how you all went out to dinner together, and he was said it was great, and then I saw quite a bit of joking going back and forth. It seems like a pretty fun team to work on.
SA: Yeah, I think so. We try to keep it pretty light-hearted, and we all get along pretty well, so you’ll often find us teasing each other a little bit.
MC: I did notice that on Twitter, there’s @acdexplained?
SA: Yeah, that’s a Twitter account. I think it’s not a secret who the creator is, but I won’t give it away just in case it is. Andrew likes to make these somewhat clever jokes sometimes, so another member of our team made @acdexplained to help explain Andrew’s jokes when they’re a little bit too cryptic.
MC: It’s really amazing. I very much enjoyed that addition to the React conversation.

MJ: So you’ve been working on React now at Facebook for about two years?
SA: Um, over three actually.
MC: Wow, it flies.
MJ: Geez. But you were contributing to React even before you went to Facebook. I mean you were using React at Khan Academy, but you were actually contributing real code, which is I think why it made sense, to segue into the position that you’re in now at Facebook.
SA: Yeah. So I told you that in June of 2013, when React was released, I began to use it, and very shortly after that I began to hang out in the chat room they had for people interested in React. I also ended up running into a few bugs in React at the time because it was obviously a much newer project, and I ended up contributing back bug fixes and working on larger and larger things over time. Eventually by the end of 2014, I found that I was spending most of my spare time on React and really figured that it was time to just come work on it full-time.

MC: I have a question with regard to that. If someone was wanting to carve out the same path towards full-time React development that you were able to take, what would you recommend for them? What does that look like three and half years later?
SA: We act as a much more mature project now, so that means that there are a lot fewer easy opportunities to contribute to the project. Versus when I was starting, when there were so many things that needed fixing and so many features that didn’t exist yet, it was pretty easy to just look and see gaps. Whereas now, we have what we think is a pretty cohesive set of features. We also have our own idea of what we’re trying to get to with the project and we’re trying to take it, and that actually does mean that it’s harder to end up contributing to it, especially as somebody who’s not completely steeped in all of our plans and things like that. That said, we love having open source contributors. We file GitHub issues now and then and label them “good first issue”. I think that’s the name of the tag. Those are our issues that can really help us but hopefully don’t require a ton of context about React that most people won’t have; we try to explain it so that somebody who’s interested in the project can get started.

MC: That’s interesting. So how has your experience been transitioning from products at Khan Academy, or a user facing product, to a product that is kind of a platform or a tool for people to build their applications on? Do a lot of those skills transfer over or has it been a totally new set of skills that you’ve had to learn and get good at?
SA: For the most part, the skills overlap a lot. You know, I’m still developing JavaScript on the web in some sense and still need to know a lot of the same things that you would need to know for building any user interface. Certainly the exact balance of how things fit together is a little bit different; we end up doing more algorithmic work and things like that while developing React itself because we want to make sure it’s as optimized as we can make it.
MJ: From what I understand, React itself though is kind of treated as a product within the larger Facebook org, right? Your customers aren’t the end users of facebook.com, but your customers are more like other engineering teams at Facebook itself.
SA: Yeah, that’s absolutely right. When making decisions about what we want to work on, we need to make sure that we’re solving the use cases that these teams have. We need to ideally make it so that they want to use React, because we’re not in any position to force them to use it if they don’t want to. If we think we have something to offer them, then it’s sort of on us to convince them of that.

Competition and camraderie

MJ: Do you get any kind of competition from other teams inside Facebook who are like, “My thing is way cooler than React. You should use my thing instead.” Does that happen?
SA: Remarkably, we haven’t run into that very much on the web. React is powering almost all of our interfaces. We do have some cases where we’re actually using older technologies for various reasons, like a lot of our home page is still server-driven, but I wouldn’t say that we really have any React competitors that are trying to displace React. Most of that competition actually comes from externally.
MJ: The external competition would be other kinds of JavaScript Frameworks, whatever other people are doing, and in that case, I wouldn’t exactly word it as “competition”. It’s more like R&D.
SA: You’re absolutely right. You know, I did say competition, but we try to be very friendly with all of the other frameworks that are trying to solve problems in the same space. We’re trying to solve a lot of the same problems as they are and it’s helpful for us to just have a collaborative atmosphere. I don’t want to fight anybody here. Facebook sponsors a couple other projects that you might consider to be “React competitors” because we really do want to encourage those projects to grow and to innovate, because we can all learn from each other.

MC: This is something that has always been attractive to me about the React community, even from the very beginning. I feel like some frameworks of really try to make the story about competition and “They do this, we do this thing in a better way,” as the story of their framework. I’ve always loved the spirit of React which is, “This is the thing that works for us. It’s a thing that works for Facebook. We enjoy it, we put great engineers behind it, we believe in it. We want to push it forward and hopefully it’s useful to you as well. But other people are doing great work; we’re gonna borrow from that, and hopefully what we’ve done can be adopted into those frameworks as well.” And I guess this is more just a statement, but I’ve always appreciated and enjoyed the spirit that you’re talking about. Friendly, maybe slightly competitive, with a spirit of hey, we’re all in this together, just trying to move things forward and learn from each other. So congratulations on doing that.
SA: Well, thank you. One thing I like to look at for inspiration is back a decade or more ago. You would have the Netscape and IE teams, I believe, sending each other cakes when they had major version releases. It might have been Firefox and IE. Even though those browsers were so often pitted against each other, under all of that there was this camaraderie.
MJ: I remember that, I remember seeing some pictures of cakes. I think I saw a Firefox cake one time. I’m pretty sure we could pull up some pictures of that online without too much trouble.

Development process

MJ: Help me understand: what is it like for a day in the life of a core React engineer at Facebook? It’s my understanding that a lot of products at Facebook obviously are built in React and that when React itself changes, that the React engineers are responsible for actually going and not only making sure that the product teams know about those changes, but actually making commits on other products to help them keep their code up-to-date with those changes. Is that right? I think this is why there are a lot of the codemods and things like what Christoph does. Is that right?
SA: At Facebook we have over 50,000 React components in our codebase. We also use a single version of React across all of them. It’s a monorepo, a single stack for all of our websites. This means that it’s a lot easier to make sweeping changes to the code base because you can update all of it in a single command. However, it also means that in order for us to upgrade React, we need to make sure that nobody is relying on something that doesn’t work in the new version. So yeah, it’s basically on us to make sure that when we make breaking changes to React we’re not breaking anybody’s code because if we did then that’s on us, if people can’t interact with their friends on Facebook, that’s not what we want to make happen. Our team basically is responsible for figuring out how to bring everybody along on this journey when we make breaking changes.
SA: This is actually something that a lot of people don’t realize about our team, but we spend a huge amount of time working on these migration strategies to figure out how we can do these breaking changes gradually, how we can get people to move on to the newest APIs. In a lot of cases, we can do it in some sort of automated way if we can write a script to rewrite people’s components. The most sophisticated example of that was when we converted from React.createClass to ES6 classes, and we open sourced that script a couple years ago. That’s the sort of thing that really helps us not get left behind, and it’s also good practice for us because if our team of seven people is responsible for upgrading these 50,000 components to work with the newest version of React then it probably means that any other company is also going to be able to upgrade to the latest version as well.

MC: In your experience with that, what have been some of the most winning strategies or lessons that you learned to the hard way that are now part of every pre-release checklist?
SA: The biggest thing we’ve done actually is automating as much as we can, because it makes it so much easier to make progress. We must have thousands of automated tests for React that capture as much as we can for all of the core behaviors of React; we add a test whenever there’s any sort of regression to make sure it never happens again. We were actually able to use this test suite when we rewrote all of React last year to make sure that the new version was basically completely compatible with the old version. We also recently worked on an automated release script where we can run the tests, push everything to npm – we have a whole bunch of packages – then tag it, and put it on Bower. There’s quite a number of steps to a release and it actually used to take us a few hours to do a release; now you can do one in like 10 minutes.

Rewriting React

MJ: I’m glad you mentioned the rewrite of React that happened last year. For anybody who’s not familiar with that, the React 16 release was a pretty vast departure internally from what was previously done. In fact you, Sophie, wrote a post on the Facebook Code blog towards the end of last year. You said, “React 16 was an API compatible rewrite of our front-end library”. You described it like replacing the engine of a running car. Here you are, cruising down the road, and somebody hops out the window onto the hood, they pop it open, and they swap out the engine – and the car is still going down. Can you tell us a little bit about that experience? What was that like and why was the rewrite something that you determined to do?
SA: We hit a point where it was getting harder and harder to make changes to React because we had a fair amount of legacy code debt that was from the infrastructure that was built up when React was first written, but we had found over time that the things that we wanted React to do had changed slightly. We found that it was pretty hard to make some changes that you that you might even think would be simple, like one of the features we added in React 16 is fragment support, where you can return more than one component from your render method. This change sounds really simple when you describe it, but it was actually very difficult to make that happen with our old code base because basically everything assumed that every component would turn into a single node. When you say, I want to render this App component, it would be like, “Well, what is the HTML element that that maps to?” and so in order to break some of those fundamental assumptions, we ended up doing a large-scale rewrite of almost all of the internals of React.
MJ: So how does how did a project like that actually sort of come to pass? How do you allocate time for that and determine, “OK, who’s going to do this?” How do you break down something that big? A rewrite of React seems like a huge, huge engineering task. I’m sure you’d had a lot of engineering experience before that, but even to me at this point in my career, it seems just like a huge task. I don’t know. I don’t even know how I would approach something like that. What can you tell us anything about the process?
SA: I wrote quite a bit about it my post that you mentioned on the Facebook Code blog, but basically, I have to give a lot of the credit to Sebastian on our team. The rewrite was really his idea, and he planned out the architecture that we ended up with. Once we had an idea of what we were aiming for, it was basically just trying to build it up piece by piece and then trying to make as many of the tests pass as possible as we were doing that. We started out, and I’m sure it was like 2 out of 700 test files passing or something like that, and then it was just more and more over time. We started with the data structures and then supporting very limited use cases. At first I think it did some semblance of an initial render, but it didn’t support setState or anything like that. We just gradually added all the features back.

MJ: I remember following along actually, watching the tests at isfiberreadyyet.com slowly go green over the course of several months. That was pretty cool. I’ve looked through the React code base – obviously not as much as you have – but I’ve noticed that a lot of the tests are written using the public API, which is totally awesome and allows you to do stuff like that. Right? Because if it’s all written using internal API, then you basically just have to throw all those tests away in a situation like that.

SA: Yeah, and that’s a big thing that we actually learned while doing this rewrite. A fair number of our tests at the time were testing these internal modules where when we had written the test, we said, “Of course we’re going to keep using this module forever” and then it just came to light that that was simply not true. And so we needed to convert a lot of those tests to be based on the public API, but in turn we have been able to do that with rewrite to make sure that both versions of React pass all the same tests. Another thing that we recently did that was enabled by this was running the majority of our tests against the actual built bundles, versus previously, we were requiring a bunch of internal modules directly. Now we are actually able to run like 90% of our tests against the exact bundles that we ship to npm and that we use at Facebook, to make sure that nothing in our packaging process actually even introduces any issues – we have a build process that is more elaborate than I think we’d like it to be, but we need to support a lot of different use cases, and certain files are replaced in certain build configurations and things like that.

Internal infrastructure

MC: I feel like there was an article written about this, maybe on the React blog.
SA: Yeah, that’s true. Dan Abramov wrote a post at the end of last year, I think probably in November–December, called “Improving the Repository Infrastructure”.
It’s on our blog, and he talked about a lot of these improvements we did, including running the tests against the bundles and the automated release script that I mentioned earlier.
MC: I feel like that’s a really helpful resource for people who are just getting into open source and testing in general. It really laid out a lot of the things that you had learned, and it does seem like lessons that a lot of people have to learn on their own. It really is nice to see them all documented in that one spot for a really big project.
MJ: It’s a helpful lesson for me to learn. I’ve got a bug right now on the React Router website that is not present in development, that is only present after the build has run and the thing is shipped to production. I’m listening to this conversation, and maybe I should be doing some sort of end-to-end – here’s the final bundle, OK, now run your tests.
SA: Running tests on the production version of React is also something we learned. We have two versions of React; the development one has more warnings and it does things like PropTypes checking which we actually skip in production, and we were running most of our tests against the development builds because we had to assert that certain warnings fired and things like that. But there were some cases where we would mess up and the dev build would work fine, and the production build would be broken and then our test wouldn’t catch it. So we also ended up rewriting our tests so that we can run them against the production builds. And for the tests that are verifying that a certain warning is logged that we just say we don’t expect that warning to be logged in production. But we expect everything else to be exactly the same.

MJ: You said your build process is a little more complex than you’d like. What are you using for the build at Facebook? I’m sure they are multiple steps and multiple things involved. What does it generally look like?
SA: For React itself, a lot of it is custom. We actually have our own build scripts inside the React repo, and a fair amount of them are custom. We also make use of Rollup as our bundler and Google Closure Compiler to minify the code after it’s bundled together. But we also have we have a lot of custom logic because certain things behave differently in certain environments. There are some files where we want to fork their behavior when running in React Native and things like that, so there’s quite an elaborate process.

Future development

MJ: I would like to spend just a little bit of time talking about the future, talking about stuff that you’re anticipating, stuff that you’re excited about. Obviously we’ve had both Dan and Andrew on the podcast in the last couple of months; we had Dan on literally the week before he went up and gave his talk at JSConf Iceland, then we had Andrew on a couple weeks after that. We’ve talked a little bit about async React. I assume you’re anticipating that, you’re excited about that. How’s that work coming along internally at Facebook?
SA: It’s going really well. With everything we release on React, we want to try to test it ourselves first to make sure that it’s good, because we don’t want to release something, have a lot of people jump on it and be really excited for it, then find out that it doesn’t really work as well as we thought it would work. That’s one of the advantages we have of actually developing something like this at Facebook – we operate at a pretty large scale, and we can make sure that whatever features we have work at that scale. Right now we are running our first production test of these async rendering capabilities, trying to see how they behave in the real world on real components; the results aren’t quite in yet, but hopefully they’ll look good and then hopefully we can get these capabilities out so that other people can use them as well.
SA: However, the version of React that we run at Facebook is always trailing what we have on GitHub. We sync in the master branch from GitHub to our internal repos about once every week or two, so all of these capabilities that we’re testing are actually already on GitHub. They’re just disabled in most of the build configurations because we’re not quite ready to have people use them, but if you’re really adventurous you can go find them there.

MJ: Oh, so you don’t you don’t actually run a specific version of React, you run more like a SHA. If you’re doing it every couple of weeks, I don’t think releases happen that often, do they?
SA: No, they don’t. Whenever we run our sync script to import the latest version of React, it just grabs whatever is on master at that time.
MJ: That’s so awesome. It’s like living, breathing software. You know, it’s not like, “This is software at such-and-such a version”. It’s like, “Whatever’s on master, let’s run that”.
MC: Feels almost like those early days at Khan Academy, just shipping React two weeks after you code it out.

Gender

MJ: There was just one more topic that I wanted to touch on. Thank you, by the way, for sharing everything that you have with us about React. This is a topic that I think is important for a lot of people that are here in this podcast and in this industry to understand and have some understanding for. So Sophie last year, in August of last year, the blog post where you said, “Hi, I’m trans,” and you said, you’d known for a long time that if somebody gave you the choice, that you would choose to be a woman, that this was something that you felt for a long time. And so at a certain point you made the decision, you said, “I’m going to transition”. One of the things that really affected me personally about that post is you talked about how about 50% of people who experience gender dysphoria, which is the clinical term for people who don’t identify with the gender that their body is, attempt suicide and as somebody who struggles with mental illness – I’ve written about it various occasions – that number really shocked me and really broke my heart. So I wanted to give you a chance and just to maybe remind us all a little bit about what we can do as people, as individuals in our communities and as part of the React community, to help and to be more inclusive. What are things that we can do to help people who might feel out of place because they struggle with this?
SA: You cited that 50% number – 50% of people who are trans end up committing suicide or attempting to commit suicide at some point in their lives. The thing that I forgot to mention in that post and probably should have, is that the overwhelming majority of those people are people who don’t get the chance to transition, people who aren’t able to live out who they are, or people who face various aspects of discrimination in the course of doing so. So the biggest thing that I can ask for is just for people to try to be welcoming to people who might not dress the same way that you’re used to or might not present themselves the same way as you’re used to, and understand that the way they choose to present is not really any of your business; it’s their business.
SA: Also, try to just have some empathy for people who are going through a difficult process. I remember actually at React Conf last year, probably in March if I remember right, I was on a panel at the end of the conference. I remember that this was before I transitioned and before I came out publicly, and I remember I was wearing nail polish when I was on that panel, and then when I was looking at the YouTube video of that panel later, I saw a comment that said, I think, “What’s with the nail polish, is this a freak show or something?” – and I deleted that comment and turned off comments, which we had intended to do on all of our videos, so you won’t see it there if you look now, but that comment was pretty demoralizing for me as somebody who was trying to find herself. I clearly made it past that, and I’m still around; I’m actually very happy living as a woman now which I’ve been able to do.

MJ: Thank you so much for taking the time to speak to that question. I know that’s it’s not a React question. It’s more just a people question and it’s being nice and being respectful to people. The more software that I do, the more I learn and understand that it really is just about people. I feel like software sometimes is the medium that we write code, but sharing code, sharing thoughts about code, talking about code, and giving conference talks really is just about connecting people and helping people, so I thank you for taking the time to talk about that here on the podcast.
SA: Thank you, too.
MC: I have a question if that’s all right. So I have two kids, Rock and Ruby, they’re 4 and 7 I think, going on 5 and 8. I’m just wondering as a parent of two kids, what’s the best way to leave that conversational door open for my kids?
SA: I think the biggest thing you can do is to just explain things to them, explain that this is how people are. In the same way where if your kids see a gay couple and ask, “Oh, what’s with that?”, there’s two ways you can react to that; you can either say it’s just two men who love each other, two women who love each other. If you say that, then kids will probably just say, “Oh, cool!” then move on to the next thing, because they’re not born with these prejudices that we have as adults. It’s really the same thing you have to do for anything like this; I have some friends who are trans who talk to kids, and one friend of mine said, “I used to be a girl, but I took a magic potion that turned me into a boy because I wanted to be a boy,” and the kids thought that was so cool. Just opening these doors to make sure that people know that this is even a possibility, will help them find themselves. Most people in this world aren’t trans, so statistically your kids probably aren’t trans, but for the case that they are, you want to be there and you want to be supportive for them, because when you’re not, I think that that’s where we get into those statistics we mentioned earlier.
MC: Absolutely. Well, thank you for that.

MJ: Okay. So @sophiebits at twitter.com/sophiebits, github.com/sophiebits, sophiebits.com. Thank you so much for joining us, Sophie Alpert, and we will see y’all next week on the React podcast.