Future of Coding - How ReactJS was created - with Pete Hunt

Episode Date: September 19, 2017

One of the original ReactJS developers at Facebook and Instagram, Pete Hunt (@floydophone) tells us the story behind the metoric rise of ReactJS. Pete explains the problems he faced Instagram Web that led him to Jordan Walke's early React prototype, and how he helped develop, evangalize, and grow React to what you know it to be today.Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Hello, and welcome to the Future of Coding. This is Steve Krause. So today I have Pete Hunt on the podcast, who many of you may know as one of the original contributors to React.js and for his work evangelizing React.js in the broader open source community. If you have learned React, chances are you've seen a video of Pete talking about how it works. Because he was there giving those early talks back in the early days. So the backstory is Pete worked at Facebook. And he was, in his own words, the first corporate drone that Facebook put on the Instagram team when they acquired it to help with, quote, trust and safety. And there he led the charge building the Instagram web experience.

And during the time he was building Instagram web, he needed something to help with front-end rendering and that led him to Jordan Walk and the React project and the rest is history. So it turns out I had actually met Pete at a party through work. He happened to be dating someone that I was working with at the time. He was showing me Instagram on the web, but I didn't and still don't use Instagram, so it didn't seem relevant to me. But then I saw on Hacker News this post by this ClojureScript guy, David Nolan, about the future of front-end and MV star frameworks. And that post blew my mind, and then I watched the talk of Pete's that he linked to,

and that blew my mind. And so ever since then, I've been obsessed with React and obsessed with ClojureScript and obsessed with Pete. And so I messaged him uh and and asked to be friends and and ever since that he's been mentoring me in a really thoughtful and clear-headed way as you'll you'll get a sense of in this conversation uh now pete is the ceo of his company smite that he started to help other companies with the trust and safety problem that he helped instagram with when he joined the idea is if you have a service that allows users to

upload content like photos or videos his service will allow is like an api that allows you to check if there's pornography or fraud or spam in that content in a real-time way so your system can be secure and safe. So yeah, it's a really cool company, and I think it's going well. So without any further ado, let me bring you Pete Hunt. So today I have Pete Hunt here on the podcast. Welcome, Pete. Hey, Steve. How's it going?

I'm doing well. How are it going? I'm doing well. How are you today? I'm great. Awesome. Good to hear it. So many people from this podcast may know you from your work with React. So I thought we could start off the conversation by talking about the beginning of React. So I'd be curious to hear about the problems at Instagram that you were facing that made you want for something that made you look for something that eventually led you to React.

Sure, that's great. So it's important to note that React actually existed before we acquired Instagram in 2012. And so we had been working on that for a while. I actually wasn't originally on the team. There was a handful of people, maybe two people or so, working on it. And the problem came out of the ads team. So there is this really complicated user interface for building ads on Facebook. So this is really complicated because

number one, you're spending money through this thing so it's got to be accurate. It actually has to be really consistent. The other thing is that there's all sorts of different types of targeting. You can do all sorts of different types of ad units. You can do all sorts of different locales where you can show your ad, which may have internationalization concerns and localization concerns. It's a really complicated piece of UI and it's very interactive. And so there was this problem kind of towards the middle end of 2011, where there were all these kind of callbacks that could happen and if they arrived in different orders the UI Would converge to a different state

Which is really bad when you're trying to you know Convince people to spend money through your thing and you want to show them what they're actually gonna get by spending on your platform so an engineer Jordan went off and started prototyping this thing that ended up becoming React. And you can kind of see some of the early experiments on GitHub under Fax.js, which I think is really cool. Fast forward to 2012, we acquire a little company called Instagram. And Instagram was

this really successful mobile app at that point. They wanted to build out a web experience as part of their growth initiative. And we had this issue where we had all of these application servers written in Python and they would talk to all these Postgres SQL servers and there was no proxy in between them. So every database had a connection to every app server. And we had this constraint where we couldn't add any more load onto the web servers, which is, you know, a pretty challenging thing to do. So we decided to go with client-side rendering and we evaluated a bunch of potential solutions, you know, both inside of Facebook and from outside of Facebook. And we decided to do a feature in React, which at that point had been put into production

on one small thing on Facebook. During the course of that first feature, there were lots and lots of issues. The API wasn't stable. A lot of stuff worked, but there weren't established best practices around it or there were features that used to work and didn't work anymore. So we discovered all of that. and then doing kind of an internal open sourcing to Instagram, which was run on an open source stack, run in Amazon Web Services, you know, just like any startups from that era would be set up. So there was that effort there. And then what ended up happening was we shipped those profile pages, which was the first feature built in React.

And then that worked out pretty well and just started building more stuff. Yeah, that's amazing. Thanks for giving us some of the origin stories. You mentioned briefly a place we could find some of the early experiments with React. Could you just repeat that again? Where can we look for that? Yeah, the original name was called fax js f-a-x-j-s and if you if you google that you'll you'll find a repo on github with that kind of original experiment cool um is there anything about fax js like any stories in particular that come to mind that you'd want to share now yeah um so i I guess like Fax.js was when it was kind of almost a personal project of Jordan's. So I don't think Fax.js ever went really into production or anything like that.

But if you go take a look at that repository, you'll be struck by like a couple of things. First of all, there's no JSX and it existed in a world before a lot of this JavaScript tooling was around. So before ES6, before Babel, before Webpack and all that. So it is really interesting taking a look at the design decisions that fell out of that. So the syntax is actually a bit different than it is today, but the core ideas are there. And the second thing that you'll be struck with is that the idea of server rendering

and the idea of something like a React Native was in there from the beginning. So it was designed from day one to support multiple rendering backends. So I just really enjoy taking a look at technical history. So whether it's the first commit, first serious commit of a project and what the design kind of manifesto was of that project, or whether it's looking at, you know, where, for example, the web component standards came from and going back into the mailing list and seeing what those original discussions looked like

