This is the third episode of Stack Stories, sponsored by STRV. Hosted by Yonas, CEO, StackShare. Follow us on SoundCloud or subscribe via iTunes.
React is now one of the most popular JavaScript UI libraries in the world. It has over 70K stars on GitHub, over 1100 contributors, over 6M downloads this past month alone, and well over 4K company stacks. But when Facebook first introduced React to the world, not too many people cared.
For the latest episode of Stack Stories, we did something a bit different. We decided to focus on the origin story of the one of the most popular technologies in the software development world: React. We sat down with Pete Hunt, one of the original creators of React, now CEO at Smyte, to get the untold, in-depth story of why React was first created, how it gained adoption within Facebook due to the Instagram acquisition, and it's eventual release to the public.
Listen to the interview in full or check out the transcript below (edited for brevity).
Check out Stack Stories' sponsor STRV at strv.com/stackshare.
- The One Man Facebook Video Team
- From Facebook Camera App To Instagram Acquisition
- Instagram Needs A Web Presence
- React Gains Adoption Within Facebook
- Open Sourcing React
- Reflections and What's Next For React
The One Man Facebook Video Team
I think it became like the number three most popular video site in the world or something. It was this hackathon project that was barely maintained, so I was like the one guy at the company that was maintaining this thing. This was back before Facebook Live was a priority or any of that stuff...
From Facebook Camera App To Instagram Acquisition
Zuck gets everybody together and is like, “Hey mobile is going to be a big deal and we are dropping everything and moving tons and tons of resources to mobile.”...I was like, “We can’t maintain the largest photo site in the world with a handful of people, this is crazy guys. We’re putting all these people into iOS and Android for apps that make up a minuscule amount of our traffic this doesn’t make any sense.” Turns out that it was 100% the right thing to do, that’s why I was not CEO of Facebook...
We had this app that we built and we were really proud of called Facebook Camera... We worked really hard on it, I wasn’t working directly on it, I was supporting it from the server side but we had a bunch of really talented engineers working on it and tons of designers. Instagram just came in and ate its lunch...
With Instagram they gave them a garage in the Facebook campus where they could just do their own thing. They took advantage of the Facebook kind of trusted safety systems, but other than that, they continued to use AWS, they continued to draft their own product strategy from what I could tell...I was the first one to go full time over there to Instagram when that happened...
Instagram Needs A Web Presence
They had photo pages and the web was a bit of a strategic thing for them, so they were mobile first, Instagram has always been mobile first. Instagram actually, a lot of the content is public and, I think SEO was an important thing for them...
They were using AWS and all the cloud computing stuff that you are used to, all off the shelf Django run on AWS talking to Postgres, pretty different software stack.
...You couldn’t see all the photos somebody has uploaded or anything. We wanted to fix that but we had this problem where if you are, this goes back into the stack, but we had these application servers that were Django and we had these database servers which were Postgres and Postgres can only support a certain number of connections...we can’t add any more load to the servers, and serving a bunch of dynamic web pages actually does add a bunch of load to the servers, especially when it’s going to be exposed in the public web. We decided we had to do client rendering.
I went to the front end engineering team at Facebook called UIE...I was like, “Hey we need a JavaScript framework what should we use?” They were like, “Well we’ve got these three or four experimental things that we have baking right now. We have BoltJS, we have JSHTML and then we have this React thing.”...I took a look at all of them and I talked to the people working on them and decided to try out React
Instagram was kind of the future in terms of tech stacks at least relative to Facebook, and I was bridging the Facebook world and the Instagram world. I saw that Facebook is five years in the future in one direction and Instagram is in the present but kind of in a slightly different direction.
React Gains Adoption Within Facebook
The ads team is some of the strongest front end engineers out there and they came to me and they were like, “Hey how was your experience building with React,” and I told them. I said, “Hey I’m a huge fan I don’t want to use any other framework other than this thing.”...
The guy that actually originally came up with idea for React, Jordan Walke, came from the ads team. He was like, "making a change on this product is terrifying, like potentially lose a day of revenue because you’ve missed a semicolon or something." He had felt the ads pain and then he convinced them after building this thing on nights and weekends to work on it full time for a little while. As he was working on this framework full time he built a type ahead component and had rolled that out I think in maybe a little News Feed unit but never a full application. Instagram was like the first full application...
Then Ads says, “Worked on that News Feed thing, worked on the Instagram thing, we’ll try it on ads.” Mobile search said, “Hey it worked on that News Feed thing, it worked on that Instagram thing and I hear that ads is going to try it,” and then they keep going.
We were really excited back at Facebook because we had been writing documentation, getting it ready and it was early morning for us because we were on the West Coast and the tweets started to roll in that were all like, “Facebook is terrible, this is the worst idea I have ever seen.”...We were like, “they’ll love this” and we didn’t realize that like that’s not how the rest of the world thought... Nobody used it and it was just kind of like a disaster.
Then JSConf EU was later that year...I wrote this talk and I was like, “I’m not going to try to convince you that React is better. I’m just going to tell you why it’s different and these are the three or four things that nobody has tried before.” That was a lot more; people were a lot more receptive to that.
Another thing that is often overlooked about React when you think about stability, within Facebook there are, I don’t work there anymore but when I left there were tens of thousands of React components which probably translates to hundreds of thousands of lines of code. Whenever React wants to make a breaking change, they can’t tell other people to re-factor their code. They have to re-factor those hundreds of thousands of lines of code themselves... React team has to do it all. What that means is that it has to be automatable with some sort of script and those scripts are shared with the community and that’s why you don’t get an Angular 2 scenario with React because the people paying the price are the people actually making the breaking changes.
Reflections and What's Next For React
What I wanted to do was I wanted to have a React team certified badge where we say, “Hey, we are blessing this third party library and we say this is the right thing to do.”...
Fiber just started passing all of its tests recently and that’s a really cool project. It does bring a lot of really interesting concepts so that’s really cool. I think the React VR announcement was really interesting. If you think about all the different platforms you can target with React Native or with React, there is iOS, Android, web, VR now...That’s really cool because you teach these engineers how to write a little JavaScript and the basics of React and then you just give them API documentation for all these platforms and they can go and move really quickly. That’s really cool, that’s stuff that I’m really excited to see.
Yonas: All right welcome. Pete do you want to introduce yourself?
Pete: Yeah I’m Pete Hunt formerly of the React team at Facebook a long time ago. Over the past two, two and a half years I’ve been CEO and co-founder of a company called Smyte.
I grew up north of Boston and amongst many, many Red Sox fans which turned me into a fan of kind of anybody who plays against the Red Sox basically. If you ever met any Boston fans you know what I mean.
I went to college in upstate New York and then basically went straight from my graduate program to Facebook in at the end of 2010.
Y: When you first got there what team did you join and what was the set up for what you were working on?
P: I got my master’s in computer science and I focused on distributed systems and I was really excited about building the next distributed database, because this was back when databases were a really, really cool technology. There were all these new database startups coming out. I thought caching was really cool and distributed consensus and all that stuff.
I joined Facebook and I was thinking, “All right okay I’m going to work in search infrastructure, memcache,” there is this thing called TAO which is their distributed graph database.
What happens at Facebook is they put you into this bootcamp program where the first six weeks I don’t know if it’s changed since then, but back then it was the first six weeks. You go work on a little bit of everything so you are given; a front end task, a back end task, an infrastructure task, a mobile task and all over the stack.
One of the things that I had to work on was the embeddable comments widget that you see on TechCrunch and other blogs that you can put Facebook comments in there. The task was like send a notification to the blog owner when somebody makes a comment and there was some condition associated with it. I wrote the code, got the code code reviewed the tests pass and it rolls out on a Tuesday. Then two or three hours after it rolls out TechCrunch posts this thing that’s just like, “What the hell happened to Facebook notifications.” Because this thing had a bug in it where it sent all the owners of these blogs like thousands of notifications in like a day.
Y: Ouch. It was your first bug!
P: This is like my third week on the job or something right and I’m like, “Wow my work made it into TechCrunch that’s awesome.”
Y: Congrats man that’s huge.
P: Thanks. They rolled it back there were like no permanent problems from that or anything and it’s, I think any tech company these days doesn’t hold bugs against the engineers at least the ones that people want to work for. That was a super positive experience; I ended up really liking the idea of working on user facing products. I ended up joining the Facebook video team and that was one person so I was the second person on that, the first person moved on so I was like the Facebook videos team.
Y: The Facebook video man.
P: Yeah basically.
Y: Wait, one person? So this is like way before videos is even a thing on Facebook.
P: This was like, you know we were talking about React Native before we started recording and Charlie Cheever started Expo. Two years before I joined Facebook his hackathon project was, “Hey you should be able to upload videos to Facebook.”
Y: Duh!
P: Yeah, right? I think it became like the number three most popular video site in the world or something. It was this hackathon project that was barely maintained, so I was like the one guy at the company that was maintaining this thing. This was back before Facebook Live was a priority or any of that stuff.
Y: He had built, so Charlie had built the first version of videos and then you were tasked with taking that on.
P: There were a couple of people that had hacked on it but I saw his name all over the codebase. There were a couple of other kind of old timers that had built that. It was one of these things that was, it was like a hackathon project and it was never a strategic priority while I was there so I was just like the one person that was keeping the lights on making sure that everything was working.
It was the third largest video site in the world or something. They put this like… 23 year old kid who sends thousands of notifications to blog owners to like maintain this thing.
It was cool, I don’t know if it was a good idea but it was cool.
Y: Did you make any like, any big bugs make it into the video product?
P: It was like … I was really into Python in college that was a pretty cool – While I was in college again like Ruby on Rails had just become popular, so python was kind of riding that wave too. I was really excited about Python and kind of looked down on PHP programmers. During my tenure on Facebook video I took all the Python code that they had written and ported it into PHP because we wanted one codebase in one language. It was kind of just like …
Y: We as in yeah, like everybody like as part of engineering wanted it. Did you want that or were you just like, “Oh man?”
P: I mean back then I didn’t have the experience I have now so I was like, “Python is cool and PHP is for losers.”
Like I appreciated having one language but I didn’t realize that for all intents and purposes it didn’t matter what language you use.
Y: Got you. At that point Hack/HHVM all that was already a thing right?
P: That was when HPHP had just finished, so they had just rolled out the last web servers on HPHP which basically takes regular old PHP and compiled it to C++. If you are familiar with all these transpilers in the JavaScript world, well it’s all the same thing, but server side you transpile from PHP to C++. The guy who wrote that saved the company some ridiculous amount of money.
I mean just making single digit percentage points gains in efficiency at that scale is a big deal.
Y: For sure, wow interesting. So, video was like your big project and then did you go directly into photos or how did photos come into the mix?
P: So, because it was a team of one it was kind of org’d or it was org’d under the photos team. We had the photos and videos team, I worked on video and almost exclusively video and then my manager managed me and then the four people or five people working on photos. Again, largest photo sharing site in the world had like four or five people working on it.
Y: How many people were at the company at this point?
P: I think it was under 2,000. Facebook engineering was I want to say like 600 people. Remember, a lot of that went into infrastructure, this was, Facebook was started before the cloud was a thing so they had to run their own data centers and do all that stuff. That’s, a lot of the headcount was tied up in various infrastructure related stuff.
Y: That would be a good thing to focus on, cloud...
P: Yeah.
Y: I was just thinking like what would Facebook’s engineering, what would that have looked like had the cloud already been a thing?
P: Yeah, it’s really interesting. The …
Y: We could probably spend like hours talking about that but yeah.
P: Hey if you want to make two podcasts today, I’m into it.
One thing, I don’t know if this is just something I read in a blog post somewhere or if this is like common knowledge. Some people say that the Facebook’s and Google’s of the world are like five years ahead of open source and companies that can’t throw zillions of dollars at engineers. When I joined I remember this vividly I think it was 2011 or maybe 2012 I gave this tech talk on this thing called Tupperware and it was using this thing called Linux Containers. I didn’t really understand what that was because I wasn’t super knowledgeable about the actual kind of devops side of things. That’s basically Facebook’s version of Docker and this was back in 2011. They had built that and Google I know had their own containerized thing that they had.
Then Docker came out I think it was 2013 is when it started getting really popular, 2014. I think that one change that would happen today is that rather than invent your own container orchestration they would just use Docker and probably something like Kubernetes.
Y: Got you yeah, no that seems like an obvious one. I think it was Heroku who had also been using Linux Containers and the obvious choice would have been Docker in orchestration there. But, yeah that’s interesting, do you think that … Out of the 600, I guess we can use that as a proxy, out of the 600 engineers how many would you say at that point were working on infrastructure versus application code?
P: Oh man that’s a hard question.
Y: Ballpark. I mean one person on video, I mean that’s kind of crazy.
P: Remember though at the time there was a whole effort for Timeline, so Timeline was like the big, one of the couple of big projects that was going on.
Y: Timeline, I remember Timeline yeah.
P: That sucked up a lot of talent on the front end engineering side. You are building this infinitely scrolling timeline user interface that’s got to work in IE6 or something that takes a lot of resources. On the infrastructure side you need to have a back end that lets people skip from the current year to what they did five years ago. A lot of times you’d put that data more in a cold storage and how do you deliver a user experience that lets you load that fast enough. I would just, I’m just making up a number here but I would say it felt like two thirds of the company was infrastructure and one third of the company, or of engineering, was front end or product.
Y: Now that’s huge right because then that could have gone, that could have flipped the other way like one third to infrastructure let’s say if the cloud had already been a thing and you guys weren’t building out your data center. That could probably be a whole separate podcast but it’s so interesting, so the photos team, I guess we can probably get into the React stuff now. Photos - what was that like; were there any like big challenges that you can remember when you were first getting ramped up in video and photos that you remember?
P: Yeah. I joined to work on video and it was kind of in maintenance mode and so one of the problems that video had was every Sunday morning the encode queue would get backed up and I would get paged and I would have to restart the encode servers. We fixed that by again like throwing out a bunch of Python code and rewriting it in PHP and the nature of the company at the time was like people would change teams really often. They would actually try to get you to change teams after a year to try to spread knowledge around the company or something.
The photos team started to turnover and I interfaced with them a lot so I ended up having to pick up the slack on some of the photos tasks. Before I really knew what was happening I was the longest tenured person on the photos team and it happened really quickly.
Back then … There was a couple of things going on; there was Timeline that was going on and that timeline involved a bunch of search and stuff like that. Another big thing that was going on was the shift to mobile, so I joined and then it was a couple of months after I joined, Zuck gets everybody together and is like, “Hey mobile is going to be a big deal and we are dropping everything and moving tons and tons of resources to mobile.” A lot of people were pulled off of the web teams and put on mobile, which pissed me off because I didn’t have an appreciation. I didn’t have a smartphone, so I didn’t have like an appreciation for mobile. This was like 2011; you know what I had just gotten my first smartphone, that’s what it was, when I graduated.
I was like, “We can’t maintain the largest photo site in the world with a handful of people, this is crazy guys. We’re putting all these people into iOS and Android for apps that make up a minuscule amount of our traffic this doesn’t make any sense.” Turns out that it was 100% the right thing to do, that’s why I was not CEO of Facebook.
Y: Yeah it was a good bet.
P: Yeah it was definitely a good bet. The kind of people that had been around for a while were being pulled on the mobile teams, which created opportunities for the less tenured people at Facebook to step up and own products and own pieces of the infrastructure. So that by the time we acquired Instagram they were like, “Hey we need a senior-ish person on the photos team to go over there and build out their web stuff, integrate them, help them get integrated into Facebook engineering. Kind of welcome them and plug them into the right stuff.” I was one of the people that was, I was the first one to go full time over there to Instagram when that happened.
Y: Got you okay. What was that like? You read about it then you were like, “Whoa this is cool,” or what were you thinking at the time?
P: Well, you know again we had, I was on Facebook photos we had this big initiative to move to mobile. We had this app that we built and we were really proud of called Facebook Camera. It was …
Y: I don’t even remember that.
P: Yeah that’s this, that comes into the story. We worked really hard on it, I wasn’t working directly on it, I was supporting it from the server side but we had a bunch of really talented engineers working on it and tons of designers. Instagram just came in and ate its lunch.
Y: Wait I do remember that app, it was all photos and then you were supposed to like stuff but the whole screen was the photo or something.
P: Yeah and we went back and forth in that design decision for a long time.
Y: Yeah I do remember that.
P: Yeah so we launched that app. My read of the situation, again I don’t remember everything 100% accurately or anything, but we spent a really long time trying to figure out the exact gestures that we were going to do and all sorts of really, really nuanced UI things. The Facebook ethos at the time was unashamedly move fast and break things and I was like, “Guys this is not move fast and break things. This is like pause, pause, pause and miss the market.” That may or may not explain what happened, it kind of felt like it was ready to launch for a long time it just was people couldn’t agree that the design was right. Anyway it did launch, Instagram made its launch. We considered them like these fierce competitors and like, you can see my first photo on my current Instagram account is when I worked at Facebook and took a photo of my desk trying to figure out why do people like this app? I’m trying to figure out, all that kind of stuff.
Y: Right, you still weren’t convinced that mobile was the future?
P: Yeah, I’m still trying to figure it out you know?
Then one day we get this or one evening we got this email it’s like, “Hey guys come in early to work tomorrow we got a big announcement.” Then we come in early and he is like, “Yeah you know in an hour they’re going to report that we acquired Instagram and they are coming in this afternoon and go shake their hands.” I was like whoa like.
Y: All six of them.
P: Yeah. Like they are our sworn enemies and now we’ve got to be friends with them... great.
Y: Right. Yeah it was like six people though right?
P: It was 14 I think.
Y: Oops.
P: No, it was actually, but depending on whether you count when they announced the acquisition or when it actually closed because they hired people in between those two.
Y: Got you, okay interesting. 14 people walked into the office.
P: Yeah, I think it was like 14 people. There is a photo somewhere that I could go and count the people.
Y: Yeah I’m sure. Okay, so then at some level you must have been like, “Oh well this is good now we have like a way to do photos and we don’t need to spend weeks figuring out gestures and stuff.”
P: I don’t know I liked …
Y: You liked Facebook Camera?
P: Well I wouldn’t say I liked Facebook Camera. I wanted, I bled the blue and I wanted our company to win and it didn’t feel like we won...turns out we did.
Y: Yeah, that’s a huge W right there.
P: It was a little weird when they showed up for me anyway and then they worked … What was cool is I think that some of the really successful tech acquisitions that have happened - think like YouTube and Instagram - those are the two that stick out for me. You kind of leave them alone, you say, “Hey we’ve got all these resources, take advantage of the resources you want but we’re not going to tell you how to run your product.”
With Instagram they gave them a garage in the Facebook campus where they could just do their own thing. They took advantage of the Facebook kind of trusted safety systems, but other than that, they continued to use AWS, they continued to draft their own product strategy from what I could tell. It was really interesting how hands-off it appeared at least. I wasn’t in the conversations with Mark or the executive team or anything, but as kind of an engineer, it seemed like they just could do what they wanted.
Y: Then how did the transition happen when you got pulled on to Instagram?
P: They needed a web presence.
Y: They had no website at the time.?
P: They had photo pages and the web was a bit of a strategic thing for them, so they were mobile first, Instagram has always been mobile first. Instagram actually, a lot of the content is public and, I think SEO was an important thing for them...
Y: Really?
P: Yeah, you search for like Justin Bieber you want the Instagram link to be up at the top right?
Y: Yeah. Yeah.
P: I think that was the strategic reason why.
Y: Yeah I can see the head of Instagram saying, “Look desktop is going to be a big thing let’s go after it.”
P: That’s what was weird because it flipped.
Y: Yeah exactly.
P: Everything went mobile first and then we would think about like, “Okay what’s the desktop angle or the mobile web angle.” SEO was kind of a justification I think for what we were doing, so my main …
Y: You were the guy. You were the desktop photos guy.
P: That’s right so my manager was like, “Hey you’ve been around the team for a while - you interested in making the change? We are spinning up this new team on the Instagram side to build out all the Instagram web stuff,” and he was like, “You should go,” and I was like, “All right, I’ll do it. I’m on that.”
Y: Nice all right.
P: That was being, I was the first full time engineer to go over to Instagram. From the Facebook side.
I was like the corporate drone being dropped into a new startup... the corporate drone from like Facebook, right?
No they didn’t make, it’s not like they made me feel that way or anything. They were all super nice and cool, they did things very differently than Facebook so, code review was largely optional. They did continuous deployment which I thought was totally crazy, Facebook would deploy on Tuesdays at 2 p.m. and if you didn’t get your changes in they weren’t going out that week.
Y: Okay so yeah it was a startup essentially, they were still just operating as kind of like a startup.
P: They were using AWS and all the cloud computing stuff that you are used to, they were using Django rather than the Facebook home built … At that point it was like a home built framework and a home built language at Facebook scale and on Instagram it’s all off the shelf Django run on AWS talking to Postgres, pretty different software stack.
Y: It’s funny because that’s of the perfect representation of what has happened in the past few years and the reason that StackShare even exists is, these days you're not building all that stuff for yourself. You are not rolling your own framework so that’s the perfect example.
P: Yeah I mean our company we started two and a half years ago, we process a lot of data, like hundreds of millions monthly actives type of data and it’s event data too so the volume is really high. We have four people working full time on infrastructure. It’s crazy.
Y: It’s like the opposite.
P: Yeah, yeah, yeah, it’s pretty cool all the technology that’s come out recently that lets you just manage all that. But anyway...
Y: That’s awesome though, so you get into the Instagram world; everyone is deploying code, slinging code to production, no code reviews...interesting.
P: They had some code review but it was optional. There were a couple of people, I remember there being like three engineers that knew how everything worked and they could just roll out anything they wanted and it was totally fine. The newer guys like me, we would want our code to be reviewed, we didn’t want to take down the site. One thing that they did have it was basically like everything was really, really well tested so if the tests were green you were okay to roll out and the tests were really, really thorough.
Y: Man so interesting, I definitely want to hear about this stack, but let’s try to keep it focused. When you got there, there was no front end framework being used?
P: So let’s rewind for a second. We had to build this, what we thought were going to be a pretty comprehensive set of web apps. Like we were going to start with profile pages and photo pages and then we were going to build hash tag pages, maps like geographic search and stuff like that, all for the Instagram web.
Y: What existed is the single photos, the single photo pages?
P: Yeah, there was a photo page and then there was instagram.com which was like a billboard for the app. That’s all that they had.
Y: Got you yeah, I remember that actually, but you could only see a photo.
P: Yeah and you couldn’t see all the photos somebody has uploaded or anything. We wanted to fix that but we had this problem where if you are, this goes back into the stack, but we had these application servers that were Django and we had these database servers which were Postgres and Postgres can only support a certain number of connections. The constraint was – and we were at that max limit - the constraint was we can’t add any more load to the servers, and creating a bunch, serving a bunch of dynamic web pages actually does add a bunch of load to the servers, especially when it’s going to be exposed in the public web. We decided we had to do client rendering.
Y: What about caching?
P: They were really good about caching and I don’t actually know if, like looking back on this the way I would have done it now is be like, “Hey we are going to server render it and we are just going to cache it.” I don’t actually remember if there were other reasons why we decided that we had to client render it. I remember I was basically told like, “Hey I think we need to client render this.” There was a prototype that was going on that was client rendered so we decided to go … Oh yeah, because eventually we were thinking those pages would be personalized, so if you are logged in, you look at the same profile page it looks different to both for us. Which is like Facebook for example... you can’t cache any full page because everybody’s page is personalized.
Y: Okay so you were doing it with that in mind?
P: That’s what it was.
Y: Okay got you. You needed to client render and none of that was, had been rolled out or anything at that point?
P: We had no client rendering. It was a small prototype of jQuery-Mustache templates which was kind of the, the designer had hacked something up with a certain engineer over there and they were like, “Hey you know this is a prototype. Hey Facebook engineer, go like production-ize this and get it rolled out.”
Y: Facebook drone, execute!
P: No. They were super cool, I love those guys. We had to client render; I actually didn’t know JavaScript at the time.
Y: Wow.
P: Facebook largely doesn’t, they don’t want engineers to write JavaScript because it adds to the download, so it increases … It’s more CPU utilization and it’s another language to learn, it’s more code to download, it’s more work, so there is a little bit of JavaScript that’s reused all over the place on Facebook. I kind of knew JavaScript but not really. I went to the front end engineering team at Facebook called UIE. User Interface Engineering, I was like, “Hey we need a JavaScript framework what should we use?”
They were like, “Well we’ve got these three or four experimental things that we have baking right now. We have BoltJS, we have JS HTML and then we have this React thing.” There were pilot projects for all of them, there might have been something else too but … because I remember I think Facebook had acquired the WebOS guys and they were really good and they had built something. We had a mobile web framework called Javelin so there was a bunch of different options. I took a look at all of them and I talked to the people working on them and decided to try out React and so-.
Y: What drove you to do that? What about the other options did you just like the name or?
P: So everyone has got their “hello world” and if you’ve worked on other ways of rendering client side apps before and then you see React, it’s like almost too good to be true. You are like, “How does that work? There is no way that that works and if it works it must be really slow.” It took me, like Jordan worked with me a lot and he had written a lot of really interesting hello world, not hello world but like quick starts for various types of things. We had prototyped the profile page in React and it was a pretty positive experience, the end result was really positive. It was fast, it worked really well, didn’t have too many bugs because it’s getting rid of all the mutable state is a good thing. We launched it and it was really successful.
Y: Which profile page?
P: The Instagram profile page.
Y: Okay so a user’s profile page. You basically, okay whoa that’s quick. You saw React you were like, “This looks really cool,” and then you just started to build out the profile page with that.
P: Yeah, but there is a lot of blood, sweat, and tears in between like let’s try React, and let’s put something into production.
Y: Okay all right cool, let’s talk about that because that sounds pretty quick it’s like, “Oh this seems cool...BOOM , it’s live for everyone.”
P: I think if there is one, like reflecting on this, if there is one big theme it’s that Instagram was kind of the future in terms of tech stacks at least relative to Facebook, and I was bridging the Facebook world and the Instagram world. I saw that Facebook is five years in the future in one direction and Instagram is in the present but kind of in a slightly different direction.
There is some things that Facebook did really, really well and better than anybody else, there were other things that they would have just used a cloud service for.
A good example was all the Facebook JavaScript, React included, was packaged using their homegrown bundler which was really, really advanced it used some machine learning or statistical thing that looks at the logs of people downloading individual modules and the dependency graph and will do an optimization on what modules are we going to bundle together and what are you going to have to download up front versus lazily and all sorts of stuff.
Written by this PhD, super super crazy, it’s awesome, it’s better than Webpack, it’s better than anything that’s out in open source still, but it’s very, very much tied to Facebook’s infrastructure. The module system - we had these comments in the JavaScript that was @ require and the module name and it would show up as a magical global - so we had to take that and somehow bring the React dependency into Instagram. The first thing I did was I wrote a Python script that would translate that weird syntax; it was a bunch of just gnarly regular expressions to RequireJS. I don’t know if you guys remember RequireJS?
AMD modules, so we did that. That was enough I think to get us to production, so I ran the script once, committed the generated code to git and then we set up a little RequireJS integration with Django and then we shipped it. As we started to pull over, build more products, we wanted to use analytics so we wanted to use Facebook's analytics stack so we had to pull over more of those modules and then that script got bigger and bigger and bigger and bigger.
Eventually I moved to management and I got a team of three or four engineers that were helping to build out all this stuff, and we wanted to build this whole suite of business products. By this point we were pretty happy with React and we knew that, we were going to go all in on it and we …
Y: You are talking about Instagram?
P: I’m talking about Instagram, yeah.
Y: Interesting yeah. In terms of where React was, you basically got it ready, you brought it into the Instagram environment or codebase and then you shipped it?
P: We shipped the profiles product, then we shipped - that went over pretty well - then we shipped a News Feed product so you can log in, see a feed, paginate. It had this one really cool subtle feature that I’m still really proud of where if you went somewhere and then clicked the back button it would cache where you were in the feed in the history API and it would also cache the data that you had downloaded. So it would bring you right back to where it was, which is super annoying if you ever use a product that doesn’t do that.
Y: Facebook mobile... yeah, it’s super annoying but that’s awesome. For that initial launch it sounds like that went really well, you guys were happy with React. Was that an “aha moment” for you or were you just like, “Oh this is cool let’s continue to use it,” or did you have some inkling like, “Oh man this is going to be pretty big if we can continue to build out with React.”
P: There was a couple of things going on; the first was I thought the development experience was awesome. It was pretty different from how it looks today. Lee Byron came in a couple of months after we had shipped the first, the profile pages and he was like, “This API is unintelligible for the lifecycle hooks let’s,” -- because we had different hooks, totally different names for every lifecycle hook. We had some they called like “prop trigger” and another thing called like “on state changed” and another they were kind of like ad hoc names-- so he is the guy who came up with “component did mount, “component will mount” he kind of cribbed it from how iOS does things. It was totally a team effort and I cleaned up a lot of the API too and fixed some performance stuff and did all the packaging for Instagram then we just went and reused a lot of that for open source.
Y: So, in terms of the evolution it sounds like that was the proof of concept, “Okay this works.” By the way how many users were there on Instagram at that point?
P: I forget, but I mean tens of millions at least.
Y: Okay, so you knew it worked well at scale in a sense, and then from there did you start building everything else out immediately in React?
P: If you look at it from the React point of view there were a couple of things going on. Yeah we were like this works great and then I get another PSD from our designer for a newsfeed and they are like, “Go build that.” Like, “All right got to go back to work and build that,” didn’t really reflect too much on the framework. I thought the framework was super super kick ass, I thought that it was really, really innovative, it was doing things in a way that had never been done before and I wanted to be a part of it. So I started contributing back to the code, the Facebook side code base just kind of in my spare time. As we would roll out new products I would fix bugs and clean up the API, write docs, whatever.
Y: On Instagram.
P: On Instagram but those would make it back into React core.
Y: It was open source from day one?
P: No, this was all …You can think of Facebook internally open sourcing React to Instagram.
There were the source of truth modules in the Facebook codebase and then we would periodically, we would just pick a git commit and then we would export it into Instagram when we wanted to take advantage of a new feature or something. It was always actually really painful to do that, because I had again this hacky script that would translate it to RequireJS and like maybe it broke or something and you’ve got to fix that and then you’ve got to, we didn’t have a lot of stability back then.
Y: It’s not like you are forking it right, you didn’t fork react the core.
P: No, it was when we made changes it was always to the Facebook source of truth and then we would export that.
Y: Okay all right, so you were committing directly to the core repo?
P: That’s right yeah.
Y: Got you interesting. You were making these changes okay basically it happened incrementally now you had to build the News Feed so obviously you are going to use React. Then what came after News Feed do you remember?
P: Then Facebook ads had to do client rendering too, they were rebuilding some critical ads product and they were looking, they were doing the same thing that I did a couple of months prior which was BoltJS, whatever their options were in React.
Y: By the way was Angular ever a thought?
P: No, not even close.
Y: When you guys were thinking about this it was always, “Let’s look at what’s already being used in the Facebook ecosystem or has been created inside of Facebook.”
P: It’s less about, I mean there is a little bit of NIH there, but there is good reason for it. Templates were never on the table. So a long time ago on the PHP side of the house they had this thing called XHP which is open source but nobody uses it. Where rather than having what passes for a template in PHP world, you build what’s called XHP elements which are components. They use this similar syntax to JSX, they have similar kind of lifecycles for loading data and server side they just spit out a string of HTML rather than DOM elements.
We were like this is definitely the right way to build applications it wasn’t even up for debate.
All those the BoltJS and all these other things you build the apps in similar ways and components. What made React unique was how the components re-rendered, the other ones there would have been an initial render and then you would have to manually like update the DOM.
That’s what I thought was, that’s what blew my mind. I like didn’t understand how that was possible.
Now we have a really crisp explanation of this like, think of it as a Virtual DOM and you do a diff and the diff is fast. That was a really big pill to swallow back then. Remember we were pushing products on IE7 and 8 back then, so having that be fast enough I was like, “Yeah right.”
Y: Right...wow that’s so interesting. It sounds like it was super organic and sorry you were saying the ads team was looking around at BoltJS and then they found React.
P: Yeah and the ads team is some of the strongest front end engineers out there and they came to me and they were like, “Hey how was your experience building with React,” and I told them. I said, “Hey I’m a huge fan I don’t want to use any other framework other than this thing.”
What they did is they did some benchmarks. The UIE team internally had also done some benchmarks too and basically we all came to the same conclusion that was like, “Hey we all clearly obviously love the programming model and it turns out like it’s most likely going to be fast enough for the types of problems that we want to solve.”
Y: It’s going to be fast enough not necessarily it’s going to be faster?
P: Yeah fast enough. One of the big observations that I didn’t really appreciate until building something with React was usually it’s only a tiny percentage of your app that re-renders so the diffs normally aren’t actually that big. In the cases that the diffs are really big the alternative approach is to use data binding and the building up and tearing down of all those change listeners is really, really expensive. React in a lot of ways optimizes just for the initial render and sometimes at the expense of the incremental updates, because the incremental updates are pretty rare and pretty small.
Y: Got you, okay interesting. From the ad side of things why did they want to take on React? Were they experiencing issues... what were they using prior to that?
P: Have you ever created an ad on Facebook?
Y: Yes, once.
P: It’s pretty hardcore. You are pulling in all these different demographic groups, they are spending money so you have to understand what locale a person is in. Yeah like if you are creating an ad in Israel like it’s got to work left or right or right to left. You want the preview of the ad unit to exactly match the actual ad unit, so you need a way to render it with the same code, but make it editable and a couple of edge cases when you are creating the ad versus rendering the ad. It’s got to be fast. If the button doesn’t save your change like you are going to spend money on something that isn’t what you wanted to buy, so it’s a very stressful thing to work on.
The guy that actually originally came up with idea for React, Jordan Walke, came from the ads team. He was like, "making a change on this product is terrifying, like potentially lose a day of revenue because you’ve missed a semicolon or something."
He had felt the ads pain and then he convinced - I don’t know how he did this - but he convinced them after building this thing on nights and weekends to work on it full time for a little while. As he was working on this framework full time he built a type ahead component and had rolled that out I think in maybe a little News Feed unit but never a full application. Instagram was like the first full application.
Y: I was about to say so was React already being used at some level by ads or did they never...
P: It wasn’t used by ads it was used a little tiny bit on News Feed. It was like 1% of News Feed users were getting this experiment that was the client-rendered comment box.
Y: Client rendered comment box okay so that was after Instagram or before?
P: That happened just before Instagram. We knew like it will work on like IE7 or whatever it was that supported it back then. We knew that it would work we just didn’t know that it would work at the scale of a full page, with like a router and data fetching and all that stuff.
Y: Got you. So basically React the inception was because of ads by Jordan so he built it as a side project they started to experiment with it in News Feed to client render comments for 1% or whatever of users, right? Then you basically saw that and said, “Looks good let’s start using it for Instagram profiles,” and then everything else just started happening?
P: Then Ads says, “Worked on that News Feed thing, worked on the Instagram thing, we’ll try it on ads.” Mobile search said, “Hey it worked on that News Feed thing, it worked on that Instagram thing and I hear that ads is going to try it,” and then they keep going. They kicked off something concurrently as well, so it really did kind of grow organically and it’s like everybody that used it got really passionate about it and excited about it and just started spreading it.
Y: Like wild fire.
P: Yeah and it got to a point where, what’s called the product infrastructure team at Facebook which owns a lot of developer abstraction and stuff like that was like, “Guys, you are writing too much JavaScript. We know that React is really fun but you can use PHP once in a while to render this thing.”
Y: That’s hilarious, they probably saw like a graph of JavaScript entering the code base.
P: Yeah, you know like, “This has gone up way too fast; do you really need all of this JavaScript?”
Y: Got you, interesting okay. It was largely organic and then, but that’s a big bet to make on ads, because ads is the life blood of the entire company. I’m guessing they started with like 1% of 1% of ads and then just like looked at benchmarks and then eventually more and more ads.
P: Yeah. Once that had happened, it was basically like the de facto way to build apps in JavaScript at Facebook.
Like if you can prove it on ads and you can prove it ... It’s like if you can prove it on ads, then you’ve proven it across all the heavy weight UIs and then there is a second question which is like; is this thing going to work on mobile and we had benchmarks to prove that as far as JavaScript goes React is going to be fine on mobile. The greater question for Facebook was; how much client rendering do we want to do?
Y: Yeah, okay so on the Instagram side because it sounds like Instagram is still the biggest user of React? Is that fair to say? Or once ads took over that was it?
P: I would say the ads codebase was probably bigger.
Y: Then they became like the biggest user of React before Instagram became all React everything?
P: Instagram was first. Instagram was all React but the surface area of the Instagram product is smaller than ads. We don’t deal with too much internationalization stuff or localization stuff. Like yeah we have to translate the strings, but we don’t need to know about different currencies. We don’t have to preview components within the components and stuff like that.
Y: Got you.
P: We had to deal with like performance, our biggest challenges were what does a React Router look like; so we built the first three React Routers ever. What does data fetching look like? Originally we were a React app that was plugged into Backbone and Backbone was doing all the data management on this. Yeah, that was actually the first profile page. The first profile pages were powered by Backbone.
Y: Wait, how did Backbone get there?
P: That prototype was Mustache, jQuery and I forgot to say Backbone.
We're like, “Man we got to ship this thing,” so hack a script to like pull React in. We replaced the templates with the React components. We shipped it, we were like, “Well, that’s pretty good,” and then Jordan was like, “You know you don’t really need Backbone, it’ll be a lot faster and better if you don’t use Backbone.” Then we built the feed without Backbone and then we started to remove Backbone from the codebase.
Y: Got you. Then when did you run into basically state management and then need to actually build something for that or was that never, when did Redux and some of that stuff come into play?
P: Yeah, state management... you got to think about it you know the second your app does anything interesting, anything changes in the UI. I was kind of like whenever I would face one of these problems, I would go to Jordan and I would be like, “Hey how should I solve this,” and then he would give me an answer and I would actually put it, like turn that into code and try to push that into production and be like, “Hey that doesn’t actually work like we got to make this changes, this change this, change the code base.” It was great because like he was kind of coming at it from the theoretical like this is how I think it should be, like drawing the state machine diagrams and stuff like that. I was hacking the shit out and actually trying to push to product.
Yeah, at that point I didn’t need code review anymore in the JavaScript stuff. I was the guy that could do that stuff.
Y: Yeah, got you. Right, you had to deal with that early on?
P: Yeah, what ends up happening is you get like one controller component that has the state for 90% of the page and then you tediously kind of pass these props down all the way down to the bottom of your app. And we actually got pretty far with that, I think most people bail out too early on that approach because that approach has a lot of benefits. Like yeah it’s a lot more typing but you also know exactly what data your component is using and you know when it’s going to change and it’s really easy to debug.
On the flip side it’s a lot of typing and then sometimes your interface to your component doesn’t make a lot of sense. If you want to render the badge of the current user somewhere you’ve got to go look at your component hierarchy and pass the user all the way down which isn’t fun. So for Instagram we just powered through it, we didn’t use any sort of state management thing.
Y: Okay got you.
P: Ads used Flux, the original Flux from the beginning.
Y: OG Flux, okay.
P: Yeah, the OG Flux.
Y: Actually OG means something different on Facebook but …
P: Yeah, the open graph tags.
Y: That’s funny, so you guys didn’t use any of that but ads needed it and they were just like, the way to go was to have something, something separate. Did they create Flux?
P: Sorry, Flux predates React, a lot of people don’t know that.
Flux came from the Facebook chat team. So the chat bar on Facebook and you type a message and you got to sync, there is like a little … The example they always use is that there is a little unread message count in the top bar and there is an unread message count in the bottom bar and you got to keep those in sync. It gets a little more hardcore because if you have multiple browser windows open you want to keep those in sync and …
Yeah, so Flux was already there and basically the approach a lot of teams took was, “Hey we are already using Flux we’re just going to swap out our manual DOM manipulation with React,” and that ended up working like pretty okay.
Y: Right and then that became the standard- React and Flux?
P: Yeah. It’s like people kept asking the question in open source like, “How do I deal with this problem?” I said, “Hey we have this thing called Flux it’s what we use, it wasn’t really designed for React but it works well enough.” That’s why you don’t often see people using the vanilla Facebook Flux Implementation, because it wasn’t really designed for React.
Y: Right and is that one of the reasons that someone who was it, Dan, that created Redux?
P: Yeah he wanted, he took … The main motivation was he wanted to do hot module reloading with Flux so you got this hot module reloading basically says, “Hey, you make a change, you save it. Then we're able to pause the state of the application load in the new code and resume and then re-render the page. It’s almost as you are typing and saving, your changes are showing up in real time. The problem is your state is stored in some variable somewhere and you have to get a reference to it and retain that. Swap out the old code swap in the new code and then put that reference back into the code.
Redux was like, “Hey, how do I just make Flux work with this hot module reloading thing?” Then I think what happened is he just got a little carried away and ended up throwing out a lot of the bad ideas and bringing in a lot of good ideas and ended up with Redux.
Y: Got you, but Instagram wasn’t using either of those.
P: No.
Y: Okay, got you. Good stuff. When did the open source piece come into play and how did that decision even come about?
P: Yeah, I remember this because... I was super excited about React, there were other people at Facebook they were super excited. Like some of the names that you know now like Chris Chedeau, Tim Young, Jordan obviously, Sebastian and then they were some people internally that you don’t really remember. Like Michael Lowman’s was a designer on Instagram and he designed the original website and the logo that’s still used today. There are some other Instagram people that were involved a little behind the scenes.
We were all really excited about it. I actually was talking with a startup about a CTO gig. Like leaving Facebook and being their CTO and they had millions of dollars in revenue and it was kind of enticing and I actually told them I was like, “Okay like I want to open source React, like hold off for like six months, I just want to do this thing.” I was, I’m saying that not to say how awesome I am, I’m saying that to say how excited I was.
That would have been a huge step up for me career wise. I was like, “No, I’m strapping myself to this React Rocket ship.”
Y: React is the future.
P: Yeah, we felt really, really passionate about it. Especially because remember this thing had been baked off by some of the best engineers I know against a bunch of competing solutions and we knew for a fact templates were the wrong way to do things. We knew for a fact that this Virtual DOM diffing thing which is kind of what we called it did work in the majority of cases that we tried it. For the ones that it didn’t there were escape patches that let you build 90% of your app with React and then 10% without.
Y: How did the idea to open source even happen or come about? Were you just like, “Yeah, we need to release this and let everybody start using it,” or was it kind of just this standard like once you have something that works really well across products you start to think about open sourcing it?
P: We all kind of wanted to do it. I think there was some stuff going on back then that I wasn’t plugged into. I think that James Pearce was hired around then and I know that Tom Occhino was the kind of the main business driver behind a lot of this and Adam Wolf. I think Tom reported to Adam and Adam was a big advocate for this.
If you go back to that time, it was January 2013 or something like that, people hated Facebook, I mean the way that people talk about Uber today is like how people talked about Facebook. Just publicly, Social Network was still wearing off, the movie, and in the developer community Facebook IPO tanked if you remember that. I was around for that too.
So Facebook’s open source portfolio was like a bunch of projects they had thrown over the wall and abandoned. Famously there was this iOS library called Three20 that every iOS developer hated Facebook because they depended on this thing and then Facebook just stopped supporting it and that pissed a lot of people off. Open source wasn’t something Facebook was very good at, but I think when they hired James Pearce I think that happened at this time they were actively looking to reboot that. There also happened to be independent of that like a groundswell of support for open sourcing this React thing so the timing was pretty good.
We were like, “Hey, we got to get this thing out.” There was a bunch of lawyering involved that I’m not going to get into that. We got it done and then we decide to announce it at JSConf 2013, I’m not sure if you guys remember that, but Facebook sponsors, the JSConfs and in exchange they get like a keynote spot or something. There is some sort of arrangement like that that happened. Already the sponsor keynote spots people are like a little “meh” about, the audience is kind of like, “The sponsor gets to speak to us... like... great.”
Y: Yeah Facebook.
P: Yeah, also Facebook this evil mega corp that ruined open source and blah, blah, blah they’re speaking at JSConf. Then so Facebook goes up, Tom O. goes up and he is a really charismatic guy and he goes up with Jordan, who is the smartest engineer I have ever met. They are like, “Hey, we have a new way of building web applications. Everything that you are doing is wrong and here is how we do it.” At least that’s how it was interpreted and it’s like step one put XML in your JavaScript, inside your JavaScript it will be totally fine.” People were like XML whoa I hate XML and then they were like, “I thought I was supposed to separate my mark up from my JavaScript, from my styling and you are telling me to put all of that stuff into one file... I think this is too much.”
When he was doing the keynote and was announcing it and it’s called React, we pressed okay on the deploy button and we deployed the GitHub repo or we opened up the GitHub repo.
We were really excited back at Facebook because we had been writing documentation, getting it ready and it was early morning for us because we were on the West Coast and the tweets started to roll in that were all like, “Facebook is terrible, this is the worst idea I have ever seen.”
Y: They just told me to throw out all my front end code.
P: Yeah, well it wasn’t even that it’s like they don’t … It wasn’t even like, “Man, I have to throw out my code,” it’s like, “These guys are dumb, Facebook is stupid. Like they have been in their own little world for too long and they don’t know what they are doing and blah, blah, blah,” it was like sort of a bummer.
Y: It’s safe to say people were not excited.
P: No, they were excited to hate it and I believe that was the last conference that Jordan spoke at.
Y: That’s like, that’s a ballsy move though, if you are going to launch a brand new framework when you do it at a conference where there is not a whole lot of anticipation that you are going to announce something big, so that’s huge. I mean hats off to you guys and the team right? That takes a lot of courage and you never know how people are going to React.
P: I see what you did there. I was chalking it up to ignorance we were just like oh yeah people obviously understand that templates suck. Like components are clearly the way to do things and we know that everybody has felt the pain of having the separate mark up from your JavaScript driving it. We were like, “they’ll love this” and we didn’t realize that like that’s not how the rest of the world thought.
Y: Yeah, that’s not how the real world works outside of the Facebook walls. So there wasn’t any real evidence that other companies or anyone else was going to use it right? It was just you guys saying, “We believe this is the future, here it is.”
P: Yeah pretty much. I felt really passionate about it being the future and remember we had already done the internal open sourcing from Facebook to Instagram and brought it into a foreign codebase. We knew that it was usable, which is a big problem with like a lot of these open source projects that are open sourced from an internal company things it’s like just completely unusable.
Y: Right that’s an important point.
P: It’s really important.
Y: It had already been used outside of ‘Facebook’ by Instagram so you had already dealt with some of those challenges. Okay, right that’s a good point.
P: Yeah, so that was hugely beneficial and we had … Remember also we had ported it to RequireJS and I think right around the time we were open sourcing it we were migrating. We evaluated all these module bundlers to be able to get away from this terrible script and we decided to go with Webpack which was pretty unknown at the time so we …
Y: I didn’t know that you guys were like one of the first Webpack users.
P: Yeah. I discovered Webpack, I’m going to take credit for that one.
Y: Nice, okay Webpack has you to thank.
P: I mean I didn’t write a single line of code or anything but it was our team actually did a big evaluation on a bunch of different bundlers. We looked at writing our own, we looked at Browserify, we looked at writing our own with browserify file components. We looked at, there was something modular.
There was Google Module Server I think was another one. There was a ton.
The code splitting is what, we needed code splitting. We are basically building out all these products and we didn’t want to have to download the profile page if we are on the photo page, because again the search engine optimization performance matters so we had to do that.
Y: Got you, okay. Webpack was being used when you open sourced React?
P: We had maybe just finished moving over. I don’t actually remember the exact timing but like Webpack came in pretty soon after the Facebook or after the React open source if I remember it correctly.
Y: Got you, okay. So what do you think was the big driver behind everyone starting to adopt it, right? And what did that adoption look like from the inside looking out?
P: Yeah, let me walk through how it got adopted. Everybody hated it at JSConf 2013.
Nobody used it and it was just kind of like a disaster. Well actually we had an IRC channel, a couple of people, if you know the Chang Lu and Ben Alpert both who now work for Facebook. They were these kind of people that stumble in the IRC and they were like, “Hey we really liked your JSConf video,” which we were like, “Really?”
Y: Thanks nobody else did, come work here!
P: No, took years. We basically, anybody at that came in the IRC I was always in there, Chedeau was always in there so we would get notifications whenever anyone would join and we would welcome them and we would answer any questions like super, super quick. The first couple of people that came in the community were up and running pretty fast because of that support. Then JSConf EU was later that year and Tom O., I was sitting next to Tom O. at the time and he was like, “I don’t want to do this stupid conference talk,” because remember his last one was so fun and I was like, “I’ll do it!” And he was like, “All right.”
Y: Nice.
P: I wrote this talk and I was like, “I’m not going to try to convince you that React is better. I’m just going to tell you why it’s different and these are the three or four things that nobody has tried before.”
Y: Good job.
P: That was a lot more; people were a lot more receptive to that. I was like, I don’t know if this is going to work. In reality we were pretty sure it was going to work but you can’t just come in and say, “Hey, we got a better solution that you should just do it this way.” You got to say, “Hey, here is the stuff that’s different,” and then you work your way to ...
Y: Just the diff yeah.
P: Yeah, exactly.
Y: Nice, okay so your talk was a hit?
P: Yeah, talk was a hit. Ended up doing a lot more talks based on kind of the success of that one. We got, we talked to David Nolen who was the guy who made ClojureScript. He had been waiting for something like this and he wrote a really kind of famous blog post called; the future of JavaScript MVCs. Where he talked about how great React was, that caused a really big step function increase in React’s popularity. Another thing that we did is that we had this wiki page of companies using React, so if any company had one tiny little project that was using React we would put their name there. This was …
Y: Got you, I think this is pre-StackShare, when was that? What year was that?
P: That was 2013 …
Y: Yeah, that was pre-StackShare
P: … maybe the beginning of 2014.
Y: Yeah, we always saw that and we are like, “Man that eventually needs to be on StackShare,” like just listing out all the customers. It’s powerful because that’s one of the first things you are evaluating is like, “Okay Facebook has used it obviously, but who else?”
P: Yeah the first question is like does it have any big users? Well, Facebook uses it. Okay, it’s like does anybody besides the authors use this because you don’t know if it works outside of Facebook use cases. That’s yeah like StackShare is obviously like a good idea like it’s been replicated on wikis how many times, yeah props to that.
Y: Yeah, absolutely. It sounds like the wiki page was like part of the strategy, the marketing. I guess let me try to run through some of these questions from the community. Some of this we’ve touched on coming back to just like philosophies. One of the questions here is; “how did functional programming influence just the whole React philosophy of state props determining output?
P: Yeah, so it’s, the way React works is very similar to how the web works; you get some data, you render a web page and you send it down the pipe and that’s conceptually how React works. This, I mean this was Jordan’s big insight and the answer is, yes, functional programming absolutely influenced React because V0 of React was written in OCaml, which is a functional programming language.
Y: Okay, interesting cool yeah. As far as React entering Facebook, we didn’t really get into that and how it like started to take on Facebook stuff outside of ads, but did it hinder or help collaboration on specific features? Do you have any insight into how it impacted the way that things were being built?
P: Yeah, when we talk about the evaluations in bake-offs, it’s not just opening the profiler and seeing what the TTI is. It’s also taking a look at how the team is executing; is it easy to reuse code, is it easy to do code review and coordinate and how stable is it? When the core makes a change do we have to throw out all of our apps or can the core team re-factor everything for us?
Y: Okay, that’s upfront part of the evaluation is like does it make this easier or harder to work together?
P: That’s right. Another thing that is often overlooked about React when you think about stability, within Facebook there are, I don’t work there anymore but when I left there were tens of thousands of React components which probably translates to hundreds of thousands of lines of code. Whenever React wants to make a breaking change, they can’t tell other people to re-factor their code. They have to re-factor those hundreds of thousands of lines of code themselves.
Y: Interesting, the React team has to do it?
P: React team has to do it all. What that means is that it has to be automatable with some sort of script and those scripts are shared with the community and that’s why you don’t get an Angular 2 scenario with React because the people paying the price are the people actually making the breaking changes.
Y: We didn’t really talk about server side rendering but do you want to touch on that? Was that after you had left?
P: No, so server side rendering was one of those things that that was really cool. When I started using React one of the reasons why I got really excited about was I would go and ask Jordan I would be like, “Hey, can React do X?” He would be like, “Yeah, like it was designed to do that. Like render client side and server side, any mobile platform natively,” I just thought that was incredible and required a lot of foresight.
The thing was when I joined, when I started working on React it’s like the server side rendering piece was more theoretical than it actually worked in practice. I had to build the API for it. Again, going back to the SEO thing we wanted to server render those photo pages so they could be crawled by Google, so I had learned NodeJS for that and built the first server rendering API. In practice at Facebook I’m not sure how much traction it has. I know that there is a lot of companies that do depend on it.
It was conceptually in React but there wasn’t … Basically what React does is it builds up a big markup string and then like puts it into the page. Well, that’s what it used to do, and there was no way of just building up that markup string. The first step was like, okay how do I get that markup string, and then I wrote an API for that and then rendered it in Node and we said “oh shit they are actually using like the window object or document dot something”. So we had to weed out all of those things, so then there was some branching in there and some abstraction, because as you add more contributors they weren’t thinking about that so we had to kind of roll back some of that stuff.
Y: If you could change one thing about React today what would it be and why?
P: Yeah, that’s a great question. There are certain things that I always wanted to do that I just never got around to doing. I’ve actually never worked on React full time, I’ve always been working on a product or managing a team that was working on a product and like half-timing on React. When we launched this JavaScript Fatigue thing it was a big deal almost instantly. Like our answer, we didn’t have, we intentionally left a lot of kind of open questions for routing and data fetching and state management and styling and accessibility and internationalization all that stuff, like we didn’t have opinions about it.
What I wanted to do was I wanted to have a React team certified badge where we say, “Hey, we are blessing this third party library and we say this is the right thing to do.” I just wanted to be very opinionated about that type of thing even if it, because the flip side of that right it’s like you might alienate somebody or you might stifle innovation in some ways and I get that and there has been a lot of innovation in the React community. I’m not saying it would have been better but that’s, I still feel like that would have been a good idea.
Go on npm and there's like 40 different React type aheads right? How many of those get accessibility right? How of those get tab behavior right? How many of those are sufficiently styleable? How many of those mutate props God forbid? I was just thinking that people can submit to the React team, then the team goes and does a quick code review, and maybe there's a checklist of what we think or we check for, locales that kind of thing. Then we say, “Yes, this type ahead is good or passes this bar,” and we never did that. I think that there was an opportunity for somebody to do that. I’m not going to do it.
Y: Well, the other way to do that is to just say what are people doing. If I was asking that question, hopefully I'll go to the Smyte page and say, “All right, what's your stack profile,” and say, “Okay, let me see everything that Pete’s using.” That’s a roundabout way to do it without a coordinated effort to say, “Well what does Pete think is good?”
P: Yeah, that’s right. If you look at kind of the, if you are trying to figure out which of one of these 20 different type ahead packages I’m going to use, a lots of times you just go on... A lot of times they are not actually on StackShare, probably it should be.
If they were I would go there but a lot of times it’s people go and look at the GitHub stars and the number of npm installs which if somebody has got a lot of Twitter followers or hits the front page of Hacker News by some roll of the dice that can throw that number off.
Y: Right, yeah. Yeah, no that’s an interesting project. Going back you would have created that from the beginning.
P: Yeah, I would have said, "We think Webpack is the one true bundler."
Y: So the future; what do you think lies ahead for React? What are some of the things you are excited about? Maybe some of the things you are not excited about? You can include React Native in that but what do you think is going to happen with React and is there anything you are excited about or not?
P: Well, Fiber just started passing all of its tests recently and that’s a really cool project. It does bring a lot of really interesting concepts so that’s really cool. I think the React VR announcement was really interesting. If you think about all the different platforms you can target with React Native or with React, there is iOS, Android, web, VR now. Somebody released a React renderer for Microsoft Word the other day. Which is not something you would normally think of.
That’s really cool because you teach these engineers how to write a little JavaScript and the basics of React and then you just give them API documentation for all these platforms and they can go and move really quickly. That’s really cool, that’s stuff that I’m really excited to see. I am sitting around waiting for the next release of the Native Windows and Mac UI toolkits because I bet they are going to look just like React. I’m waiting for the day when the only way that you build UI, the only way you can build UI is with the React paradigm.
Y: Got you. Well, I guess yeah that kind of answers the question but what do you think about Electron?
P: Man, you know I don’t know. I’ve got mixed opinions of it of like I get the program and productivity savings, but it is really heavy. We, I think that there is one thing that I would kind of change in the front end dev community in general is people use this kind of programmer or productivity savings as an excuse for, like you can justify like almost anything with that. I’m only adding five kilobytes to JavaScript or I’m only adding 50 milliseconds on this render pass, it’s not a big deal.
That’s premature optimization; guess what, optimization is premature. Like premature optimization it’s meaningless because it’s going to be repeat that 50 milliseconds 10 times and now you have half a second delay every time a component renders, right? React came on the scene and it was super, super fast because it was micro benchmarked, because it was micro optimized. Like did we have to do that event object pool thing? Probably not but nobody complained about garbage collection pauses when it came out.
I’m saying that there are things that sound really true that are repeated all the time. Like premature optimization is one of those things where it sounds great, it sounds like, “Oh, you are thinking about the big picture,” but in reality you are adding latency to your app and you don’t have a … a lot of people don’t have a rubric for when is that okay and when is that not okay.
I also like to follow people on Twitter that disagree with me or are from a totally different world of engineering. I follow like a lot of game programmers and like when something like Electron comes out or some use of JavaScript somewhere that they don’t like, they always just make fun of all JavaScript programmers. They are like, “Look at these morons,” blah, blah, blah.
Y: JavaScript land, what a dump.
P: Yeah and then the JavaScript people are like, “They are just a jerk and there is nothing true to what they are saying.” In reality there are big benefits to bring in a language that everybody knows to a new platform and building as much as you can in that platform. At the same time we burn so many CPU cycles that we don’t need to burn, delivering pretty basic UIs. I just think that you have to listen. Even if somebody is being a little offensive in the way that they like disagree with you, there still might be a kernel of truth to that.
Y: Yeah interesting. One very important question; are you guys using React at Smyte?
P: Yes we are. We are absolutely using it at Smyte.
Y: Do you want to tell people a little bit about Smyte? They will learn more in the coming weeks, hint hint.
P: Yeah, so remember how I mentioned that when Instagram came over, they took advantage of some of these tools that Facebook had but we mostly left them alone, the one big one they took advantage of was Facebook Site Integrity System for catching bad guys. Fake accounts, compromised accounts, spam, harassment and I was just struck by how important that was.
So Smyte is trust and safety as a service so you plug your application into Smyte either your analytics stream with our API. We’ll analyze it for bad behavior, this can be; spam, harassment, buyer side fraud. Like if you ever bought an apartment on Craigslist or rented an apartment on Craigslist you know that there are some deals that are too good to be true. We try to find that stuff on market places, fake credit cards.
So we work with a lot of marketplaces and we try to find fake inventory, so those are often deals that are too good to be true. Sometimes they are terms of service violations, so every marketplace, the instant it gets started. People post drugs for sale and some of them, some market places don’t want it so. It's a really interesting problem it’s a text classification problem, it’s a user behavior classification problem, it’s an image classification problem all kind of rolled up into one really interesting product I think. It’s been really fun doing it.
It’s been really fun building on all sorts of new, like it’s mostly infrastructure, we do have UIs that are built with React but I think the really interesting problems are the infrastructure and being able to scale up to all these hundreds and millions of monthly actives with an infra team of four people, that’s pretty cool.
Y: Amazing. if you think about it, that was one the big stories about Instagram was like they were able to do it with five, six engineers all writing application code and they weren’t worrying about the plumbing.
P: With Kubernetes the math is getting even more crazy.
Y: With Smyte so you guys are powering some pretty massive sites right?
P: Yeah, I mean we work with a bunch of market places like GoFundMe and Indiegogo and YouCaring. Social Apps like Quora and musical.ly, Task Rabbit yeah. If you think about like any sort of peer to peer application and two sided application they are built on the idea of their users trusting them and that it is a safe place to interact with people, a safe place to transact. In order to do that you need lot of automatic analysis as well as kind of a nice human element to understand those kind of gray area cases so that’s what we do.
Y: Yeah, no that’s awesome. Well, one thing that came to mind was that you being such a strong believer in React the natural assumption would be like you are going to go build something around React. What inspired you to start Smyte and how did that even come about? Did you go straight from Facebook to Smyte?
P: Yeah, as soon as my, as soon as I handed in my gun and badge at Facebook I went and I bought a new computer and started writing code for Smyte. But the idea, you know kind of going back to what we were talking about earlier, to think of Facebook as being kind of five years ahead of everybody else their approach to trust and safety is something that will be useful for other companies.
I saw this thing it was really, really valuable and important. I was like, “Okay, you shouldn’t have to sell your company in order to solve this problem.” That’s why we started Smyte to go and try to help out the companies that aren’t Facebook and can’t afford to get an army of engineers and a million servers to solve this problem.
Y: Awesome man this is amazing, thanks for taking the time.
P: Yeah, thanks for having me.
If you liked this interview, Follow us on SoundCloud or subscribe via iTunes to catch future episodes. Subscribe to StackShare Weekly to keep up with the latest tools and tech stacks.
