Sophie is the bomb diggity

Hello, party people. We’re super-excited today. We have a very, very special guest. Someone whose career I wish I had. I was just telling her how I want her hair and I want her career, actually. Both things. We have the wonderful Sophie Alpert with us today. Welcome, Sophie.

Hello. Thank you for having me.

And on the panel today is Divya. Welcome back, Divya. It’s been a hot minute.

Hellooooo! It has.

Today’s show is gonna probably span a few different topics. We’re excited to talk with Sophie about her career. For those of you who may not be familiar with Sophie, Sophie was on the core React team for many years; I think maybe you worked at Facebook/Meta for four years, or something along those lines…

That’s right.

Yeah. And so she’s now currently head of engineering at Humu, so we’ll talk a little bit about her career… But one of the reasons why we invited Sophie onto the show today was really to kind of dive into her experiences on the React team, and being part of that early growth, as part of one of the most widely-adopted open source projects in the web community… And really, just some of the challenges around what its like to manage a project at that scale, and you know, all the kind of expectations around community engagement, and API nerd turfing, and all of that other good stuff. Lots to get into, so welcome, Sophie. Do you wanna just tell us a little bit about yourself in your own words?

Sure. I mean, I think you covered the highlights… I worked on the React team for about four years at Facebook, from – what year was it? Gosh…

Yeah, well I don’t even know what day it is, for what it’s worth…

[03:57] 2013 to 2018? I don’t know… See, that’s not even the right number of years. But yeah, for four years; 2015 to 2018. Wow. I used to know that off the top of my head. Now I don’t. Yeah, so I joined the React team when it was very early days for React. I actually started contributing to the React project just on GitHub before that; I think I became the number one committer to React before I even worked at Facebook.

Are you kidding me? OMG. And this is while you were at Khan Academy, right?

That’s right.

Again, another really cool job, by the way. It’s like a dream of mine to one day work there, so… But Khan Academy is great.

Well, yeah. So my career I guess is three jobs long. I worked at Khan Academy for an online non-profit and tech startup; I did that for a couple of years, I worked on a lot of frontend stuff there. When React was originally open sourced, I think I saw it online and read the site; it was like, “This really cool”, and actually, it worked really well for one of the projects I was working on at the time at Khan Academy… So I started trying it out. I shipped it to production I think two weeks after it was released, which in retrospect maybe seems a little irresponsible, but I think I was maybe the first production user of React outside of Facebook.

But it worked for me, it was exactly what I wanted it to be. I was using Backbone at the time, I had a lot of troubles with managing state, and embedding components in other components, and when I saw React, I was like – this immediately clicked for me, and I thought “This solves a lot of problems I have, and I’m excited to use it.” But at that time it was not popular at all. It was released at a JS Conf in, I believe, Florida in 2013, and was honestly widely banned from the community as soon as it came out, in part because of JSX; everybody was like “This is a disaster. Why would you ever wanna put your HTML markup in your JavaScript?” Which, I must admit, I also had that reaction when I looked at it, and I was like “React looks cool–”

No pun intended.

“…JSX doesn’t look as cool.” When I first started trying to use React, I said “Okay, I’m just gonna use React without using JSX.” And I think after like three weeks I was like, “Okay, I see the purpose of JSX”, and then I did start using JSX as well.

But somehow, the React model of being able to nest components, and just having the props and state and saying exactly what you wanna render at any given time just clicked in my head, and I was like, “This is great. I wanna use this.” So I did, and I started hanging out in the IRC channel. Can you imagine having an IRC channel for a new project these days?

Oh, wow…

That was what we had in 2013, back in the Dark Ages… And some of the core developers from Facebook were hanging out there, I got to know them, and eventually just started fixing more and more bugs in React, when they came up. Both ones that I encountered, and then also ones that other people encountered, and asked questions about it in the chatroom… And ended up just getting more and more involved with the team, and really enjoying working on React. And yeah, eventually at some point I said “Well, it’s kind of silly that I’m spending this much time working on React when I could just be doing it full-time as my job and getting paid for it.” So I eventually went to Facebook, and took that on as my full-time work.

Wow. There are so many insights there that I was completely unaware of… First of all, being the first person – at least the first major website that’s probably using React in production outside of Facebook - like, wow. Being the number one committer, and then – I didn’t realize how early you had joined. You had been contributing for even longer. That’s fascinating. And what’s so interesting for me is there’s this arc that I’m seeing with the folks that I personally know in the React team, folks like Dan, and Brian, and Andrew… All of them were community contributors before joining. So it seems like this interesting trend of “Hey, if you wanna go work at a FANG company, go work on their open source projects and maybe they’ll give you a job.” That’s pretty cool.

[08:13] Yeah. As the React team, we always liked to hire people who were very in touch with React itself and the React community, because we figured that’s the way you’re going to be able to best support the community on the inside, is if you’re already familiar with it coming in.

So yeah, we did end up hiring several people who had built third-party libraries that worked well with React. It turned out that that was a really great way to hire, because we could see their work, and we knew they were interested in React, and so then it was easy for them to get up and running, I think.