or the original discussions around CSS or the original memos from Xerox PARC around Model View Controller. I think it's very, very interesting to see how those ideas were introduced and then what they evolved into. And then people are still fighting about every single one of those concepts today, even though some of them are, or all of them, I think, are decades old at this point. And so taking a look at how they were originally introduced and what we're fighting over now is always really, really interesting. Thanks so much for going into that. I think I'm also a kindred spirit in that

i'm trying to understand historically how a lot of these things came to be uh so part of why i created this podcast and this whole research project is to like add some structure to this project that i'm working on uh and i think a lot of the listeners to this podcast are people who are trying to create like new frameworks and languages um so let's see i have a lot of questions one question for you is um you listed a few different histories and and like people and places um where you find interesting ideas uh like i'm i'm curious if you have a place on the internet that you have notes on these things, or where else do you look? How do you structure your research? Could you give us some advice on how to do that? That seems like a really useful thing that you do. Yeah, that's a great question.

So to just give you a really quick answer, follow programmers on Twitter that were around in that era. So Kent Beck, for example, used to or he sorry, I used to work at Facebook and he still works at Facebook. And he he's like the guy that invented unit testing. And he's been around the I have a new idea or a controversial opinion about something, I'll either think about, hey, has he or anybody that he knows tweeted about this thing recently or blogged about it? Or maybe I'll just go and ask him and he'll give me an interesting history lesson. So there's identifying the people that really built this software, you know, decades ago. That's one place. There's another thing, which is the original wiki. So Ward Cunningham falls into that category of people that built all the software decades ago.

And he built the original wiki and it's hosted on a place called C2 and you can see a lot of you know discussion about technical topics you know that that happened from the 90s until today and they're referencing a lot of stuff that happened even before the 90s and so it's a great way to kind of like look in and see you know hey you know object-oriented programming got really popular starting in the kind of mid to late 90s. What were they fighting about back then? What was the influences?

Was small talk really as influential as everybody says it was? Was it really so amazing or are there downsides to it as well? And you can really get a great impression from there as well. And the other thing you can do is identify, you know, if there are standards bodies, like W3C, for example, has all of their mailing lists archived, and there's a lot of other, you know,

organizations like that that have archived mailing lists that you can take a look at and follow along in the original discussions. But basically the point is try to track down the primary source if you can. That's really great advice. I was wondering if you could, you listed Kent Beck, who is someone I also would agree is definitely someone to pay attention to.

His Prune article in particular. Did you follow, see what his work on Prune? Yeah, I was still at Facebook when he was working on it actually. So I was kind of following along internally. Um, and then I think I left before he finished it, but he published a postmortem that was public, I believe. Yeah. So all I saw was the postmortem cause I was never at Facebook. Um, and I spent a few months actually trying to like retrace the steps a little bit. Uh, so anyways, I think he's great. I was wondering if you had, if you could just list off the top of your head,

another handful of people to follow on Twitter, who you think are outstanding here. Oh man. Well, you know, Mark Andreessen is, is a venture capitalist now, but he's got a lot of, if you search for his name throughout the archives, you'll find a lot of stuff about browser history and the history of the web and HTML and stuff like that. And one thing that I really like is he gives a very, very impassioned argument for the font tag. And we accept today that the font tag is this universally bad idea and that CSS is, or at least the idea of having a separate style sheet from semantics is almost universally

accepted as a good idea. But a lot of the really smart people that worked in the beginnings of the web disagreed substantially. So Mark Andreessen, his original news group posts are really interesting. Alan Kay, he's the, you know, among other things, user interface. He invented a lot of user interface paradigms that we see today, but also he's one of the people that worked on Smalltalk. Joe Armstrong worked on Erlang. Who else? Not to say that there aren't people today that are doing interesting things, but it's always good to know your history. John Carmack and all the old game programmers. One observation that I found

is that you really want to start paying attention and talking to the people solving the really, really difficult problems. As in, if you don't solve this technical problem with something that really hasn't been done before, the business dies. And so that's where you start to get the really innovative and interesting technologies. And so that's why, for example, you see all this really, really great cutting edge distributed systems research coming out of Google because they hit a larger scale than anyone ever had. And so they had to push technology forward. Similarly, a lot of the AAA game companies have to do things with hardware that have never done before because the games have to do things with hardware that I've never done before because the games have to do more, they have to do a bunch of innovative stuff in terms of managing state, in terms of drawing performantly,

managing the network, that type of thing. So I like to to follow game programmers as well and pay attention to what they're doing. A good example is the other day, there's this notion of immediate mode GUIs in game programming, and it's always intrigued me, but I've never been convinced that it's fully practical. But somebody pointed me to the documentation for the latest version of the Unreal Engine, and the way that you build UIs in the Unreal Engine while it's in C++, the programming model is components and passing components into other components to compose composite components. It handles events through callbacks and they introduce a domain-specific language for

connecting components together in C++. I realized that it's very similar to React. And it's always interesting to see how those ideas, whether they cross pollinated or people just came to the same conclusion. It's always just really interesting to take a look at that. Great. Thanks. Given that you've talked about React a lot in a lot of other places, and React is pretty popular, we don't have to give everyone a full understanding of what React is.

They can find that elsewhere. But if you wanted to maybe take a minute or two to give a brief description of how you see React and the problems it solves, in particular, if you could emphasize what things about React, like what are the innovations that React brought to the scene, that'd be helpful. Yeah, yeah, that'd be great. And I think we can touch on what I think is the most important and relevant idea to your project as well. So I'm excited to get to that. So the core idea with React,

and this is the only thing that matters. So don't view components as a React innovation. Components have been around forever. You build any sort of native application on Windows or Mac OS or iOS, there's a notion of a component. Sometimes they call it a view, whatever. But the idea of composing components out of other components, it's been around since the dawn of time.

I don't know why we weren't doing it on the web. I think we were just, I don't know, being stubborn or something. But that's not a new innovation. The new innovation is basically making your view or your components, how it renders, a pure function of some underlying data model. So you can think of this as one-way data binding. So you've got this underlying data model or data structure, and then you write a function that says, given this data structure, this is the HTML and the CSS I want to show up on the page to render the UI.

