Facebook engineering has recently produced a powerful suite of loosely coupled tools for software development: React, GraphQL, Relay, React Native, and Flux Architecture. They are ruthlessly pragmatic developer tools. React is the product of Facebook and a large open-source community.
In a recent series on the Software Engineering Daily podcast, we explored the inner-workings of React and its implications for software development — including this prediction: Facebook will build a React operating system.
Development of native apps is currently bottlenecked by the Play Store and the iOS App Store review processes, which require hours, days, or months of turnaround time from pushing an update to making it available to users. Facebook wants mobile developers to be able to ship their native apps continuously, just like web developers can.
One of the highlights of React Week on Software Engineering Daily is this interview with Ben Alpert, a member of Facebook’s React Core engineering team. Listen to the episode below, and continue reading for edited excerpts.
Jeff Meyerson, Software Engineering Daily: One thesis I have is that React has the potential to be as influential on application development as iOS has been. From your position on the inside, on the React core team at Facebook, do you share this view?
Ben Alpert, React Core engineer, Facebook: Yeah, that’s an interesting question. I think that the creation of iOS and the new phone paradigm really created a whole bunch of different types of software than had previously existed. These apps are not really like quite anything that came before. I would say that React isn’t exactly like that, we’re not really making new types of apps. What React does is it makes it a lot easier to build apps, it makes them a lot easier to reason about and think about. What that means is that it’s easier to build more complex apps that work really well and don’t have bugs. It’s also easier for people who don’t have a lot of experience to get up and running and start making their own apps. So I think what we’ll see is over time, we’ll see people who don’t really have programming experience or that they only have a little bit, they just dabbled in it making serious apps that are even just for themselves, they want some reminders app and they wanted to behave in a very specific way just for their own personal workflow. They can build that or you’ll also see people who previously wouldn’t have thought of building apps, getting into the app building market, if you will.
Jeff Meyerson: I’m very curious about how the team dynamics and the software development culture has evolved on the React team. Because I think of Facebook as this very bleeding edge company in terms of development. It seems like you guys do a lot of things that are maybe fringe or can’t be done at other companies perhaps. Because the engineering quality is not high enough at other places. How does being on the React team compare to the more general types of application development and software engineering management styles that you’ve seen?
Jeff Meyerson: Does the social nature of the product that you’re building —well, Facebook as a whole — does that make the development more social? Or does it change the dynamic at all?
Ben Alpert: Not too much, I think. Facebook’s obviously known the most for facebook.com, and the Facebook mobile apps. There’s actually a ton of different projects here that are using React and related projects. They’re not all built in with a social component, but of course, many of them are.
Jeff Meyerson: I want to get an idea for how Facebook sees optimal web development, or some picture of web development. I’d like to talk about how best practices have come to life using React and GraphQL and Relay and Flux Architecture, and all these other things, these inventions and paradigms that have come out of Facebook. Because I’ve seen these things individually but I’d really like to understand how they fit together and map out a future of engineering.
Ben Alpert: I think that we’re just trying to figure out, what’s the simplest way to build applications. What that means is, most cases going higher and building abstractions on top of what people are used to using. When the language C was created, you had people saying, “Oh, I don’t want to use C because I don’t know what assembly code it’s going to compile into and it’s going to be slower than the assembly I would have written myself and all these sorts of things.” Now, basically nobody writes pure assembly anymore, and everybody writes in C or usually a higher-level language than that. I think you’ll see the same thing with React and Relay, and these projects. They try to abstract away these details that you don’t really need to think about when you’re using them. What that’ll mean is that you ask in a few cases you have a little bit less control, but on the whole, it’ll just be less work and your programs will work just as well as they would have. They’ll actually work better because instead of spending your time trying to figure out which line of assembly you made a typo on, you can just be building products.