Sophie, so I think what’s super-cool for me about React - when it was first introduced, it didn’t… Like, it wasn’t just another web framework. I think it just introduced so many new components, no pun intended… We’re gonna have to count the puns after this show. But there were so many new components that were introduced along with it, including the Flux architecture, and the one-way data flow, and props, and kind of this componentization of your UI code that really – I feel like we were skirting around components for a while with MVC and MVVC and CVM, CVS, and all the permutations of that… Remember? We were skirting around it; but I feel like React just nailed it. It was just this intuitive API that, for the most part, if you squint your eyes a little bit around JSX, it is just JavaScript; like, there’s just a lot of power in that… Because I think listeners on this show have heard me use this analogy 100 times, but - with Angular, you could never… Like, I could never remember how to do a pipe, or filtering. There was always this arcane syntax… Because it was made up N developer land. It wasn’t JavaScript, right? So you had to learn this domain knowledge along with Angular… And with React, it felt like the amount of domain knowledge you had to learn was really minimal to be productive quickly.

Yeah. That was definitely the goal, and that’s definitely one of the things that I loved about React, is that any of these React elements, anything that’s essentially the value of a JSX expression - you can just manipulate it, the same as any other value in your program. You can put it in an array, you can store it in a variable, you can use it in a conditional, and it just works the same way as anything else that you might have in your program…

So our hope always was that maybe there is a learning curve to get familiar with how to use React well, but our hope was always that if you’re able to get through that, then that doesn’t just teach you about React, it teaches you about JavaScript in general, and it’ll give you skills that are going to be reusable for anything you wanna work on in the future.

Yeah, I think that was also an initial appeal to React in general… Because previously, when you’re learning programming or you’re new to it, you had to learn this entire domain… Like, okay, you have to understand what the DOM is, and you have to understand HTML, and CSS, and JavaScript, and all of this before you could actually do anything… And I think with React there was this ability for you to just learn the Syntax and then have all this power within your toolbox to build a very fully-functional application, without fully understanding the DOM. So there was sort of a reverse approach, where you don’t learn the – it’s like, I don’t know if this is the right way to look at it, but it’s like the fundamentals, and there was one approach where you had to learn the fundamentals before you start working on an app… And React is like “That’s not the case. Let’s get you started.” Because generally, when you’re learning, you wanna get things onto a page and be successful, and then as you’re getting advanced, you learn the bits and pieces… So I think that was a really cool approach, and it gave a lot of people more agency, which was really cool to see.

Fundamentals are always really important… And there may be times when you can skip over them. You’ll almost certainly wanna end up learning them properly later… But I think that also that was figuring out what things to teach, in what order, and what did our users know and not know is something that we had to grapple with as a growing library, or as a growing framework.

[12:23] I think that’s something that definitely changed over time as well, because in React’s first couple of years basically every single person who was using it is somebody who was personally really invested in the JavaScript and the web development community, who stayed up on the latest trends and who probably knew HTML and CSS really well, knew JavaScript really well, and they were people who found React themselves and thought “Oh, this looks cool. I wanna use this in my project.”

But then, over time, as React continued to get more popular, many more people started to use it, both in cases where somebody else at your company introduces it to the codebase, and then now you didn’t pick it, but it’s in the codebase you’re working with, you need to figure out how to use it… As well as people who are maybe going through a coding bootcamp, or some other type of instruction, where again, somebody else picked React and said “You’re going to be learning React”, and then the people who are actually done learning it don’t necessarily have that same background.

You and Divya both touched on some important points here, which is like React is so easy sometimes you don’t need to understand all of the – maybe some more experienced folks like us would consider foundational fundamentals… Like, you can wave past the fundamentals, and we kind of did see that a lot with folks struggling with the actual “this” pointer in JavaScript, and the entire API shifted as a result of that.

I think React landed in a place that’s better, I think, because of it, which is exciting. I think hooks – it took me a long time to get around to hooks, because I’m old and curmudgeonly, and I had a big “Who moved my cheese” moment… I’m like, “What the hell? I have to learn a new thing that does the same thing? I can do the same thing with the old thing. Why do I have to learn a new thing?” So I had that kind of curmudgeonliness. But I think after using it for a while and seeing the benefits, I get it. But it wasn’t instant.

And I think for me, when you know you’ve made it is when the bootcamps start to put you in their curriculum… So I feel like as soon as bootcamps were like “React is what you’re gonna learn for frontend”, everything changed. Not everything changed, but I would say the mass adoption scales had really tipped, because you had a bunch of newbies using this tool. So I’m curious to hear what were some of the challenges there with folks who are really struggling with some of the fundamentals… You know, being so productive so quickly, but then getting to this point where things are broken, and they don’t really understand why…

And then of course, there was the other challenge of that, which was before Create React App, I’m like “Good luck trying to set up your React environment if you don’t have a masters degree in JavaScript build tooling.” There’s just so many challenges there I think that the community has smoothed over now, but I’m just curious what was that experience like.

It was definitely an ongoing thing we needed to be mindful of. I think that even the current live incarnation of the documentation site - we basically assume that you are familiar with JavaScript, and that you are familiar with HTML before you try to go through the React docs. And obviously, there’s many, many different ways to learn React, and not everybody uses the official docs, especially for something like a coding bootcamp; they’ll have hopefully thought about that scaffolding and exactly when to introduce what concepts.

[15:57] The last time that we really redid the docs was probably in 2017, I wanna say… And even at that time - I mean, React was definitely getting popular, but it wasn’t as popular as it is today, and it felt like that still made sense for that time to say “Okay, these are the base assumptions we’re going to have, and we do expect that somebody’s going to know those fundamentals.”