And React's key innovation was being able to do that at any point in time. So if something slightly changes in your data model, the way that you used to do that at any point in time. So if something slightly changes in your data model, the way that you used to implement that was you would pick up on that change and then you would directly change the user interface. So there would be phase one where you paint the initial user interface, you render the initial markup in CSS, and then there was the update phase where you would observe a change in your data model,

then you would update that HTML or CSS as it existed on the page. And the problem is, you know, if you're rendering that once and then mutating it, understanding all the different ways that data, that user interface can change is really hard. With React, you conceptually just throw out all of the existing state in your application, all the existing markup and CSS that you've rendered, and just render it fresh. And the magic of React is that React makes that efficient and gives you good user experience on top of that. So that makes it a lot easier for you to predict what your UI is going to look like. It makes it a lot easier to test.

There's some interesting performance and developer experience characteristics in there, but that's kind of the big innovation that it had. Great. And while we're at it, maybe you could just talk a bit about the core underlying idea behind Flux. So I found this quote of yours, it was like an answer to a question on Quora, where you said that Flux, like Elm, is effectively just an implementation of event sourcing, which first appeared over a decade ago, which is loosely based on the command pattern introduced by the Gang of Four in 1994.

So if you could just kind of unpack that a little bit and explain what Flux is, that'd be helpful. Yeah, that's some history right there. So this is something that's really interesting, right? Like the idea of event sourcing, there's a related concept called CQRS and it's from like the Microsoft Enterprise world which is not a world that a lot of like front-end engineers or open source people you know really know that much about or interact with but it so they a lot of people think that flux is some new novel idea but it's been around

forever the idea here is that itux tries to solve one of the problems with React. So the really good thing about React is that everything is encapsulated. You pass into a component that data model that I mentioned, you pass in only the data that it needs, and then it can render the UI. Now the problem is your component might be made up of lots of other components, and if a component really deep in your hierarchy that you might not even know Now the problem is your component might be made up of lots of other components. And if a component really deep in your hierarchy that you might not even know you use because you use another component that actually uses that might request an additional piece of data. And so what that means is that it breaks every component that uses it because you have to pass that piece of data into that component throughout the hierarchy.

So that's a big problem. And then eventually you end up with these interfaces to these components that don't make a lot of sense because you're passing, for example, the currently logged in user into every single component, or you're passing in the client-side cache into every single component. And so Flux tries to solve this problem by introducing some global state. So rather than passing in the currently logged in user to every component, you can just query a singleton and you can say, hey, I want to get the currently logged in user and it'll return the currently logged in user. And so when you hear global state or global variables, like a lot of people have been taught that global variables are bad. And that's not entirely true. As long as you know

where the global variables are, and as long as you have a way of coordinating writes to them. So if they're global, for example, if they're global read-only variables, then those are just constants and those are great. If they're global variables that are mutable but you can very finely control when they're written to and coordinate that, then they're also actually pretty great. Global variables really get you in trouble when either they're implicit, so you don't know there are global variables, their expectation is that there isn't a global variable and there is one, or when you have multiple pieces of code or threads writing to the same global variable. That can get you in trouble too. So what Flux does is Flux basically coordinates

writes to the global state. And the way it does it is using something called the command pattern. So rather than having any piece of code in your application be able to write to your global state, like change the user that's logged in or update a user model or something, you instead dispatch these logical events. And so you create a new object and it'll be called maybe a login

event. And then you put that into a queue and then you have something called a reducer or a store that will pull events off of that queue and then update the global state and then trigger the re-renders across your application as needed. And so there's a couple of advantages to this. First of all, by forcing people to use a relatively small number of fixed commands or fixed events, you limit the number of ways that those that global state can change. The second thing is that all of the changes to global state are in one place in your reducer or in your store. And the third thing is that it becomes a lot easier to debug because you have the history of all of those events. You can introspect it and you can replay it and rewind it

and you can say, oh man, there's a bug in my application. You get the application into that state and then you can see the events that led up to that bug. And so that's a really powerful kind of approach to this. Thanks for giving us the summary. For anyone who's listening who hasn't heard about React or Flux before or doesn't know what this is, I think Pete's...

You should just know that it takes hours and hours for this stuff to make sense, or at least it did for me. So I think just in case that confused anybody, there are hours and hours of video where Pete explains, and other people, how this stuff works. So I thought I'd just give that caveat. But thanks for going over it, Pete. That was great. And it made me think of this trade-off, this technical design trade-off, this argument I have with my friend Samantha John of Hopscotch,

who is also a student of Alan Kay. She is inspired by a lot of his work. She thinks that the current obsession with the command pattern, which is now in favor, mainly because of the success of React and Flux, is a fad. She thinks that like a language like Erlang, where like it's kind of more organic and anything

can change state and it's much more, it's much less like command and control, much more organic. She thinks that's more kind of the future? And I disagree with you. I'm kind of more in the React school of thought. Do you think this is like a fad or do you think this is kind of the way things are going? Yeah.

So I actually tend to agree that the command pattern is overused. I don't think we necessarily have to allocate objects. And I've never seen a ton of value in that being able to audit every event that happened and being able to replay it. Simply because if I have the bug, I'll just drop logging statements or I'll bring in some sort of like logging abstraction where I can log that in developer mode.

I think the idea of saying, hey, though, we're going to have one plate, we're going to have global mutable state, and we're going to say that's an okay thing to have, because global mutable state, it's introspectable, it's serializable a lot of the time, and it's easy to understand and test, you know, depending on how, depending on if you implement it as a singleton. And then having basically what's called a facade. So rather than being able to mutate this global state directly, you have a small set of functions that do it on behalf of your components. And those can basically throw exceptions or return nulls or something, indicating that you're using the API wrong. I think that accomplishes a lot of the same, it gets you a lot of those same properties that Flux tries to get you. but it's faster and there's less typing.

