Brian Vaughn speaks about his transition from graphic design to programming, his building of react-virtualized, him landing his job on the React core-team, and finally, React's goals with 17.
We are joined by Brian Vaughn. Brian is on Facebook's Core React Team. He also contributes to a lot of open source products in the javascript space.
While Brian went to college to study Graphic Design, he ended up transitioning into programming. During college, he did a lot of graphic design consulting work, as a way to pay his way through school. Eventually, he agreed to create a website for a client and found that programming was a much better fit.
Brian built react-virtualized during his time he spent at Treasure Data. The company is really into open source, and many of his team members had projects out there. When they were writing the console, they used Facebook's fixed data table.
However, it did not have the features that they wanted. So Brian volunteered and built what would be the first version of react-virtualized.
The exposure he got from sharing react-virtualized with the community is what landed him the job on the React Core Team. A developer's success tends to come from sharing the cool thing they built. Share your work everyone!
Brian talks about React's goals with 17. Dan Abramov and Dominique have been working on creating an optimizing compiler for react components. The idea is that the compiler can read your components and optimize them. You will be able to keep writing React components in ways that make sense to you, and it will compile them and optimize at runtime. The team is also working on making functional components more powerful, so you do not have to reach out to class methods. It will be interesting to see what will shake out of their work when using async and the compiler.
"Brian Vaughn, React Core Team" Transcript
John Lindquist: All right, our guest today is Brian Vaughn. Brian, can you go ahead and introduce yourself?
Brian Vaughn: Yeah, hi. My name is Brian. I'm on the core React team at Facebook, and I maintain and contribute to a lot of Open Source projects, mostly in the JavaScript space. I like to run and sometimes I write and record music as hobbies. That's me.
John Lindquist: Yeah, so I checked out some of your SoundCloud stuff. You're very talented.
Brian Vaughn: Thank you a lot.
John Lindquist: You get around to recording or performing anymore, or is that kind of a previous life now?
Brian Vaughn: I don't perform anymore. I haven't performed in a while because it's a lot of work, but I do still write and record, just in a home bedroom studio situation.
John Lindquist: I'm glad to hear you keep that up. I know a lot of people just kind of lose track of that talent and let it go. Can I ask how you got into programming, what your first exposure was and first job and that sort of fun background?
Brian Vaughn: I went to college for graphics design, and I was fortunate enough to line up some consulting work initially doing design work, and then it sort of transitioned into doing some programming work, which I was using to pay my way through college. I had a client that asked me at one point if I could build them an interactive website and I said, "Sure, I can," even though I couldn't.
Brian Vaughn: And I bought a MySQL book and read it on a long weekend and thumbed my way through it and really enjoyed it a lot. And over the course of college, I realized I would much rather do programming than the graphics work, and so that just made the transition. I played a lot with Flash and Action Script in the early days because it was a nice overlap with programming and the visuals,. But yeah, that's how I got started.
John Lindquist: Yeah. Sometimes I miss the stage and the display list and all the fun animations and inter frames and all that in days gone by. It's funny you bring up the MySQL books; I remember the feeling of ordering a book online and that thick PHP book would show up on the doorstep, and like, this is gonna make me so much smarter. I'm gonna be able to build so much stuff with this giant book I haven't felt that in forever. Just haven't ordered a giant book, I guess.
Brian Vaughn: Yeah, that's also true.
John Lindquist: So how did you get into React? What was your experience there?
Brian Vaughn: Yeah, I worked at a couple of Bay Area startups. I worked at a company called Recurly in 2014, and Recurly was a subscription eCommerce company, and we had ... I think we were using React 0.11 at the time. We weren't really using it for most of our applications, but it was just controlling a couple of widgets here and there, like a typeahead sort of a thing. And then I joined another startup later in 2015 called Treasure Data, which is data management company. They have a bunch of software as a service to collect and analyze large amounts of data, and the cool thing about Treasure Data is that they were built on top of a lot of Open Source technologies. The company has written and released a lot of Open Source themselves, and they were very supportive of using React, I think.
Brian Vaughn: That was '14 at the time. We use it to build a console, which was the web interface for how you import data, you manage your databases and tables, you write SQL queries, these things. That was my first in-depth experience with React, because the Recurly one was very shallow. So yeah, Treasure Data was probably the first deep experience with it.
John Lindquist: All right. So they were already using it, and you went into the job and it was part of the job requirement? Or is it something that you introduced or someone on the team introduced?
Brian Vaughn: Well, I joined the company just as they were doing the big rewrite of the console application, and the front end team was pretty small. But they were, the folks that were there before me were really excited about React, and I was just fortunate enough to join at the time and get to use it, because I hadn't had much experience or opinion about it yet.
John Lindquist: Yeah. Yeah, I love the excitement of learning something new like that. I've been doing React for a few years now, and the excitement's still there, but the initial, "Oh, what's this thing do? Oh, how does that work?" Especially with the team, you're always discovering and sharing.
Brian Vaughn: Yeah. I made some really clowny mistakes in the early days. I put things in props that should have been state and vice versa, and I didn't understand why it mattered. It's fun to think back at that learning experience.
John Lindquist: Yeah. For anyone listening, we all, no matter how expert someone is, we've all been where you are. We've all made the dumbest mistakes possible. This is just part of the growing process. So what got you on the ... was your React virtualized work, your performance libraries and stuff, was that what got you on the React team, or how did that ...
Brian Vaughn: Yeah, I think that's probably the biggest thing. As I mentioned, Treasure Data was really big into Open Source. Some of the core engineers there had a lot of libraries that they had created and maintained, and they also contributed to a lot of larger projects like Ruby on Rails and larger frameworks. So when we were writing the console at Treasure Data, we used the Facebook's fixed data table component at first, because we needed to display tens of thousands of records of rows of data. So we wanted to window it so that we didn't have really terrible performance, but fixed data table didn't have some features that we wanted. Namely, there wasn't a way to programmatically jump to a specific row, which is something that was important for us if we wanted to highlight a row and [inaudible 00:05:33], or a column in your table that was misconfigured.
Brian Vaughn: I remember having this conversation with my teammates saying, "I think I can build this," and they're like, "No, that's a lot of work. That's a lot of work." But I was stubborn, and so I went home over the weekend and put together a prototype that ended up being the v.1 release of react-virtualized. Treasure Data was super supportive, let me open source it, which is awesome because that's something that I would have really struggled to do if it was just a free time project. Then we also were using Redux for our state management, and we wanted to be able to filter the data that you're looking at. So you're looking at a huge set of records and you write a SQL query to search for things, but maybe you want to filter farther within the browser. I wrote a search middleware for Redux that we could use to filter in the browser.
Brian Vaughn: It was another thing that I open sourced, and then I worked with one of my teammates, [Sazar 00:06:29] on that one, and we open sourced it. Then I guess Dan found out about it and tweeted about it, which was pretty exciting at the time because I had, I don't know, 200 followers on Twitter maybe, if that. He tweeted about it and one day, I just noticed a bunch of people following me on Twitter. What is going on? It was because of that. Yeah, he tweeted about virtualized and Redux search, which is the name of the other thing. That got all our traction, and yeah. Through that, I met a couple other people online from the React team. There's a direct line from there to the fact that I'm working on React today, for sure.
John Lindquist: Right. I found most developer's success is, I shared this cool thing I worked on and, just some either weekend project, late night project, put it online. Then it's just like a career boost. Share your work if you're listening, just share it. Seriously. That's a great story, I love it. So, what was it like joining the React team? I imagine ...
Brian Vaughn: Super [crosstalk 00:07:31].
John Lindquist: Well, just seeing all the feedback from the community, and all the different issues that you were probably never exposed to before. It's got to be a pretty daunting task to support everyone.
Brian Vaughn: Oh, yeah. It was super intimidating. I've done a couple of Open Source projects on my own. I think my first one was a PHP engine back in 2005, 2006 on SourceForge. So I've dabbled in Open Source for a long time, but nothing at this scale. Virtualized by far is the biggest personal project, but that's nothing on the scale of React. There's definitely been a lot of fun learning experiences, in terms of the types of considerations that go into even seemingly simple changes. My teammates have been really awesome in sharing their experiences, and that's based.
Brian Vaughn: It's been a lot of good learning experience, but joining was super scary. I was very intimidated for a long time, too, not just until I joined. I think I was intimated for the full first year. Just certain types of changes are just really scary to make. Certain types of PRs were scary to make, because everything is visible. There's so much scrutiny and spotlight on a project that has that much traffic.
John Lindquist: Writing code can be scary sometimes. No one should look at the code I write during the weekends. That's mine. Oh, that's good to hear that people are still people, even when they get on the big teams like that. So with React now, there's always something brewing there. There's been ... 16's pretty recent and lots of talk about 17. Can you go over some of the changes in 16, like specifically the unsafe changes and all that, and what developers should be looking out for?
Brian Vaughn: Yeah, so 16 has been ... yeah, it's been a lot of things. The initial 16 re-write was focused on a few areas. It was a big tech got cleanup to get rebuilt and adding full type static analysis coverage to the code base, making it easier to create custom renders. There were a lot of longer term goals for 16. There were some really nice short-term wins. Everyone liked that it got smaller, you could return a raise from render. There were some nice features that were enabled, but 16 I think was a forward looking release. It's starting pay off already. I mean if you look at the 16.3 release that we did a couple of weeks ago, there were a lot of features in that release for just a point release. And I think the fact we were able to add all of those features is a testament to the architecture that the fiber rewrite and 16 enabled.
Brian Vaughn: There's still stuff coming. Async is another big thing, like 16 sync by default, Async is still an unstable feature that we're experimenting with, but the architecture that came with 16 was to enable Async work.And yeah, you touched on the unsafe life cycles in 16.3 that we introduced. That's also part of our work with Async. We released a couple of blog posts around this time, and I don't know if we can include links to them in the podcast description anywhere.
John Lindquist: Yeah, we will.
Brian Vaughn: But if you have ... Awesome. Yeah, if you haven't read the blog posts, I would definitely encourage you to go to reactjs.org and check them out, because they have a lot more information that I won't be able to go into in the podcast. But the gist of where we're going with the class component life cycles, is that we've looked at a lot of code. Facebook has something around 50,000 React components between all of our mobile and web products, which is just [inaudible 00:11:13].
Brian Vaughn: We've also looked at GitHub. You use GitHub search features to look at Open Source libraries that are just on the internet that we can look at, trying to identify patterns that people are using in React components, and then the life cycle changes that came as a result of that was basically us recognizing that some of the life cycles are easy to use in ways that will cause problems with Async Rendering. That's not us pointing fingers at people and saying, "You're misusing this." This is just the API when it was created several years ago, the class component API has been stable for something like three to four years.
Brian Vaughn: No one was thinking of Async Rendering at that time, and you can do a lot of things in a sync rendering context that work fine that don't work well in Async. So it's been a process of us realizing how Async is going to work, and then saying, "Oh, what about this? This will hold pretty with Async." The 16.3 and probably the next release or two in 16 will be ... one of the focuses for us will be finding patterns that don't work so well, or might not work so well with Async, and then providing guidance and recommendations for things that will work better with Sync and Async, and that's, yeah. That's been a big focus.
Brian Vaughn: If you have follow-up questions, maybe specifically about the unsafe stuff, I'll give you a chance to ask them because I'm kind of rambling.
John Lindquist: Can you talk about the difference between Sync and Async just a little bit more, just to expound on what Async means?
Brian Vaughn: Yeah. So when I say Sync and Async. Synchronized rendering is the way that reactors traditionally work, which is just that when you call, for example, ReactDOM.render, React will render your entire application tree and update, in this case the DOM synchronously before it returns control to the JavaScript that caught it. Asynchronous rendering is a new thing that we're playing with. And there's some really great talks about this from last year's React conferences. There were some talks by Tom and [Lynn 00:13:17] and others about what sorts of things Async will unlock. There was a recent talk that Dan gave, maybe three weeks ago that was a really cool compelling demo to of the types of things that Async can unlock.
Brian Vaughn: But in general, I think the observation is that, well it's a couple things. One of it is that React, sometimes it isn't the only JavaScript on the page. We [inaudible 00:13:38] all the way for React to operate better with other JavaScript that's running on the page, so that React isn't using up all of the frame budget. Then we also wanted a way for React to do a lot of work, but still remain responsive to user input, like mouse-click events and things like that that require immediate feedback, and this recognization that certain types of input, let's say a network request that returns a response are inherently less important than other types of input, such as like a user click or a keyboard event. So finding out a way that React could support and do this prioritization and scheduling in a smarter way, I think are all things that feed into Async.
Brian Vaughn: Async, in a nutshell just I guess means that when your React components render, they might not all render within the same frame or the same tic. If you have a really complex application in the future, your rendering might take place over several frames, and that's to enable the things that I mentioned previously. Then what comes with that, is that any parts of your code that were previously written with the assumption or the expectation that rendering is synchronous, we have to look at that and find ways that we can provide people different patterns for writing code that won't have that assumption, because that assumption would break with Async Rendering. Does that answer the question?
John Lindquist: Yeah, yeah. For sure. Are these changes for people whose big applications are built on 15 and migrating to 16 and beyond? What's their outlook as far as being able to update and switching to the new component life cycles? Is this going to be a lot of work on their end? Are there going to be guides coming forth? How can we help them out the best?
Brian Vaughn: Yeah, totally. So I will say again that Facebook has something like 50,000 React components, and when the React core team makes a backwards-breaking change that we're ... and there's fewer than 10 of us on the core team, and we're responsible for not breaking Facebook. We each own several thousand components essentially, so we definitely feel the pain of legacy code and I think that's, hopefully I say this to reassure the Open Source community that migration from Sync to Async will be gradual, and it will be incremental and we're going to follow the same pattern that we've followed for the last several years, which will gradually introduce deprecation warnings, and as long as you're addressing them in each release, then you'll be able to continue upgrading without any break.
Brian Vaughn: So what this means for Async specifically is that, a couple of weeks ago, I guess it's been about a month now. I released a blog post that had a bunch of patterns. So here's how things were done with sync components or sync rendering, and here's the suggested patterns that we suggest instead for Async. We also released, there's a repo called React-codemods. We released a codemod on that repo to rename the life cycles to use the unsafe alias. We'll continue doing things like this with each release. We'll definitely be there doing the release with people.
Brian Vaughn: We've also released some helper libraries. So there's a create subscription as a package that we released along with 16.3, which it's sort of a library to help manage ... I think there are a couple edge cases in Async that we're working to make better, tricky edge cases. And one of them is subscriptions. Create subscription is a library that wraps up the complexity and gives you a really simple interface that you can use instead if you want to subscribe to something and do it in a way that's safe with Async. We're going to be looking to do more things like that.
Brian Vaughn: Another one of them is something that we've been calling Suspense, and this is something that Dan demoed a couple of weeks ago at his conference talk. But this is something that we think will dramatically simplify the story around Async resource loading and things like that. Our goal is to make a really compelling use case both from the performance standpoint. Like hey, you'll get these good things performance, but also from a syntactic standpoint. Like look, once you can use Suspense, for example. It used to take this much code and now you can do it in this much smaller amount of code, and it'll perform better. That's a goal, and that's a gradual thing that we're going to be working towards over the next, a year. I'm not sure what the timeline will be exactly.
Brian Vaughn: But, yeah, I would encourage people to just stay calm and tell us your feedback and your concerns. I know several of us are watching Twitter, Reddit, Stack Overflow, and we're constantly responding to and asking questions and taking feedback and this all helps shape our release strategy. So, definitely keep talking to us and sharing your concerns and we'll try to incorporate all that feedback.
John Lindquist: Awesome. And thanks for being so kind to the community that way. You don't have to be, right? It's cool to see that your team cares so much. I just add, I think it's one of the biggest motivating factors for upgrading the latest release of something. It sounds like you're improving the developer experience, like you mentioned working with the asynchronous code will require less and it'll be easier to reason about and you catching errors, and that'll probably be easier now. It's not just ... sometimes if it's just a little bit faster, or if the package is a little bit smaller, it's like, "Well, we can stick around on this version." But if it makes it easier to get your project done, it sounds like that's what's coming.
Brian Vaughn: Yeah, definitely. Yeah, we want to try to avoid fragmentation in the community. Ideally, everyone would always be using the latest release of React. That would simplify a lot of things for Open Source. [inaudible 00:19:28], but understandably, that's not something that can happen. But as much as possible, we would like to make that happen. So we do this through making releases. Deprecations are gradual, we always if we can provide codemods. If not, we provide clear dev warnings and recipes for how to updates thing, and then also as you say, sometimes the motivation of a little bit smaller or a little bit faster isn't enough. We want to make people excited, and we want them to want to update to use the new APIs because they're going to be easier to use and faster to write code. That's a big advantage of React in the first place, is that you should be able to write code and applications quickly. That's something that we're looking to do with features like Suspense.
John Lindquist: Yeah, React is a joy to use. I love building apps with it. Is there anything else you're kind of excited for, looking towards the future as far as React or its supporting libraries or Virtualized? Anything you're working on?
Brian Vaughn: Yeah, Virtualized is something I struggle with to find time with lately. Just finding time for that is something that I'll look forward to doing, but with React, Suspense is definitely the biggest short-term thing and just Async in general as we move forward with making that not an unstable, but a first-class thing that we support. Another thing that I can't talk much about because I haven't been very involved with it, but something that Dominic and Dan from the team have been working on a lot over the past several months, especially Dominic for a lot longer than that even, is work on creating an optimizing compiler for React components, and this is pretty cool. Once it's done, the idea is that this compiler will be able to read in React components and optimize them, which can include things like flattening them if there's a lot of nesting.
Brian Vaughn: We're doing other optimizations on how the JavaScript works using a Facebook technology called Prepack. And the goal for this is, or one of the goals for this project is that you'll be able to keep writing components in ways that I guess make sense to you ergonomically and such, and then we can run them through this compiler, and then they will perform better at run time. This is still early, early days. We're trying this on a couple of Facebook internal projects and finding out what works and what doesn't work and what we need to change, but that's a really exciting thing.
Brian Vaughn: In general, I think I'm really excited and interested to see what kinds of patterns just shake out of our work on Async and compiler in general. I think especially in regards to ways that we can make functional components more powerful so that people don't have to reach for class components to do things like [Stave 00:22:11] or things like get access to the life cycles. There's some fun brainstorming that's going on internally for ways that we might be able to add that stuff to functional components, and that would in turn help with Async and help with compilation efforts. So I think there's a lot of related stuff that's going on that hopefully will result in some even better APIs and stuff and future versions of React.
John Lindquist: Oh. Cool. I wrapped a function in a proxy the other day and gave it the context, like I managed the state of a pure component inside of a proxy. This feels very wrong, but it's really fun.
Brian Vaughn: That's the thing about JavaScript, that you can do a lot of things with it. [inaudible 00:22:49] and it's back. Yeah.
John Lindquist: Well, awesome. Thanks for much for your time, we're going to wrap up here. Do you have any closing inspirational words for anyone listening? Not to put you on the spot.
Brian Vaughn: Inspirational words. Well, maybe. I don't know. I would say thanks for having me. It's been fun, and I would say to anyone again, I think I already said this, but if you are an Open Source community and you're using React and you have ideas for improvements or suggestions or questions or complaints, talk to us, because I think we're all really accessible, on Twitter especially, but also in GitHub and stuff. We love getting ideas from the community to help the projects.
John Lindquist: Awesome. Great, thanks Brian.
Brian Vaughn: Yeah, thanks John. This has been fun.