Now, there’s this new beta documentation site that is out, and I think they’ve chosen a slightly different approach there to try to be a little more mindful of people who may not have that background, which I think is an incredibly great move… But yeah, we would routinely get people who are struggling with people in React, where the answer to their question is “Oh, you’re confused about this thing, and this thing that you’re confused about actually isn’t React-specific, even though the first place you encountered it was in React.” And I think that was true with “this” keyword, like you mentioned, Amal, and also, in Hooks, shortly after Hooks came out, I think we got a lot of questions that essentially boiled down to the behavior of capturing variables in a closure, in a function, where people were confused about “Okay, why aren’t these variables not changing”, and we actually had to take a step back and – we needed to figure out how to tell that story and how to explain that, and how to teach people “It is actually just using these JavaScript features. React isn’t doing anything magical here to make functions work differently than they work in an ordinary application.”

But then I think that’s still a great opportunity to help educate people and help people gain a deeper understanding of the fundamental concepts and the tools they use every day… And that’s one thing I’m really proud of in React, is that that time that you spend learning about closures, for example, is going to be useful to you in all of your JavaScript programming, and honestly probably programming in other languages as well… Whereas I think some of the other UI frameworks out there, they have more of their own concepts, where they have something else that’s sort of similar to JavaScript closure, but is just a different concept that they invented, that works a little bit differently, and is specific to that framework, and then you need to relearn more things that are specific to a specific set of tools.

I like the design methodology of building a framework that is specific, yet general enough, so that the knowledge transfers… Because yes, you want ideally folks to stay within that framework ecosystem, and keep working on it and building within that, but it’s also nice that there is this flexibility that you’re not tied to that per se. So if you’re working in React, you could easily move to – I mean, concepts are obviously different, but i worked in Vue a lot, and I moved from React to Vue. Honestly, React had certain concepts that translated. It was just the syntax changed. So in a sense, when you work within the React ecosystem and the framework, you’re still learning the fundamentals, and understanding how the web works, how the DOM works, how things are manipulated reactivity. And those ideas – the syntax changes, of course, but the ideas are the same… And I think that’s really powerful for a framework to think about, because then it’s just – I think that creates a longevity to it as well, because then things don’t expire with time. The ecosystem changes, and the framework can change alongside it, because it’s already been sort of keeping par with those changes and trends.

A hundred percent. And I think that’s one of the great things about open source in general, is that by sharing these concepts and ideating on what are different ways we can advance things, we help to build a common foundation that can be used by everybody in the future, and that future projects can build on top of.

Sophie - wow, that was very poetic, and I keep having my fangirl moments here… So folks who don’t get to listen in between the show, Divya and I were just gushing and laughing, so I’m gonna try to contain myself now… So I’m just curious, with this hockeystick growth wave that you got to ride and be a part of - you know, everything from the giant conferences, to the ecosystem just kind of booming… What sort of community management did you all need? Because it wasn’t just this tool that Facebook was using all of a sudden. It was this tool that modern web teams were adopting. So I’m curious what types of – how did community come into the project as the adoption grew?

I think a large part of it was us just needing to pay attention to what is going on in the community, what do people who are using React need, what are their top concerns, what are they thinking about, and trying to stay very in tune with that.

As one example, in the very early days when we were first adopting React at Khan Academy, the number one complaint I heard from my co-workers about React was “When I run into a problem, I always google it and I get no results.” Because it wasn’t very popular at that time, and not a lot of other people were using it.

And I thought to myself, “Well, normally, when I google for an error message or whatever it may be, where do I end up?” Well, it’s usually on Stack Overflow; usually, somebody has asked and answered the question there. So I basically said to myself “I wanna help solve this, and the way I’m gonna do this is by answering every single Stack Overflow question asked about React.”

So I subscribed to the #reactjs tag on Stack Overflow, and so I got an email every time somebody asked any question… And the volume wasn’t too extreme; it was like maybe one a day, or something… And I said “I’m gonna try to do my best to make sure that these questions get answers, and that’ll help both the people asking them in that moment, as well as it’ll help make sure that there’s a wide corpus of advice and knowledge about React that people can find when they search for it later.”

So I did that, and I did that for probably a year and a half, maybe two years. By the end of that time, it started to get a little bit unmanageable, where it was like “Okay, there’s like four questions every day, and I don’t know if I really have time to write answers to all of these questions.” But by that time, there were also other people who were answering the questions, and so I felt that I could step back. So that was one thing that I did at the time.

[24:09] At other times, as the React team, we tried a few different things out. We tried making a first-party official discussion forum, that we later sort of sunset in favor of other community-run platforms… And then also most of the React team has presence on Twitter, and that’s where a lot of the JavaScript community in general is, of course.

For better or worse… [laughs]

Exactly. So we ended up being pretty available there. I don’t even know if that was a conscious effort; I think a lot of us were just already using Twitter, but it was something where we tried to be aware of what are people talking about, what are people listening to, what are the questions that people have about React, and what are their painpoints. And you already mentioned Create React App. I think that’s another great example of something where – that was something that we basically never heard from people inside Facebook. This pain of setting up all of the open source toolchain and figuring out how WebPack works, and figuring out how Babel works, and figuring out how to plumb all those things together is something that third-party developers struggled a lot with, because the tooling in the ecosystem wasn’t very good for people who just wanted something simple and didn’t wanna spend a lot of time setting things up. That wasn’t something that people at Facebook had a problem with, because at Facebook the projects were already set up; people already had their tooling in place…