And that's the technique that I generally use, is I just kind of create a set of modules that represent the global state and I think about a fixed API for them. I write a lot of tests around those and then I have the rest of my components talk to them. I'm not sure where the Erlang actor model fits into that. Personally, I haven't really had a lot of experience actually implementing in Erlang, but I do understand the actor model's influence on a lot of systems. But we can get into that if you'd like, but I don't know where you wanted to go with that. Cool.

Yeah. Thanks for, thanks for clarifying. Uh, okay. So my, my next question, uh, is, uh, kind of more on the emotional side of things. So I, I think a number of the people who listen to this podcast and me in particular, um, see what you did by creating this new way to think about user interfaces and help create a massively successful open source project is something that they aspire to do themselves.

And I'm curious to get a sense of how that feels in the early days. You bet the future of instagram on like this new react thing like how did you know and like how did your like certainty that this was going to be the future and this was going to work out grow over time and like especially because what's crazy about you is that you want to get like react goes against so many of the established best practices in in the industry and And you kind of took that on as your mantra, rethinking best practices trademark. So how did you know and how did your confidence in React and in yourself grow over time? Well, there's a couple of things there.

So first of all, React was not created to be a successful open source project. It was created to solve Facebook's problems and Facebook's problems only. And if it only did that, like it would have been a success. And so there were like maybe three or four competing technologies within Facebook at the time that were trying to be the next way that we write applications. Because you know, there's a lot of great programmers at Facebook working on this stuff. And so by the time, so React had been baked off against a couple of things by the time I got there. I baked it off against a couple solutions.

You know, down the line, mobile search and ads and all these other teams were considering React versus other technologies. down the line mobile search and ads and all these other teams were considering react versus other technologies and I was you know they would interview me about my experience with react we would compare notes on all of our benchmarks on all of our developer experiences on that you know what the code maintenance burden was that you know the byte payload or the the download size and the TTI and all that and so by the time we got around to open sourcing, like I knew this thing was fast. You know, any technical concern that could be brought up, I was pretty confident that

we were right on that. So the real question, I think, is, you know, why did we, why did we choose to open source this? And when we started using React, it was basically like, oh my God, this developer experience is so good, so much better than what we used to do with Facebook's internal equivalent of jQuery. And then we looked at what the open source community was doing with these templating languages. We were like, we know that that's not going to work in a million years. So let's open source this thing. And so the real challenge, we never actually knew whether it was going to be successful in open source. We thought that people would like it.

But it was not initially well received. You know, again, there were a lot of people that really hated this technology. A lot of people that thought we were wrong and it took, um, it took a lot of time to figure out how to message this thing because you can't just come in and say like, everybody's wrong and we're right. Blah, blah, blah, blah, blah. That's not, um, that's not really. You did go a little bit well which which talk um so there was the original jsconf us talk where we kind of came in we said

hey this is how we build um user interfaces uh at facebook and it was kind of just like a tutorial and then there's another way, which was the second talk, which was the one that I did, which was basically like, hey, here's why React is different. The argument that we were trying to make is that, hey, these are the problems that we had. Here's the solution we came up with and here's what makes our solution different.

And we had a lot of caveats in there that said you know hey this might not work for you there are these certain edge cases where it's actually slower than what you're doing today but what we found was this was a better set of trade-offs and really what we focused on was not educating people on how to use react or how to build their next application with it it was more about this is what makes it unique and interesting. And what that did was it kind of disarmed people. They were like, oh, this is actually really interesting. We focus much more on the implementation than how to use it.

And people appreciated that. And the second thing it did was it recruited people into the community that were really passionate about what it does differently. And so you see these big shots in the React community now, like Sophie Alpert and Dan Abramov and Chang Lu and all these people. They were originally recruited because I think they found the internals of React to be interesting, or at least some of the ideas around it to be really interesting, rather than, oh, I built my application in three less days than it otherwise would have taken. Cool.

So could you talk about a bit about how, because from my perspective, it seemed like React was inevitable and it just kind of happened magically, but you were more on the ground floor making it grow, it seemed like. You're flying around to conferences, evangelizing it. So could you talk through how it became adopted, how that felt, what were some of the key milestones or like the key things that happened that like made it uh that like moved along yeah so there was jsconf us which was the original announcement um everybody hated it uh then there was jsconf eu uh which got some more people excited about it. We wanted to support everybody a lot so we were in IRC like almost 24-7. People would come in and ask a question we would answer it. Some people would would camp on Stack Overflow and answer

those questions but basically like the idea was we wanted to recruit and basically keep those people engaged in the community because hopefully they could help out and that ended up working out nicely um so the number one thing was like just supporting the hell out of people the this you know second big milestone that happened or third big milestone that happened was when um david nolan got involved uh and kind of brought in the closure scriptureScript community. And he wrote this blog post called The Future of JavaScript MVCs. And he was kind of like, hey, this React thing solves a missing piece that we've had in the ClojureScript community for a long time. And it's got a programming model that I really like.

So that was a big noticeable uptick in the use of React. So again, what we're doing right now is recruiting in passionate early adopters. And that started to slowly turn into some real production usage of React outside of the Facebook companies. And then fast forward maybe a year or so, Flux is introduced and that solves a problem that the community had. We started talking at kind of bigger more corporate conferences like Facebook's F8 and then eventually put on a React conference for all of the users and then that started to inspire a lot of confidence in people to use React. And so then all these big companies started actually using React.

And once you've got some real-world production usage, we had this wiki page where people could add a link to their service and where they were using React in production. And we would point people to that when they're like, hey, my boss doesn't know if I should use this new technology. We said, well, you know, did you know that Facebook is using it, Instagram is using it, Airbnb and the New York Times and all these other well-known brands. So that was helpful too. Then, you know, we just started to see this big explosion in the usage of React throughout the community. And kind of the snowball was rolling down the hill at that point.

React Native was another big milestone in React's kind of adoption because that opened up the world of mobile developers. So I found React because of David Nolan's article that you mentioned. And I was immediately convinced after reading that article and then watching your Rethinking Best Practices talk, which I think he links to in that essay. So I can definitely see how that was a big milestone. I didn't realize how big of a milestone that was in your mind. But that's how you got me. So it makes sense. Yeah. You know, that wasn't an accident either. Um, so like, there's a lot of, you know, I was going to conferences and I was connecting with people on Twitter and stuff like that. And the way that got put together was

there's this guy, Brandon Bloom, who's a game programmer who you guys should all follow on Twitter because he's really smart. And he sent me a message or tweeted at me or something. And he was like, hey, I saw your talk. Did you know that this is how all game engines are implemented? And I was like, what? I don't know very much about graphics. And he

talked me through it and explained it to me. And he's like, he was in New York and I was like, oh, I'm flying to New York. We should meet up. So we met up over a cup of coffee and he's like, I'm going to bring my friend David Nolan and he's going to come sit in on our conversation. And so the three of us were just kind of at a coffee shop somewhere in New York talking about React. And then he pops into the IRC channel, has a bunch of questions as he's building his first version of his React bindings. And we're all kind of, again, continuing this level of support that we had.

And that blog post pops out and changed the game for React. So that wasn't like, oh, I stumbled upon this technology and I was struck by how awesome and that blog post pops out and changed the game for React. So that wasn't like, oh, I stumbled upon this technology and I was struck by how awesome it is. It's like none of this stuff, like, yeah, things go viral, but they go viral after a lot of boots-on-the-ground effort. I'm so glad that that's how it actually happened because that's so empowering that it isn't just random what goes viral and what doesn't. If you work really hard and do the work, it'll eventually work out.

So I'm really glad that that's how it happened in reality and that I have it on this podcast. That's really inspiring. Yeah, yeah. I mean, there are things you got to get right. Like you got to write documentation and you got to build's got, you get like three bullet points, three single sentences to communicate why your project is different and worthy of someone's attention. And like it's faster and it's smaller and it's lightweight are not real reasons. Like you've got to sacrifice something, right? Because otherwise React would be smaller and lighter weight, right? So what are you sacrificing? Totally.

So one thing I saw on the internet that caught my attention when I was preparing for this interview is that there was a quote where you talked about how you replied to every hater comment on Twitter. And is that something that you thought was effective? Do you still do that now? Tell me more about that. Oh, yeah. that was actually Reddit. So we would post it to Reddit, and there would just be all of these salty programmers

would just reply and trash on like, oh, my God, you're putting HTML in your JavaScript. It's so bad. Or like, who is Facebook to tell us how to build applications when we have this thing from Google, and Google's got way nicer products than Facebook? Whatever it is. And I replied to every single one of those.

And you know what? Like, some of these people had legitimate concerns. I've actually found in my personal experience, there's very few real trolls that are just trying to troll and just trying to piss you off. There's a lot of arrogant people and there's a lot of people that have strong opinions and don't do a great job of expressing them in a respectful way. But their goal is not to piss you off. They actually have legitimate concerns. And the way that I thought about it was, you know, I viewed every single one of those concerns as my fault, because either the technology didn't do what it needed to do, or as in they had a legitimate technical concern, or they didn't have a legitimate technical concern, and we failed communicating that to them. And so if you just say like, hey, all of these complaints on Reddit are actually legitimate or have a kernel of truth to them and they're all my fault. You start to do a lot of self-improvement really quickly. And so that's why I think the messaging around React got to be, I thought, very, very crisp within the first nine months of it being open

sourced. And that messaging, like branding it the virtual DOM, that now gets a lot of flack and criticism. But I stand by it. It's not 100% accurate. But if you've got someone's attention for five minutes and you want to explain how React works, virtual DOM is a great way to do that. Really interesting. I think replying to all the haters

as a way to hone your message. All the nested haters in Hacker News and Reddit. I think that's a really funny way to hone your message. I guess when your audience is programmers, you might as well yeah talk to them and hear their concerns that makes sense yeah yeah the the answer to any technical question um should be or any one of these these haters i think um should be yes you're right and we're going to fix that no you're wrong because um and here's a link to the documentation, or we should write documentation on that,

or you're right, but we made a calculated trade-off and here's why, and here's a link to the discussion as to why we made that trade-off. And if you can't do any of those, then you might be deluding yourself a little bit. You gotta really be, you gotta really look at yourself and your project critically and assume good faith on all sides.

Okay, yeah. I think that's a really good clarification. You're not like our president just replying to haters ad hoc. You're thoughtfully responding to each concern in a systematic way. I think that's a good qualification to make. Yeah, yeah. Like, you put HTML in your CSS and that violates separations of concerns, says somebody. The answer to that is, well, no.

Like, we view that as separation of technologies, not concerns. But you're right. We didn't message that very well. So, like, we're going to create a page in the documentation about that. And then, you know, the next response to that is, well, designers don't want to look at JavaScript, they only want to look at HTML and CSS.

And then the response to that one is a little different. It's not like we failed the documentation. It's like we're making a conscious trade-off where we say hey the designers got a power through some javascript in order to contribute and what you get for that is very very much increased productivity for your friend and engineers and we think that trade-off is worth it what have you learned uh what like the hard lessons that you learned creating a massively successful open source project? Or put another way, what are your biggest regrets?

What would you do differently? Sure. So the big thing that I learned, which I think is particularly relevant to what you're doing with your project, is I see this like every day a new project comes out. People conflate the idea of making a framework or a library or a software package that makes programming easier for programmers and making programming more accessible

and inclusive to a wider audience. So I firmly believe that the tools that you use to introduce somebody to programming look very, very different than the tools that you give somebody who already knows how to program and make them more effective. And if you think of a lot of the early criticisms of React, which was, hey, we have this,

people were using template languages before, which are really, really simple and easy to pick up, even for non-programmers or people who can't program very well. Well, the downside for that is that when your UI gets really complicated, you really do need a powerful programming language to express what you need to express. And React fully embraces that. So React, you know, is, I would say React is harder for people that don't know how to or almost impossible to use for anybody who doesn't know how to code. Whereas a templating language like Mustache, you might be able to use if you don't know how to code. But building a complex application in React for somebody who knows how to code is much, much, much easier than building something in handlebars or mustache templates. So that's, I think, a really important concept that I see so many companies and so many projects get wrong. Like pick your audience. It's either experienced