But in the community, that was a big pain point, and so one of the things that Dan (on the team) did was to create the project Create React App to make it so that you could, with a single command, get up and running. And I think that project is obviously alive and healthy today, but also I think helped inspire some other projects in the space, or at least I like to think that it helped. I think if you look at something like Parcel today, a bit pitch they have is that you don’t need any configuration. You can just install it, run it, and drop your files in, and it’ll just work. And that, I think, is a huge improvement for making it easy and accessible to get started with web development.

Yeah. We see this trend a lot in the JavaScript community, of like big, influential libraries or ecosystems kind of like always raising the bar. We went from zeroconfig being a thing, to now having fully-supported boilerplates, scaffolds, Create React App being a thing… We were talking to Rachel last week on the show, and she was talking about the new documentation site, and how there’s interactivity built in, and all this kind of feedback… And I think that’s also becoming – hopefully, the goal was for that to become a standard for popular documentation libraries to have interactivity, as well as a fully fleshed out tutorial in their docs.

So it’s really nice to see the envelope being pushed a little bit. However, there’s a dark side to that, sort of… Because I remember Create React App being the first thing I remember as seeing an actual development effort that was purely community-based from you guys, from the core team. Because obviously, y’all are doing open source work, but at the end of the day, Facebook/Meta is funding you, your primary job is to create this library to make hundreds and thousands of developers internally at your company productive, right? And I’m sure there’s lots on your plate even just for that. So now you’re focusing on this big community project, and then doing community work on what feels like your off-time… That can be a little exhausting. I’m just curious, was that draining at some point? Because it really feels almost like there’s two jobs, because you have external community work, and then there’s actual commit work.

[28:12] Yeah. I think there’s definitely things to balance when doing that role. I don’t wanna frame it as like in our off-time. It was still –

Yeah, I guess it was not off-time.

…definitely still doing all of that at work. It’s not like people were only doing community work nights and weekends. But yeah, there’s multiple things to balance. The good news is that usually things that Facebook employees were asking for to make React better are in many, many cases the same as what people in open source were asking for. And oftentimes, even when there’s a discrepancy, it was often just that the Facebook employees were maybe working on larger projects, and hitting problems before people in open source were… And that was actually great for us, because we solved those problems before people really hit them in earnest in open source; that’s a great way for us to be able to stay ahead of the curve in the community.

I mentioned Create React App is one of the maybe notable examples of a time where those needs did diverge, and we wanted to make sure to support the community still, even though that wasn’t something that Facebook was asking for.

So in general, I think the React team does a good job balancing concerns from different angles, and balancing requests from different audiences. Sometimes when people are annoyed at like “Oh, why isn’t React spending time on this?”, usually the answer isn’t “Oh, because it’s not important to Facebook, the answer is because the React team thinks they have other things that will help the community more, longer-term projects that are being worked on.

Right.

You know, it can be tough to work on a really long-term project. The React team has some projects that have been going on for 4, 5, 6 years at this point, basically. Some of them will be wrapped up in the React 18 release, which will hopefully be in the coming months… But as a community member, I think it can be frustrating to have this tool that you use every day and feel like the team behind it is working on things that aren’t going to benefit you immediately, or that you maybe don’t understand the value of yet. But I guess it’s a double-edged sword. I think there’s that pain, but on the plus side, being able to invest in very long-term projects is a luxury that a lot of projects don’t have, and ultimately I think helps push the project forward and push the industry forward. Or at least it will, if the projects work out, which we’re always hoping they do.

I’m actually curious, because there is a super-real concern that ultimately React was created as an open source project, and then with Facebook’s interests in mind, to some extent, because you are building for internal engineers and for those processes. What was the balance between the interests of the org versus community interests when it came to figuring out what went on the React roadmap?

The React team at Facebook/Meta, at least when I was there, was given a lot of autonomy - I imagine that is still the case - to focus on the things that are most important for the React project. And it was very rare that we would ever have to confront a conversation of the form “Oh, should we do this thing that will benefit Facebook, or this thing that will benefit the community?” That really rarely came up. Instead, it was a question of “What are the biggest problems with React? What are the things that we can make the biggest improvements to? What are the things that people are running into again and again?” and then figuring out how to make improvements to those things.

[32:04] And I think that – I already mentioned this, but Facebook is operating at a larger scale than most other applications. Facebook.com, as of a year or so ago, is basically 100% React now. That was a rewrite that took quite a long time, and a lot of people worked very hard on that. I mean, I don’t even know, but there’s probably thousands or maybe tens of thousands of components involved in the website, and that means that some solutions that maybe would work in the community wouldn’t work for Facebook.

And you know, if I pick an example, it’s – like, for example, maybe it’s prohibitive to send down the list of possible routes, the list of possible URL patterns for the application. At Facebook’s scale, that would be a huge, huge list, and it just doesn’t make sense to do. So Facebook had to – not the React team, but the Facebook team working on the new React website… That’s a confusing term; the Facebook team working on the new Facebook website built-in React ended up building a routing solution that doesn’t rely on sending down that full list of URL patterns upfront.

But then when you see the React team exploring things like React server components, a lot of that is inspired by some of those solutions that have been built at Facebook for routing and for data fetching and for incremental loading of component code, and doing that in the most efficient way, where oftentimes at that scale there are certain changes you need to make in order to do things efficiently, that would still benefit people at a smaller scale, but just never rise to the level of something where you would say “Oh, okay, this is one of our biggest problems and one of our biggest opportunities to improve.” But then if we can use that inspiration when building React, then hopefully - that means everybody using React - will benefit from that; their sites will be a little bit faster, or a little bit more scalable, even if they don’t themselves have to do anything.