programmers that are building applications that are going to production, or it's people trying to learn programming and you're trying to build an educational tool. Don't try to do both. You also asked kind of what we could have done better. And what I, the big mistake that I think we made, and I didn't push for this hard enough, was I wanted to have some kind of certification process. Now this sounds like a lot of bureaucracy, but basically it's like a GitHub badge where you could put it on your project and it could say like certified by the React team or something, and we could have some people,

we would have basically like a checklist of things that you would have to, criteria you would have to meet in order for you to get that badge. And we would have a network of kind of trusted individuals in the community that would bless certain projects and so what that does is like when you're going and looking for a type ahead component or a table component you could have some guarantee that oh this thing is going to be accessible this thing is going to work cross browser this thing is adequately stylable so I can drop it into my application without forking it, that type of thing. That answer your question? Totally, yeah. Those are great. I want

to go back to the first point you made because I think that's a really interesting point that I agree with in some ways and disagree with in others and I would like to flesh it out a little more. So to me it sounds like what you were saying is that when you're building, the tools that experts use are going to look different than the tools that beginners use, which makes sense at first blush. Beginners tools are going to look like

MIT's Scratch programming language and expert tools can look more like a good text editor and React code. That makes a lot of sense to me. There are some places, however, where beginners and experts use the same tools like musical instruments like a guitar and a drum set the same tools that beginners and experts use but in other industries they're you know it's different you know beginners use some tools and experts use different tools so i'm i could see the argument that in some cases the tools that beginners get

and the tools that experts get are different. But I don't see any reason why, like from first principles, those need to be different tools. Does that make sense? What do you think about that? Yeah. So there's a really good blog post about this that I can't remember what it is, but the musical instrument analogy really got me going down this path. It's like, I could, I would compare like playing the guitar to Guitar Hero. You know what I mean?

Like Guitar Hero is really, it's for everybody, You know, it's really democratized. Anybody can pick up Guitar Hero and play Guitar Hero. You got to invest a serious amount of time into playing the guitar to actually play the guitar. And I think that for that analogy anyway, it's really about how structured or unstructured it is. So how many different directions can you take the tool? And beginners need a lot of direction and experts need it in some places and don't need

it in other places. I'm not sure if that analogy is really holding up, but kind of what I'm... When I think about the beginners versus experts thing in the JavaScript world, it's like, you know, beginner doesn't really want to understand, they just want to get something showing up on the screen. Because part of it is a motivation and an energy thing. And so you want to get something showing up on the screen. And you don't want to have to show them the command line or educate them on the command line screen and you don't want to have to show them the command line or educate them on the command line and you don't want to

educate them on a type system and you don't want to educate them on all these other things just to get something to show up on the screen. So like a lot of beginners really want like a, I think anyway, a text box in the browser where they type the code, they press run and it shows up and they don't have to deal with any of that other crap. No professional wants that. I think that professionals want things that run in the command line and can be plugged into their CI system and can be integrated into all these different things. So the command line tools are harder to use but they're a lot more flexible, whereas the in-browser editor takes a lot of decisions away from you but you can get up and running in 30 seconds

okay yeah i think i think we're on the same page uh we're like i'm i'm i understand what your perspective is just just to flesh it out a little bit more um like to to kind of push back a little bit um i built a tool. Are you familiar with Google Blockly? It seemed to remember the name, but could you just explain it to me? Yeah. Yeah, sure. I should describe it for everyone.

So Google Blockly is a library that Google makes that allows you to very easily make a block-based programming language. So it's kind of like MIT scratch but like you can make your own blocks is a general idea so so I came up with this idea so my first idea was I was teaching children how to code and I just gave him a text editor on a browser and told him you know type some stuff in stuff will happen but they had to learn HTML CSS and JavaScript and it was a mess so I

came up with this idea I'm gonna make blocks where they can use like a jquery type thing to create their web app um they only get the block there's one interface they don't have to learn multiple languages it's just like a jquery type interface and it was kind of successful but very quickly i realized that that imperative jquery style wasn't going to work so i created a next version which is a which was a React tool. So they would move the blocks around. You'd put a div inside of a div, and you'd put a reactive variable in there. So the code literally compiled to React. You would mess with blocks and it would compile to React code on the backend.

And so from my perspective, this was so much easier for beginners. They could make real apps in the React style much easier than they could code a simpler app by hand in HTML, CSS, and JavaScript. But at the same time, me as an expert, or my other friends who already knew how to type React code by hand, we also found it easier to use this tool. I should caveat that with this tool was super buggy and hard to use and like you know i'm not gonna actually use it in production because it's not that good but in principle it seems like someone should be able to like it's reasonable to to imagine a tool that's both intuitive for beginners and also more powerful for experts um or do you think in principle that that's like the wrong way to go uh and it's much better to pick an audience so So just help me understand it. Are you building the blocks in a UI or in a text editor?

So the blocks are the UI. If you're by computer and you want to check it out right now, I'll send it to you later, but if you want to check it out right now, you can go to stevekraus.github.io slash cycle. Okay. Hashtag to do hyphen MVC, I think, is cycle. So, yeah, stevekraus.github.io.

Yeah, I clearly should have sent this to you a while ago because I don't think this is the solution to anything. Here. I got anything. Here. I got something. Cool. You got something? Cool. If you put hashtag to do hyphen MVC, you should get a sample program.

I see. So it's not beautiful. It's not perfect. The only reason to bring it up is just to kind of help us flush out this idea because I think it's a really key discussion like the audience and in principle expert tools versus beginner tools it's something I think about all the time

so I'd love to get your thoughts on it yeah so you can not only style but you've also like, control flow and stuff like this. And here. So the, like... So, sorry, to just make this conversation a little more focused, there's, like, a million things that I know are wrong with this tool.

Like, I'm not continuing to work on it. I don't want to go too deep into this tool. I just wanted to use this tool to I'm not continuing to work on it. I don't want to go too deep into this tool. I just wanted to use this tool to illustrate that. Because what you said, and I agree with you, is that if you're teaching kids HTML, CSS, and JavaScript from the start, you want to teach them those things first and then go to React. You don't want to start with React because React is more complicated. But in this tool that I have here, React is less complicated than, um, any other tools. But, uh, you know, so what I'm getting at is I, I think if you build the right interface, there's a convergence between what the experts want to use and what the beginners want to use.

So, so I, I understand what you're saying in principle. And I think that there's, there's some truth to it, right? Like if you build a better mousetrap that's universally better, both beginners and experts will like it. And if you build a mousetrap that is easy to do 80% of the stuff you need to do and then provides nice and easy escape hatches for that last 20%, then that's great. The part that I would would challenge like specifically with like

the visual programming stuff this is just um in illustration of the type of thing that i wanted to talk about with the divergence of expert tools and beginner tools is like if i want to diff two versions of this uh or if i wanted to search and replace for a string within the whole application. These types of things people can do in the command line for decades. But every time that you introduce kind of a new tool, for beginners, at least for me, the scary thing for beginners is you got to teach the command line and the thing that they need to do. And you want to just try to do one at a time.

I think, anyway. You probably educate more people than I do. So maybe you have a better opinion than me. But I do think that the easy way for a beginner and the easy way for experts are sometimes aligned and sometimes different. Great. Thanks for going down this rabbit hole with me. That was really helpful. So React is very much the way most people think about designing user interfaces today.

What do you think, what problems still exist in user interface design that need to be solved? Or, yeah, in which way, what problems still need to be solved or do you think React has kind of solved most of them like what's your perspective on the future of interface design

that's a great question I think where the React model breaks down is so React kind of assumes that it's running if you think about React Native actually let's talk about mobile and React Native you kind of assumes that it's running if you think about React native actually let's talk about mobile and React native you kind of assume that all of the the gestures and frame by frame

animations are implemented in some native component somewhere that is wrapped in a React component and then you can build you basically snap together all of those different React components on the JavaScript side but if you have to do something that's really, really high performance, like frame-by-frame animation type of thing, you still implement that in native code. I think it would be interesting, and I may or may not have prototyped some of this, what if we implemented a React-like abstraction all the way down to the middle. So rather than the current state of the world with both React Native and React Web where you have this kind of object-oriented view hierarchy and then React

does its diff and then updates that object-oriented view hierarchy through the normal API, what if we actually had a React-like UI library that spoke directly to the graphics engine? And what would that do to performance? Could we actually render frame-by-frame gestures in React and use all the same nice abstractions that we have and nice conceptual models that we have for rendering the swipe gesture rather than just putting in a swipe gesture component. So that I think is really interesting. If you take a look at some of

the stuff that game programmers are doing with immediate mode GUIs, or immediate mode user interfaces, there's a really interesting video on a website called MaliRocket that talks about it. It really kind of changes the way that you think about what React could do. Now there's a lot of open questions on there and it remains to be seen whether that this is a solution that the market really needs. Like it seems like React Native is fast enough and people are using it, but still it could be really interesting to make that change. I'm really glad you brought that up

because that's something I've been thinking about a lot, actually. So in particular, the way I think about it, and you could tell me if this is not the way you think about it. So it seems like people are constantly talking about ways to build a better version or better abstractions on top of JavaScript and make JavaScript better. And we kind of leave HTML and CSS the way they are in a lot of ways. But from my perspective, while they do do some amazing things, like they have a lot of interesting components,

like an input box, and they handle layout and stuff like that, it feels like we could build a better layout, engine, styling, abstraction thing that maybe compiles down to HTML, CSS, or just writes on the canvas directly um and then we build bindings for android and ios and different things like that is that kind of what you're getting at like building like kind of starting the renderer of things from scratch and like skipping the the dom like doing it on our own yeah so i've actually

i've actually done that. It's really interesting what happens when you start to do that. So like, I can tell you the approach that I took in my prototype, if that would be interesting. Yes. Okay, so there's, what you basically do is you want to start with a fairly low-level abstraction. And so there's this thing called libSDL, which is this kind of friendly API on top of OpenGL. So you can say, hey, I want to render this text or I want to render this shape or whatever. And I want to paint it to the screen. And so if you haven't done any graphics programming before, the way that it works is that you have an infinite loop and then every 16 milliseconds your function gets called and you draw to

the screen. So you have like a ton of... you have frame-by-frame control over everything that happens and so everything has to be really fast. And then what I did was I compiled that with this thing called Emscripten. And I had it running in a canvas in the browser with a mere 14 megabytes of JavaScript, but still. So the point is, like, we had this library that was running both in the browser and in a native application on my desktop. And then you can take a project from Facebook, which is called Yoga, Facebook Yoga, which is an open source layout engine. And what you do is it's an implementation of Flexbox. It's written in C. You basically provide a function that can measure text.

So you say, so the layout engine says, hey, text field, you have 300 pixels to fit your text. How high is, like, how much height do you need because of text wrapping and stuff? So I had to write a little code that integrated yoga with that. And then finally created like a tiny little React-like library in C to, you know, have the React kind of semantics of re-render every frame and only re-layout when you need to, and then paint the pixels to the screen. So it was a really interesting project, and I would love to see what would happen if I actually, you I actually brought in a JavaScript engine into that project so you wouldn't have to write your UI in C. But it is possible. It was like a couple hundred lines of code. It's not that crazy. The tooling's really good now. You already have an open

source layout engine that you can plug into. You already have something that can compile C to the browser. And all the dependencies are already ported over. So it's actually not too hard to do. I'm so excited about this. Is the code open source? Do you have a postmortem written up somewhere, kind of like Prum? What are the next steps?

I'm sold. I mean, I don't know if I'm sold. But I could clean it up and post it somewhere. Okay, I'll bug you for that offline. It's just a hack, but it's a cool hack. I'm more excited. To me, it sounds a lot like whatever you've come up with wouldn't be the thing it's just the the thing that inspires the thing uh so and anyways i'm i'm jazzed about about this so i'll bug you about