Yeah. I have to say, I’ve always personally been inspired by Facebook’s scale, because I think – for me, I’ve always thought about the folks working on Facebook.com as working on the most used website besides Google.com, and Google.com is just like a box. Granted, there’s a lot going on, don’t get me wrong, on Google.com… But there’s a lot more going on on Facebook.com when you’re logged in.

So I think for me that scale has always been very interesting, and thank you for sharing that story about the routing. That makes a lot of sense. A lot of problems of scale aren’t translatable to every average web dev problems, the everyday problems, and I think it’s hilarious when I see folks trying to optimize the crap out of their to-do app, or their blogs. It’s like, “Y’all, you don’t need to handle a million requests per second. Chill.” You know what I mean?

Yeah.

So it’s good to keep that in mind, that folks working at Netflix, Google, Amazon are solving scale problems that are very unique to their use cases, and you don’t necessarily need to go and adopt them. However, there’s lots of goodies that you can adopt, like good patterns and best practices.

So I’m just curious actually, to kind of segue into maybe some of the stuff we were discussing a little earlier around community - community also means that you also need to manage opinions and have a funnel for people giving input to the API. And this is specifically folks external to Facebook. So I’m curious, what is open governance like in React right now?

[35:59] Because I’m aware that there’s a new working group - I was speaking to Brian about this a few weeks ago in New York; he told me that there’s this new working group that’s been put together, which is exciting, and I’m so glad to hear that… But just in general, how dd you all manage governance, and what’s the funnel for community input? Because I think for me that’s always been a black box with the React team. Because it just feels like it’s the React team show, the core team show… Which is fine, maybe, sometimes; not always though. With Suspense there’s a lot of back and forth for the community… So I’m just curious if you could shed some light on that.

In many ways, it is the core team’s show. I don’t think anybody can dispute that. And it’s also hard for it to be anything else, because the React core team is several people who spend all day, every day, thinking about React, working on React, hearing about the problems people have with React, hearing about different nuances and quirks that people are running into, hearing about the problems that different people have… And if somebody who doesn’t think about it, talk about it, and work on React all day, every day, wants to contribute, it’s often hard to have this amount of context necessary in order to be able to make those –

Informed opinions?

Yeah, exactly. It’s actually not that uncommon that somebody in the community will say “Oh, can we change React in this way, to solve this problem?” And then the answer is “Well, that sounds like a cool idea, but also it would cause all these other problems, or it’s not aligned with this other future direction that fits into some of the existing plans.” It can be pretty difficult to explain all of that context to people, especially in a case where that context is always changing. And you mentioned Suspense; that’s a great example, where Suspense for data fetching is still not released in a stable version of React. And the reason for that is because the React team is still figuring out what are the ways to make this work? What are the ways to make this intuitive and reliable and easy to use, so that it solves the problems that people actually have and doesn’t cause more problems?

We originally talked about Suspense – it must have been in early 2018, maybe in March. That was 3,5 years ago. If we knew at that time that it would take this long to get it into a stable release, I’m sure we would not have talked about it that early, because it did cause a lot of thrash in the community. Because we had ideas of what would be necessary to change in people’s codebases in React in order to provide those features. And ultimately, a lot of those – well, first of all, those ideas were fairly complex and nuanced and difficult to explain, but also a lot of them ended up changing as the React team continued to iterate on those features and continued to learn more about how things are set up, or how things need to be set up.

So the React team I think always wants to try to get people bought into the vision, “Here’s the story, here’s what we’re currently thinking”, but that messaging work to make it clear what’s going on without worrying people, without scaring people, is a lot of work, and especially if the thing that you’re trying to message is something that is constantly changing, then that’s even harder. I think that’s one of the things that is tough about having a really large community, is that different people will have different amounts of context, different people will have different pre-existing knowledge, and what will resonate with one user of React is not going to resonate with someone else.

[40:07] So on React we try to be as open as possible. One of the big things we try to do is develop in the open on GitHub, where - you know, not all the conversations that the React team has are on GitHub, but a lot of them are. All of the pull request reviews are public, the React core team uses pull requests the same way that anyone else would to try to propose a change to the React project… And you can learn from all of those discussions. That was something that was really important to us as a team. It’s different from what most other Facebook/Meta open source projects do, but it was important to us as the React team to try to be as open as we can, and try to get people bought in.

I think the progression of that was pretty clear throughout the project, because in earlier versions of React at least it was – anytime a version was released, there was some breaking changes, and if you wanted to use the next version, you kind of had to change to the next version… And I think it was like React 17, 16, something like that, where you all introduced this gradual change, where you didn’t have to change the entire version. You could just sort of do partial changes, so that you could move your application up without having to create this crazy refactor, and people were not falling behind in upgrades, which I think was happening in the past… Because if you moved from React 13 to 14, it’s like, okay, there’s some changes there that you need to change large portions of your application, and that might not be in line with current business logic… Because you need to make money for your business, so how are you gonna do that, so you fall way behind…

And I think it’s interesting that you talk about just like trying to hear what the community is thinking about, also trying to balance the needs of how the team wanted the project to progress, versus what the community needed as well. And yeah, it’s really cool to see just the iterations over time, where in the earlier stages it was just like “This is the direction of how things are going” and then over time I think there’s been more allowance for what the community’s needs are, and hearing how are people using it, and there’s more of that conversation, I think… So I think I see that a lot more now, and it’s really cool that that’s happening, because it means there’s a cohabitation between the community and the React core team as well.

Yeah, for sure. And then the RFCs - I think you brought that up in the break, Divya… Do you wanna double-click into that a little bit? I think it was cool that RFCs became more of a thing, I would say, with React…

Yeah. At that time I think Yarn had done it, but Yarn was part of Facebook too, so… I think Ember maybe had done an RFC process as well at that time… I can’t remember.

Yeah, I think Ember was where we originally took that inspiration from.

Yeah, and it’s cool to see, because again, it was sort of the first stage where – I think previously there were ways in which you could talk about what you wanted, and things that the community didn’t really have an avenue for talking about what they wanted, versus just going on Twitter and just being like “I wish React did this”, or sliding into your DMs directly and asking you, which might be really annoying…

[laughs]

But yeah, the RFC process–

Hey…! [laughs]

I mean, it happens… I guess if you don’t have a platform, you make your own… So the RFC process was nice to see. Ember sort of started that trend a bit, but it gives the community a voice, or it gives them a platform in which they could voice their opinions… And I think I’ve seen a lot of really fruitful discussion from there. And also feedback.

I’ve spoken to Dan Abramov a bit at one point, about how there was a point when they were – I can’t remember which feature it was, but just like a suggestion for a specific feature, and the community was like “This doesn’t make sense. We want it to be this way” or “This is how we work.” And it has shifted the architecture, or at least the way you think about making decisions, which I think is very important when you are an open source project… Because ultimately - yes, there are business interests because you’re part of Facebook, but the community is also part of what sort of led to the success of React overall.

Yeah. Very well said. And you have to also draw the line somewhere, right? Because if you try to please everyone, you please no one, and it’s a tough battle. But anyways, we’re gonna take a break here, because we have lots of – I would say the hot topics coming up next, maybe… I’d love to really hear Sophie’s thoughts on what parts of React could be in the platform… All that good stuff. So we’ll be right back.

Alright, Sophie, so now we’re on to the fun stuff, right? [laughs] The controversial topics. Thank God you don’t – no, I’m just kidding. I can’t get you fired from Facebook because you don’t work there anymore, right?

Exactly.

You’re working at Humu, so I can’t get you fired. That’s good.

Yeah. I’ll get retroactively fired.

Yes. [laughs] No getting Sophie retroactively fired. That’s bad. So obviously, we hear a lot of opinions on the internet about React. “React should be this, React should be that”, people who I love and admire and I adore kind of poo-poo talk React sometimes… And I kind of wish people were nicer about the way they talk about APIs, because APIs get deprecated, people don’t… So I think people should always remember to be respectful and constructive in their opinions. I wish people did that more often, but it doesn’t always happen.

I personally - I’ll start with some of my beef with React, which is really around synthetic events. And it wasn’t made clear to me until very recently – like, I understand now why synthetic events are still a thing inside of React, and that’s because I think people forget that React isn’t just for the web. It renders to many different platforms, and so there’s some interoperability that needs to be handled there.

The way I’m thinking about React is I think it’s maybe a better tool for folks who wanna keep that door open to mobile… But if you’re building a web-only/web-first application, then you can use React or a bunch of other things, right? You’re not just limited to React. Anyways… Any thoughts on synthetic events, and why they’re still a thing?

[48:05] Yeah. Synthetic events were originally created to paper over some differences in the ways different browsers handled events… Most of those have been flushed out now, where they – browsers these days tend to be pretty compatible, especially on the parts of the web standards that have been around for quite a long time at this point.

If React was being built today, I don’t know that it would have the event system in the same format… But an important question to ask is – like, if you’re asking about getting rid of the synthetic event system, what does that actually mean, and what is the benefit that a user of React would gain, or someone who has to interface with React and doesn’t actually like React, or whoever it is - what is the benefit to people of getting rid of the synthetic event system.

There’s different answers you can find to that. One of them is that it used to be difficult to have React apps embedded in a larger page and have the events bubble correctly in the right order. And that is something that was fixed, I believe in React 17, without getting rid of the synthetic event system, but just by changing how it works slightly, by changing where it attaches the listeners in the document, so that that problem is now solved, and that type of interop does work, both between React and other frameworks, as well as between different versions of React.

I think that there’s a few other quirks where forms submit event bubbles in react and doesn’t bubble with the normal browser event… I’ll say I think that was probably a mistake, doing it that way, and it probably shouldn’t bubble… But also, we always have to weigh the amount of effort to change something and the amount of thrash it will cause on the community, versus the benefit that changing it will give. That’s one where it’s not the decision I would have made today, but also, I don’t think it’s causing a lot of problems for people. It doesn’t add a lot of bundle size to React, it’s not making things confusing for people and their applications very much… And it would require some breaking changes to get rid of that might be annoying for people.

And so for something like that, oftentimes the answer is just “Well, let’s leave it as it is”, because keeping a stable ecosystem is more important than getting to the magical, mythical, perfect version of React that we might ideally wanna get to.

That makes a ton of sense. I think what’s challenging is - to kind of play devil’s advocate here - and this is the argument I’ve used in the past as well, to be very clear. This is a well-rehearsed argument… Like, why can’t acebook can fund those projects, they can hire Igalia, there’s lots of ways to get those interop issues patched. Is it worth the overhead and the bloat in the library?