that offline to to get to get that written up in some way because i think that's really a really interesting line of inquiry who knows where it'll go yeah so i've been trying to convince um this was before react native but i was trying to convince, this was before React Native, but I was trying to convince, you know, there are all these like mobile web startups that are trying to build really fast mobile apps.

I was trying to convince them to build basically like a minimum set of browser primitives that can be really fast and then build your own browser such that you can like build a web app build your own browser, such that you can build a web app that targets this magic fast browser that you have, but can also run in commodity browsers.

And I don't know, I think that's a really good idea. You can see some of that stuff in the React Native world with React Native for web that might be solving the same problem, but it could be an interesting approach. Yeah, I think that's really brilliant. Okay, so my last question, if you have things to talk about, go for it. And if you don't have obvious things, we can skip this one. So it's like a two-part question. One, what technologies are exciting you today? Like what new frameworks or things should we keep our eye on in user interface design

or even just any sort of programming technologies that you're jazzed about? On the other side, what technologies you think are distractions or overhyped in this space specifically? And then the third part to that question is what are you excited about in particular that nobody else is noticing? Ooh, that's interesting. So I started a company a couple of years ago called Smite, which is trust and safety as a service. So anti-spam, anti-fraud, anti-harassment stuff. And we are mostly an infrastructure company. So we ingest event data and we have to process it very quickly and we have to learn from it very quickly. And so what's interesting about this is I see kind of what's going on at Cutting Edge on the infrastructure side, server side, as well as the Cutting Edge stuff for my work with React. And so you see event sourcing on both sides of that coin.

So Kafka is really, really huge. Everybody's using it on the server side, which is the kind of messaging bus that you use to implement something like Flux. So you put a message into Kafka, it comes out, you have some process running in a container that processes that and writes to a database. That's exactly the same way that Flux works. So I think that's really interesting. In terms of what to keep our eye on, you know, on the front end, I'm not like, I feel like to say the front end's pretty good. Like React Router's pretty good as a version 4. You know, there's like a bunch of different inline styles,

libraries you can choose, and they're all fine. I like mine because I like to type as little as possible, and I really only care about desktop apps at this point in my career. In terms of actually laying things out on the page and styling them, I think you got React or React-like library, JSX style or a JSX style library for inline styles. And, you know, laying things out with Flexbox has been pretty awesome and I enjoy doing that. Data fetching is something that's still an open question.

I mean, GraphQL is great, but I'm not convinced by any of the client-side implementations right now. I haven't heard of a lot of success outside of Facebook with Relay, and I know that there was some churn on that. We've used Apollo, and there are some bizarre design decisions within Apollo that I don't really understand or agree with. Those are the two major ways to interact with GraphQL. I think that there's some room for innovation there on the front end. And if you were to kind of take a step back and look at the big themes in software in general, and now I'm going to start to sound a little bit like a business guy, and I apologize for that. But I also am still a programmer, but also do a lot of CEO level stuff.

And there are kind of three main themes that I see in the tech industry. The first is a relentless focus on iteration speed. And there are kind of three main themes that I see in the tech industry. The first is a relentless focus on iteration speed. So you see this with things like React Hotloader. You see this with things like continuous integration and continuous deployment. You see this with every tool is getting faster and the idea is to get as many feedback cycles in as you can. The second big theme that I see, and I'm not sure if this is relevant to front end as much as it is on infrastructure, but there is this relentless march towards variable costs for everything. So before you had cloud computing, you had to buy space in a data center and buy some servers, which are some fixed costs, and then you run some software on them.

And then every month you have some power and rent costs, and those are your variable costs. With the cloud, you now have variable costs where you can spin up and tune down VMs as you see fit, and then those become variable costs. With functions as a service or serverless architectures which are getting pretty big now, or about to get big, that's even more fine-grained. So you're talking about on the per request level you're paying, rather than on the amount of time the server is up. And that's again, you know, this march towards variable costs, not fixed costs. And you can see this in how you buy software, too. It's very rare now. If you wanted to buy Photoshop, for example, you used to pay a couple hundred dollars and you would have Photoshop forever.

Now you have, you pay $10 a month or whatever it is for Adobe Creative Cloud. And you just buy a license. So there's certainly this move from fixed cost to variable cost. The third thing that I would feel comfortable betting on, which a lot of people will disagree with, is I think you can always bet on centralization. So you're seeing more and more things over the last 10 years that used to be lots and lots of small companies or peer-to-peer style applications or whatever they are.

And they're all becoming centralized. And the reason for that is, again, when you centralize, it's a lot easier to iterate quickly. Basically, you don't have to worry about pushing the update out across a bunch of decentralized peers or whatever. You can just make one sweeping update. So those, I say, would be the three themes that I see when I'm looking at the industry as a whole. Cool. Thanks for going through that for me. Okay. So I want to be mindful of your time and wrap up now. I just want to say thanks so much for taking the time to do this. This was so much fun. I learned a lot just during this talk and there's a lot that you referred to that I have to now go do research on.

So thank you. No problem. I enjoyed it as well. It's always good to think about the beliefs that you have and make sure that they're right or question them. Yeah. So the last that you have and make sure that they're right or question them every once in a while. Yeah, so the last question I have for you is, basically what is your API? What is the Pete Hunt user interface? If people wanna get in touch with you for various things,

what are the channels, like Twitter, email? Are you hiring for your company? How should people think about interfacing with you? Yeah, Twitter's pretty good. I'm Floydophone, F-L-O-Y-D-O-P-H-O-N-E on Twitter. We're also hiring at Smite, jobs at smite.com is another way to get in touch if you're looking for that. We're hiring for infrastructure, front end, sales, marketing, whatever like if you can help we want you but yeah yeah

Twitter is Twitter is really really easy for me to interact with people great okay well

thanks so much again and I'll talk to you soon alright have a good one you too bye bye Have a good one. You too. Bye. Bye.