Synthetic events have gotten smaller over the years, for sure, in the refactors… But I’m just curious, is that contributing to browsers and pushing them – is it too slow? Because I really do think of Facebook engineers as probably being very fast-moving and very – I don’t know, the opposite of the standards world, where things move glacially slow. So I’m just curious, is there conflict there, or is it just faster to do it yourself?

Yeah, I would say Facebook is very open to getting involved in trying to change web standards when it makes sense for the community to try to do that. I think that there are definitely pros and cons to be conscious of… The speed of iteration I think is the number one thing, where when something is part of React – obviously, React now has its own many million plus users to worry about, and not thrashing them… But still, it’s something that can change over time, and can make backwards-incompatible changes, which is basically not true on the web. Once something’s part of the web, it has to stay that way forever.

[52:19] Yeah, for sure.

And if something is part of the JavaScript code that is downloaded on pageload, then that can change over time, as we learn new things. When you talk about standardizing something and moving parts of React into the web platform, in principle, a hundred percent on board; I think it’s just a question of okay, which parts it make sense to move, that are stable enough? And oftentimes I hear like “Oh, can’t we just move the React component model? Because that doesn’t seem like it’s changed very much… And can we standardize some form of that?”

I think we need to be careful with how we do that, because doing that is committing to essentially never changing it, ever, in the future… Or at least any form of a change would be by introducing some alternate, second API into the web platform that could be used alongside it. And for the React component model, as an example, that’s something where in the releases of React that have come out so far it hasn’t changed very much. But then I think you can see – I mean, even pointing to Hooks as an example, where I think before Hooks came out, people might imagine saying “Oh, it would make sense to standardize this idea of like a UI component, and have these componented mount hooks, and component update.” Because that was what React did, and that was what a lot of other frameworks did at the same time. But then would that have meant that React Hooks couldn’t have been invented, and couldn’t have been released? I think that would have been a loss; I am, at least personally, a huge fan of React Hooks. I know some people don’t love them, but I like them. And I think that Suspense - of course, another divisive topic in the React community, but that’s another example…

[laughs] Yeah, it’s all in the name, Sophie. It’s all in the name. You should call Suspense something fluffy and cute, instead of Suspense. Suspense reminds me of like an Alfred Hitchcock movie. That’s what I think of when I hear Suspense. I’m like “Huh! Suspense!”

I’m actually not sure what that team’s latest thinking is on that. They might actually be planning to phase out the name. Because I know some of the draft APIs are called things like “use transition” and “start transition”.

Oh yeah, actually. Yes, the new Transitions API I think is the new – yeah.

So it’s possible that maybe the Suspense name will finally die completely. Maybe Dan’s listening to this right now and shaking his fist at me for saying Suspense, I don’t know…

Transitions seemed to be the word that Brian was using the last time we spoke, but maybe that’s – I don’t know for sure.

I think when it comes to – you know, the general theme of those Transitions APIs is adding core support for asynchronous tasks into the core of React and into the component model, so that React understands “When do I need to wait for some data to be fetched, or for some operation to finish, or for some code to be loaded?” And that is something that has been a request since probably React’s very first year. I think we had some requests of “Oh, can I just return a promise from my React components?” And again, with that, it can be tempting to be like “Yeah, we’ll just patch that in”, but instead, we tried to be a little bit more patient and think about “Okay, how does this actually all fit together? How can we make this the absolute best it can be, and sort of reimagine things from first principles?” And the result is some of these new transition-related features that will be part of upcoming React releases once they’re stable. And if we had tried to standardize the existing synchronous React component model in the web platform, then it’s possible that these changes could never have been added.

[56:00] So I think you need to be careful when you’re talking about adding things to the web platform, because obviously, the advantage of the web platform is that it’s available, it is stable, it is something that people can build upon… But that’s also the cost - it has to be stable; it can’t change, it can’t evolve… Or at least it can only evolve in sort of an additive way. You can’t change things that are already there.

Yeah.

But that doesn’t mean that the React team is not invested in web standards. To give a couple of examples, the React team has been working, especially with the Google Chrome team, they’ve been great partners, I know, on a few new features for the web platform. One of them is a scheduling API for asynchronous tasks, another one of them is a feature called display locking, which is a way to make some changes to the DOM without having them appear on screen, that will essentially avoid the need to stall the browser while it redoes layout if you can say like “Okay, this computation can essentially be done in the background by the browser”, then that gives the browser more power to schedule those computations intelligently…

Yeah. That feels like a really cool cheat, by the way. I love that. That’s like a way to get around the whole single-threaded render blocking kind of actions. It almost feels like a very assistive thing to the virtual DOM reconciliation algorithm; that’s really cool.

Yeah. I know that the React team - you know, they sit back and they say “What are the biggest problems that are facing application developers today? …either folks who use React, or folks who don’t use React.” I know that they also take inspiration from like “Okay, what is happening in the game development industry? What’s happening all over the place? What are the biggest barriers, and how can we make progress on them?” And if the answer to that question is “Oh, the best way to make progress on this is that we can’t without making changes to the web platform”, and that adding new browser APIs is a way that will unlock more capabilities for React apps, and in most cases for many other apps that are not using React as well, then that what makes sense to push on.

But at least to this point, it hasn’t felt to me - I’m sure opinions may differ on this, but it hasn’t felt to me like taking things that are currently in React and working well in React and standardizing them, it hasn’t felt like that’s one of the highest leverage opportunities to improve React and improve the web in general so far.

Yeah, that’s really well said. There’s this kind of push-pull between web developers and folks working in the standards communities, specifically folks that are writing for JavaScript engines, and browser rendering engines, and web developers… That kind of push-pull is really around trying to follow the web developer cow paths… So web developers very often pave the cow paths for what will in ten years be maybe standard on the web platform, or maybe there would be ways to do similar things in the web platform. Promises is a great example of that.

Thank you so much for, I think, for me very clearly explaining that “Hey, Amal, React needs to iterate, and we still haven’t found our perfect thing yet.” And “Hey, there’s these browser APIs that are going to hopefully help facilitate some of the scheduling work and some of the asynchronous work that we would like to do.” However, it wouldn’t be wise to commit to these APIs and these interfaces just yet… Thank you for explaining it to me in those terms; I think that clicks for me… I don’t know, what do you think, Divya?

I think this is a very valid conversation.

[01:00:01.20] I kind of wanna throw the coin over… [laughter]

I think we’ve covered a large breadth of topics…

Yeah, we have. I know. Sophie’s the bomb diggity. So I guess, to maybe continue playing devil’s advocate a little bit, Sophie… So there’s this need to do a lot of scheduling work with React. I remember a few years ago I was at Chrome Dev Summit, and Andrew Clark was on a panel representing React… Do you remember that?

I don’t remember the exact one.

Yeah, okay. But anyways… But he talked a lot about – we’ll link to it in the show notes, but he talked a lot about how React needs to do a lot of scheduling. And that was kind of the concern at the time. I think this was maybe 2017, or something like that. Or 2018, I can’t remember. And I think there’s lots of frameworks that don’t need to do as much scheduling work… And you think about Preact, you think about Svelte, for example, that doesn’t have a virtual DOM, or a lot of this other kind of internals around asynchronicity… What are some needs that are really driving that on the team for you? Or what were some needs that were driving that when you were on the team? And are those things that – similar to what y’all are doing now with the Chrome folks, should we just be pushing those towards native APIs that will allow you to do the thing better, versus trying to do it in JavaScript? Because concurrency is really hard…

Definitely.

And just in general, like - working within the JavaScript event loop, and trying to game it… It’s hard. It’s really, really hard. So I’m just curious, how much of that is really – what’s the core driving need for that?

Yeah. I mean, I think it was all based in “How can we make faster applications?” or applications that feel faster. There’s a few ways to do that. You can do the same things, in the same order, faster, you can do fewer things, or in some cases you can do things in a different order, where the actual things themselves may take the same amount of time, but if you can do the important ones sooner, the ones that a user is actually waiting on, and expecting and anticipating to see, where they just clicked a button and the number one thing they care about is seeing the results of that button click. Or they press the key on their keyboard while typing into a text field. That’s the number one most important thing for a website to feel responsive and fast.

In some cases, one of the things that the React team noticed, especially when working on larger apps, both at Facebook and outside of Facebook, is that sometimes when you’re typing it’ll lag, because the browser is doing something else. And when I say “The browser is doing something else”, it’s usually some other JavaScript on the same page that is running at that time. The browser is busy executing that JavaScript, or executing some changes that that JavaScript made to the page.

[01:03:02.13] So I guess we asked - okay, well if we’re able to make sure that the number one priority for the browser at any given time is doing the things that the user is actually actively waiting on, then that is going to make things a lot smoother, and it’s going to make a much better user experience. So that is something that, to some extent, can be done without adding new browser APIs, to be honest… And React had some prototypes where essentially we built a scheduler entirely within JavaScript, that runs on top of the browser, and then we tried to schedule all other work through that. And that worked, and made some significant – you know, it had a lot of promise. But also, when we looked at that, that was something where we said, okay, this is a case where the browser clearly can do this better than we can do in user land, and also, this is the sort of thing that in order to really, really be successful, needs to be a common API, a common single schedule that schedules all of the work that’s happening on a page, that isn’t just what React uses, but is also what other pieces of code that might be on the same page use. So for that reason, it can really benefit from being a standard, and so then the work on scheduling APIs in the browser really came out of that, as a way to say, okay, how can we take advantage of what the browser does best, and also make it so that there is this standard built-in API that any library, including React, can make use of.

Yeah. You know, that makes a lot of sense. I’m glad to see that there’s like a user-centric-driven – like, ultimately, it’s really at the core, about improving user experiences, and that’s really exciting.

Sophie, it’s been an absolute pleasure having you on the show today. Really, I’ve been a fan of you, and I’ve been watching your career for a long time, so I’m really glad that we got to do this today. Is there anything else you wanna let folks know? Where can they connect with you online…

Thank you. It’s been a pleasure being here today.

And you’re hiring at Humu, right?

Yes, we are. Yeah, at Humu I lead the engineering team; we’re a small HR tech startup trying to make better work environments for people, and trying to support everyone with what they need in order to grow at work. So we are hiring engineers of all levels, we’re also hiring designers and PMs, if you know anyone… So check us out there. You can also find me on most places on the internet, but I guess especially Twitter. My username is @sophiebits.

And you also work with Kball.

I work with Kball.

Yeah. At Humu. We’ll put that in the show notes. So thank you everyone for listening. This has been a delightful conversation. We will catch you next week. We have an awesome show with my co-worker, Liana Leahy. She’s a product manager. We’re gonna be talking about transitioning from engineering to product… So it should be a really fun conversation. Catch you soon, folks…