subscribe

maicki

There are no people in maicki’s collective.

Huffduffed (281)

  1. Q&A Panel with Core team and speakers at @ReactEurope 2017

    Original video: https://www.youtube.com/watch?v=BvHxlVlse-g
    Downloaded by http://huffduff-video.snarfed.org/ on Thu, 25 May 2017 15:19:59 GMT Available for 30 days after download

    —Huffduffed by maicki

  2. Relay Modern with Lee Byron and Joe Savona | Software Engineering Daily

    http://traffic.libsyn.com/sedaily/RelayModern.mp3Podcast: Play in new window | Download

    Relay is a JavaScript framework for building data-driven React applications. Facebook open sourced Relay around the same time they open sourced GraphQL, and Facebook expected Relay to be the more popular of the two projects.

    However, the reality was reversed. Open source companies like Meteor quickly began to build GraphQL tools and a few businesses were started around GraphQL. One year later, the excitement for GraphQL had completely surpassed the excitement for Relay which had aged poorly in a newborn ecosystem of GraphQL tooling.

    At the same time, Facebook was also starting to integrate Relay into their React Native apps. But Relay was performing poorly on low-end Android devices. This led the Relay team to the conclusion that they needed to rewrite Relay. Both to better fit into the growing GraphQL ecosystem, and to be built with performance in low-end React Native environments at the top of mind.

    Relay Modern is the new version of Relay. It was released to the open source community at this year’s F8. In this episode Caleb Meredith is joined by Lee Byron, the co-creator of GraphQL, and Joe Savona, a founding member of the Relay team, to discuss Relay Modern. The discussion includes a conversation about the commercial GraphQL ecosystem, the story of why Facebook decided Relay needed to be rewritten, and a look at the future of UI development from some trends seen in Relay Modern.

    Transcript

    Transcript provided by We Edit Podcasts. Software Engineering Daily listeners can go to weeditpodcasts.com/sed to get 20% off the first two months of audio editing and transcription services. Thanks to We Edit Podcasts for partnering with SE Daily. Please click here to view this show’s transcript.

    Sponsors

    Oracle Dyn provides DNS that is as dynamic and intelligent as your applications. Dyn DNS gets your users to the right cloud service, CDN, or data center, using intelligent response to steer traffic based on business policies, as well as real-time internet conditions, like the security and performance of the network path. Get started with a free 30-day trial for your application by going to dyn.com/sedaily.  After the free trial, Dyn’s developer plans start at just $7 a month for world-class DNS. Rethink DNS. Go to dyn.com/sedaily to learn more and get your free trial of Dyn DNS.

    It’s never been easier to hit the ground running: MongoDB Atlas is the only database as a service from the engineers who built MongoDB. With continuous backup, VPC peering, monitoring, and security features, MongoDB Atlas gives you everything you need from MongoDB in an easy-to-use service. And even if you’re already running MongoDB in the cloud, Atlas makes migrating your deployment from another cloud service provider trivial, with its Live Import feature. Get started with a free, 3 node replica set: no credit card required. As an exclusive offer for Software Engineering Daily listeners, use code SEDaily for $10 dollars of credit for when you’re ready to scale up at mongoDB.com/sedaily. MongoDB World is where the world’s fastest growing database community comes to connect, explore, and learn. Join the team that builds MongoDB in Chicago on June 20-21, 2017 for hands-on and deep-dive technical sessions, giving you the tools you need to build and deploy your giant ideas. Use code SEDaily to get $100 off tickets!

    Dice.com will help you accelerate your tech career. Whether you’re actively looking for a job or need insights to grow in your role, Dice has the resources you need. Dice’s mobile app is the fastest and easiest way to get ahead. Search thousands of jobs from top companies. Discover your market value based on your unique skill set. Manage your tech career and download the Dice Careers app on Android or iOS today. And to check out the Dice website and support Software Engineering Daily, go to dice.com/sedaily.

    Share this:Click to share on Twitter (Opens in new window)Click to share on Facebook (Opens in new window)Click to share on LinkedIn (Opens in new window)Click to email this to a friend (Opens in new window)

    Related

    https://softwareengineeringdaily.com/2017/05/24/relay-modern-with-lee-byron-and-joe-savona/

    —Huffduffed by maicki

  3. Past, Present and Future of C++ - CppCast

    CppCast is the only podcast for C++ developers by C++ developers.

    http://cppcast.com/

    —Huffduffed by maicki

  4. Software Transactional Memory - CppCast

    CppCast is the only podcast for C++ developers by C++ developers.

    http://cppcast.com/2015/09/brett-hall/

    —Huffduffed by maicki

  5. What’s the best fitness watch? It’s not the Apple Watch - Recode

    Wearables expert D.C. Rainmaker offers his picks on the latest episode of Too Embarrassed to Ask.

    https://www.recode.net/2017/4/21/15375408/fitness-smartwatch-ray-maker-dc-rainmaker-wearables-running-cycling-recode-podcast

    —Huffduffed by maicki

  6. Mac Power Users #374: iPad Sensei - Federico Viticci - Relay FM

    We catch up with Federico to discuss how he became an "iPad Guy", some of his favorite tips, tricks, and workflows on iOS, where there’s still room for improvement, the future of iOS and more.

    https://www.relay.fm/mpu/374

    —Huffduffed by maicki

  7. LLVM with Morgan Wilde | Software Engineering Daily

    http://traffic.libsyn.com/sedaily/LLVM.mp3Podcast: Play in new window | Download

    Every program gets compiled down to 1s and 0s before it can be executed against hardware. Before being translated to machine code, programs that are written in a language like Rust, Swift, or Java spend time in an intermediate representation.

    In Java, this intermediate representation is Java bytecode. Many different languages–such as Scala–translate to Java bytecode, because there has been lots of optimization written to speed up Java bytecode. Java bytecode runs on the JVM–the Java Virtual Machine.

    LLVM is a project that draws inspiration from the Java Virtual Machine. LLVM originally meant “low level virtual machine” but today it is just called LLVM and describes a set of compiler tools.

    In today’s interview with Morgan Wilde, we explore how compilers work, how different processor hardware architectures present a problem for compilers, and why LLVM’s intermediate representation creates a layer of interoperability for any language that compiles down to that intermediate representation.

    Whether you are new to compilers or have experience, this episode will appeal to you. Morgan is an excellent teacher and his enthusiasm for the subject comes through. He has a 30-minute YouTube video–A Brief Introduction to LLVM that I highly recommend.

    Sponsors

    To understand how your application is performing, you need visibility into your database. VividCortex provides database monitoring for MySQL, Postgres, Redis, MongoDB, and Amazon Aurora. Database uptime, efficiency, and performance can all be measured using VividCortex. You can learn more about how VividCortex works at vividcortex.com/sedaily.

     

    Exaptive simplifies data application development for the web. Work with the tech you know. Leave the other stuff and the blue code to the platform. Go to exaptive.com/sedaily to learn more and get a free account.

    Oracle Dyn provides DNS that is as dynamic and intelligent as your applications. Dyn DNS gets your users to the right cloud service, CDN, or data center, using intelligent response to steer traffic based on business policies, as well as real-time internet conditions, like the security and performance of the network path. Get started with a free 30-day trial for your application by going to dyn.com/sedaily.  After the free trial, Dyn’s developer plans start at just $7 a month for world-class DNS. Rethink DNS. Go to dyn.com/sedaily to learn more and get your free trial of Dyn DNS.

    Transcript

    [INTRODUCTION]

     

    [0:00:00.3] JM: Every program gets complied down to ones and zeroes before it can be executed against hardware. Before being translated to that machine code, program that are written in a language like Rust, or Swift, or Java, they spend time in an intermediate representation.

     

    In java, this intermediate representation is Java bytecode. Many different languages, such as Scala, translate to Java bytecode, because there has been lots of optimization written to speedup that Java bytecode. Java bytecode runs on the JVM, the Java Virtual Machine. LLVM is a project that draws inspiration from the JAVA Virtual Machine. LLVM originally meant low-level virtual machine, but today it is just called LLVM and describes as set of compiler tools.

     

    In today’s interview with Morgan Wild, we explore how compilers work, how different process or hardware architectures present a problem for those compilers and why LLVMs intermediate representation creates a layer of interoperability for any language that compiles down to that intermediate representation.

     

    Whether you are new to compilers or you have some experience, this episode will appeal to you. Morgan is an excellent teacher and his enthusiasm for the subject comes through. He has a 30-minute YouTube video, A Brief Introduction to LLVM, that’s in the show notes. I highly recommend it if you’re curious about this topic. It’s one of those really succinct explanations that nonetheless has a ton of depth. Thanks to Morgan, and I hope you enjoy this episode.

     

    [SPONSOR MESSAGE]

     

    [0:01:44.3] JM: To understand how your application is performing, you need visibility into your database. VividCortex provides database monitoring for MySQL, Postgres, Redis, MongoDB, and Amazon Aurora. Database uptime, efficiency, and performance can all be measured using VividCortex. Don’t let your database be a black box. Drill down into the metrics of your database with one second granularity.

     

    Database monitoring allows engineering teams to solve problems faster and ship better code. VividCortex uses patented algorithms to analyze and surface relevant insights so users can be proactive and fix performance problems before customers are impacted. If you have a database that you would like to monitor more closely, check out vividcortex.com/sedaily to learn more. GitHub, DigitalOcean, and Yelp all use VividCortex to understand database performance. At vividcortex.com/sedaily, you can learn more about how VividCortex works.

     

    Thanks to VividCortex for being a new sponsor of Software Engineering Daily, and check it out at vividcortex.com/sedaily.

     

    [INTERVIEW]

     

    [0:03:04.7] JM: For Software Engineering Radio, this is Jeff Meyerson. Morgan Wild is an iOS developer at Shoplandia. He is the creator of a YouTube video called A Brief Introduction to LLVM, which I found to be a very helpful resource.

     

    Morgan, welcome to Software Engineering Radio.

     

    [0:03:20.6] MW: Hey there, Jeff. Nice to be here.

     

    [0:03:22.2] JM: Today, we’re going to talk about the LLVM, and I want to have a general introductory discussion of some compiler stuff first before we get into what LLVM is, because it’s related to compilers. For people who are needing a refresher, what are the high-level steps that a piece of code goes through when it gets compiled down to binary ones and zeroes?

     

    [0:03:46.7] MW: Right. In a general sense, any kind of programming language has to end up looking like a machine code that a CPU can execute. Obviously, there’s a whole bunch of CPUs, and there’s a whole bunch of programming languages. There has to be something in the middle there to translate, so to speak, or compile the source into what a CPU would understand.

     

    A big step up from what we had before compilers, which was assembly language, which essentially was a human-readable binary code. We would just issue instructions and they were non-portable instructions. If you say worked on Intel, you can do ARM, or vice-versa. The compiler sort of created this abstraction layer over the machine language, or CPU instructions, by allowing us to program in a sort of more abstract programming languages where we worry about the logic, sort of the things that we want to see happen, rather than thinking about what to instruct the computer to do to get to that point.

     

    Any kind of source that you write in a language that is compiled, because there’re languages like Python, in PHP, and Ruby, that they are not compiled. They’re interpreted light. Any kind of compile language does have a necessity of having a compiler to translate that into machine language.

     

    First step is you take the source file and you basically just put everything into tokens. You just assign, do a syntax check whether the tokens check out and whether it’s legitimate piece of language, and you compile trees into trees from that and you get, essentially, an abstract non-readable format of your code that just scrapes all of your comments, your variable names, and all of that stuff.

     

    Depending on your architecture from that abstract form, sort of cleaned up form, there can either be a direct translation into one architecture or another. The term here is target. Any kind of CPU architecture you’re looking for is essentially a target. If you’re targeting an iPhone, you have to worry about instructions that are different when you would be targeting a Macbook, for example.

     

    If you’re directly compiling, like GCC, which is the new compiler collection, takes your C, for example, and just spits out machine code. Structures like LLVM create an intermediate representation of that code. It can optimize that code and deal all kinds of smart stuff that allows it to speed up your existing code. If you compile it, say, three years ago, you would compile it now and you get the speed up. That finally gets translated into machine-readable code.

     

    [0:07:15.7] JM: Absolutely. Let’s talk about the pre-LLVM world before we get into LLVM. You touched on this idea of the N by N language to process problem, where in a world without LLVM, you potentially can have this scenario where for each language and for each processor, you need an individual way of getting that language into a form that that processor can understand. Is that accurate?

     

    [0:07:49.1] MW: Yeah. It is a very big problem from, I guess, a few decades back, that prevented and stagnated the industry in that portability was pretty much nonexistent before Unix came along and created the POSIX standard. Before that, before POSIX, you had people building all these architectures and they didn’t share a whole lot in common. If you, as a programmer, required a simple task as reading from desk, you would have to abstract that part away yourself and take care of any number of architecture, because Unix does file read in one way, there’s one command, Windows does it differently and some architecture acts would do it, would do it differently.

     

    These things that have stagnated the industry to a point where Java, when it came out, was this massive savior for the whole market and that programmers started dreaming about the build one once and run everywhere launcher which is pretty powerful when you’re stuck in the world where you’re limited in that regard.

     

    [0:09:10.4] JM: Now, we’re going to get into LLVM in a sec. You mentioned Java, and you mentioned the degree of portability that Java added. Can you explain what that portability was and what were some of the result of people being inspired by the JVM model?

     

    [0:09:28.5] MW: Java is sort of this poster child of that build once and run anywhere movement that sort of later was transformed into the web architecture, or at least inspired the web architecture where, pretty much, you have this experience where you develop a website over a web service and you have the expectation of being able to run those anywhere. That came from Java, and JavaScript was sort of directly influenced by Java.

     

    What Java does is it takes your source, and LLVM and Java has this part in common where LLVM has the IR, or the intermediate representation, and Java has the bytecode. From that point on, they act different upon those two things, because what Java does is it distributes the bytecode and you run and you execute the last part of what a compiler would do, which is translate bycode into machine-executable commands runtime.

     

    There is an inherent lag in any kind of Java program where there’s like a two-second thing that needs to happen for the bytecode to be loaded on to what’s required for that architecture. Yeah, that simple fact of being able to carry that abstract to the form of your code in a form of bytecode and then compile it only when you run it, certainly does have its benefits.

     

    [0:11:04.4] JM: Right. I think where you’re getting at with this is that in the JVM ecosystem, you’ve got this bytecode, and the bytecode is this representation that’s not super low-level, it’s not super high-level, it’s somewhere in between, and because we have this bytecode representation, we can move it between different architectures and we can have the same predictable runtime experience on each of those hardware architecture.

     

    LLVM borrows from this in some ways, because of this intermediate representation that we’re going to get to. Let’s start simply. What is the LLVM?

     

    [0:11:49.0] MW: Back in the day when it was first formed, it was a step towards emulating the bytecode intermediate language between an executable code and source code, and it turned into this pretty massive effort that’s open-source and it’s a whole ecosystem of compilers and their tools and the thing that joins them together, the thing that all of them share, is the intermediate representation, or IR.

     

    Obviously, the man, or one of the two men that created LLVM is Chris Lattner. He later joined Apple specifically on that achievement. It was a graduate project. Most of us would dream of a graduate project that’s successful. Yeah, it turned into something that I’ve heard recently it’s able to C faster than GGC is able to do.

     

    They started off a lot slower than C, but their whole mission is to create an optimizer for their custom intermediate representation that is able to continually optimize the code to the point where it just gets better and better and better.

     

    [0:13:11.2] JM: Yeah. We’ll get into as much of the LLVM as we can, but this is — For listeners who don’t. This is a really big subject. Basically, before LLVM, compilers tended to have this monolithic structure. As you talked about in your YouTube, which I’ll have in the show notes, LLVM breaks the monolithic compiler structure into a series of steps. It breaks this structure into scanning, parsing, intermediate representation, the intermediate representation optimizer, semantic analysis, target code, and finally, compile code.

     

    We could get into any number of these steps in the compilation structure. As you said, the intermediate representation is really the area that we should focus on. What is meant by that intermediate representation? What does an intermediate representation mean and how do we get there?

     

    [0:14:08.5] MW: Sure. Before that, I do want to clarify that. You’ve mentioned seven steps here. They’re not unique to LLVM. In general, when you’re thinking about compilers, pretty much, all of them have the sequence of those six or seven steps. I want to stress that that’s not unique. LLVM did not invent that sequence. What it did was is it decoupled the IR from, essentially, what is the frontend. Meaning, parts of the compiler sequence that are concerned with a specific source, source code, source files, and the backend, which essentially is concerned with optimizing specific targets and then creating executables for those targets.

     

    The key unique thing that it did was it sort of separated IR from the sequence here. Pretty much, every compiler has that sequence, and pretty much, every compiler has that sequence in a modular-ish way within their own world, but none of them — Yeah, I feel like none of them — At least not the big ones. They don’t have the intermediate language as separate as LLVM has.

     

    [0:15:29.5] JM: Okay. Thanks for that clarification.

     

    [0:15:31.8] MW: Yeah, because any computer scientist that goes to the compiler class, you’ll sort of see the sequence, and it’s there. It’s not an invention that we can credit Chris Lattner with. To your question, IR is — It depends. Every system has its own IR, and it’s just a step that uses the optimization steps, which create the — The executables are speedy and affirming.

     

    What you have — In regular source code, as I mentioned in the beginning here, is soft of high-level structures. Let’s take Swift, for example, because that’s my favorite language. You have your classes, you have structures, you have functions and methods and all kinds of high-level stuff. Now, no processor operates on that level. Obviously, they don’t understand that.

     

    In between machine code, executable code, and source code, you have this assembly-like intermediate representation. When I say “assembly-like”, a lot of the people that deal with assembly languages can pretty much immediately feel accustomed to what’s going on in specifically LLVM IR. What you do there is — First of all, you don’t work with variables, you work with registers.

     

    To that point, so that the biggest difference from any kind of assembly language is registers are mutable. By that, I mean, when you have your REX register, you just put stuff into it or you take stuff out of it. You read from it. It’s a constantly changing state. It’s a physical register that just constantly is mutating. Any number of parts within your code can change that. Being able to optimize any kind of dynamic data is a lot harder than optimizing something that’s immutable. IR for LLVM, has immutable registers, which is essentially just an unlimited sequence of let or const declarations that you do.

     

    [SPONSOR MESSAGE]

     

    [0:18:09.3] JM: You are building a data-intensive application. Maybe it involves data visualization, a recommendation engine, or multiple data sources. These applications often require data warehousing, glue code, lots of iteration, and lots of frustration. The Exaptive Studio is a rapid application development studio optimized for data projects. It minimizes the code required to build data-rich web applications and maximizes your time spent on your expertise. Go to exaptive.com/sedaily to get a free account today.

     

    The Exaptive Studio provides a visual environment for using back end algorithmic and front-end component. Use the open source technologies you already use, but without having to modify the code, unless you want to, of course. Access a k-means clustering algorithm without knowing R, or use complex visualizations even if you don’t know D3. Spend your energy on the part that you know well and less time on the other stuff. Build faster and create better. Go to exaptive.com/sedaily for a free account.

     

    Thanks to Exaptive for being a new sponsor of Software Engineering Daily. It’s a pleasure to have you onboard as a new sponsor.

     

    [INTERVIEW CONTINUED]

     

    [0:19:42.0] JM: Okay. Let’s go through a simple example. Let’s say we had a program that we wrote in Swift. As you said, this is one of the favorite programming languages of today, of 2017. I think there was a Stack Overflow survey recently that said this was the favorite language of programmers on Stack Overflow. This is a language that is used to develop most iOS apps these days.

     

    Let’s say we wrote a Swift app that was just X = 5, Y= 2, and Z = X + Y.

     

    [0:20:16.1] MW: Sum — Yeah.

     

    [0:20:16.9] JM: Yeah. Then, print the sum, or something. If wanted to say, “Let’s compile that and run it.” Maybe you can explain what happens to get to the intermediate representation point, and what’s going to happen with those registers in the intermediate representation and optimization step.

     

    [0:20:36.6] MW: First of all, when you’re tokenizing your source, say that X = something like or something. Swift does a beautiful thing, which is called type inference. You don’t need to write int, or float, or whatever. That step is required for the complier to allocate the correct number of bytes and sort of be able to deal with the underlying data.

     

    What the first few steps do is they position everything that you’ve declared into sort of stack frames, and the stack frame is just concerned what tokens are you able to access within that stack frame and what tokens will you be able to access from shielding stack frames. At that point, what you do is you get the token identifier, which is X, or Y, or Z, and then you get the type, and then you get the current value for that thing.

     

    Something as simple as sum — And this is one of those points that I showed in the presentation, is you take those types and you convert them into IR types. Obviously, you don’t have structures or classes, but you have pretty advanced types like function pointers, and all kinds of numeral types, and functions, and all of that stuff, which is definitely a lot higher than what you would get with assembly-like languages.

     

    Every single declaration of a register has to be preceded by a type, so there’s no type inference. Yeah, you got your X and your Y and they can be translated into anything, but all those identifiers will start a percent sign and let’s say percent one, percent two, would be your X and Y and they will probably have an integer type, let’s say integer 64, depending on the architecture, of course, or 32.

     

    Like with any register, you’d be able to issue the ad command. The only difference in terms of commands here, since your registers are immutable. It’s very much a functional language. Any kind of result from an operation that mutates data or potentially would mutate data, it’s just a return value. When you would add stuff in assembly-like languages, you do like ADD and then one register and another register. You won’t be able to do that here. You wouldn’t have to assign that value to another register, to a new register. Yeah, that’s addition.

     

    The only difference here would be you take the plus sign, you turn that into ADD. You add the type identifier, and your two sort of values — Not too big of a deal when it comes to simple math.

     

    [0:23:44.2] JM: It sounds like there’s not much optimization going on in this example. Is that right?

     

    [0:23:48.4] MW: There’s zero optimization.

     

    [0:23:51.3] JM: What kind of things will we need to add to this code in order to illustrate the optimizer?

     

    [0:23:57.8] MW: Let’s say Y would be zero. Your X is two, your Y is zero, and you’re adding these two numbers and you’re using the sum. If you’re defining value with just a numeral, you could optimize that out yourself. Often times, when value is defined in a static let somewhere in a struc that is far away, you don’t see the value. These things easily happen. It’s one of the most popular optimizations here.

     

    What a processor would do is you’d waste a couple of instructions, at least, to do that non-operation, essentially, because adding zero to anything does not change the value. To save those couple of instructions, a couple of cycles, IR looks for common patterns. The sequence of patterns is constantly updated and it’s a growing list. It obviously differs by the types that you’re dealing with.

     

    Say, any kind of any numeral type would have plus zero equals the same value. You can optimize that out. Times one, the same value, you can optimize that out. All that mathy stuff, you can optimize out. The way it works is deep in the C++ that’s dedicated for LLVM, there is a split, a branch, depending on what kind of operation you’re doing, that takes you to a for loop that iterates through all the possible optimizations for a specific — I forgot what the sequence is called. But for a specific sequence of code, which his essentially any kind of operation, that add would be one example, move would be another example.

     

    It loops all the possible options there, and it applies the optimization and assigns the result to a temporary variable, and then it checks, first of all, whether there’s no errors that are introduced by that change and whether there’s any value gain from that operation. Then, if that’s true, that gets substituted into the original code.

     

    [0:26:26.4] JM: You’re saying that when I compile my Swift code, after it gets translated into the intermediate representation, there is a tree of possibilities that are created to attempt to see. Is there a way to represent this same code in a more concise fashion than the original naïve intermediate representation that we’ve created? Is that right?

     

    [0:26:58.1] MW: Yeah. First of all, you should probably never deal with IR directly, and — The first stop is sort of the naïve translation, a verbatim of what you see in your source file into IR. Only then can you do the optimization, because then you’re dealing with immutable registers and a structure that inherently is more accessible to scans like that.

     

    [0:27:28.8] JM: If we’re looking at all these different potential configurations of our code, that sounds like something that would be really, really time intensive, especially for complex programs.

     

    [0:27:39.1] MW: If you remember, when Swift came out, compiled times for something that was bigger than a few view controllers, they were pretty big. You’re right, it does take time to optimize the optimizer for a specific frontend. The main thing here is that any kind of performance gains from, say, someone working on optimizing C, and obviously, to optimize C, you have to go through LLVM IR and do some clever optimizations over there.

     

    Guess what? Those same optimizations translate to any frontend that gets compiled down to IR. People that are working on these — I don’t know what’s the number of languages that have frontends to LLVM IR, but it’s pretty big, and some of the languages are very well-used. Those optimizations get shared.

     

    [0:28:37.2] JM: Right. I want to eventually get to the modular part, but a little more on this intermediate representation optimization stuff. I am reminded of the Deep Blue, the IBM Deep Blue stuff, because this was the chess computer, where given any chess scenario, Deep Blue would look at all of the potential decisions spaces that you could potentially go down and play out the entire chess game down that part of the decision tree.

     

    It sounds like the intermediate representation optimization is that level of complexity, because if you’re looking at the entire tree of possibilities for different ways that your code could be arranged, that to me, in a complex program, that sounds like it is just too much work. Is that accurate, or is it just — Is it possible to break down?

     

    [0:29:35.3] MW: I wouldn’t say — In a way, it is just and that you end up looping over the entire sequence of this specific optimization, but you’re not looping for every existing optimization for each line of code, or each operation, and operation is the atomic unit there.

     

    First of all, what you’re doing is you’re putting that existing operation and the existing variables into a specific slot and niche. That alone reduces your problem space significantly. Obviously, when you reduce your problem space, you’re not dealing with what’s the chess board total probable moves when you start a game — Trillion? I don’t know what that is.

     

    You’re not dealing with anything of that scale, because you have this inherent step of you take an operation and then you take out the existing identifiers, the values there, and then you only go through the appropriate optimizations for that. There’s, obviously, predictive stuff going on there which I’m not in depth on. From what I know, it is certainly not enumerating everything that you can possibly think of.

     

    [0:31:05.7] JM: This certainly sounds like a problem that could be assigned across multiple threads, because if you’re testing these different —

     

    [0:31:13.1] MW: These are super parallel. When you’re dealing with optimizations, you’re optimizing each individual operation. You’re not optimizing in terms of multi-operational sequences. The parallel nature of this whole thing is very great. Yeah, absolutely.

     

    [0:31:32.6] JM: When you say operation, maybe this is a naïve question, but what do you mean? What is an operation?

     

    [0:31:38.8] MW: For example, add one register to another.

     

    [0:31:42.8] JM: Can you explain some other examples of operations? I guess I’m having trouble understanding where — Add one variable to another. That doesn’t sound like something where there would be that many different configurations to test. Maybe you can help me clarify that.

     

    [0:32:01.2] MW: There can be a whole bunch of them. Obviously, you have your load and store. You have your control transfer ops. You have your type conversion ops, like when you’re adding —

     

    [0:32:15.0] JM: You’re illustrating add as a fairly high-level operation that gets translated into a bunch of low-level operations.

     

    [0:32:21.5] MW: No. Add is as low as it gets.

     

    [0:32:24.5] JM: Okay.

     

    [0:32:25.3] MW: Yeah. There’s nothing that —

     

    [0:32:27.4] JM: Oh, I see. You’re talking about other operations that add —

     

    [0:32:30.4] MW: Other sort of equivalent parallel operations.

     

    [0:32:35.0] JM: Right. Load and store — Maybe explain what a load and store operation is.

     

    [0:32:39.9] MW: Loading is reading from a register, and storing is a writing type register.

     

    [0:32:45.6] JM: Okay. That’s an example of something that you could see being optimized if it was tested in different —

     

    [0:32:52.8] MW: I will say you’re reading a value and assigning that to another value without any kind of mutation. An optimization would be anywhere you’re using the variable that you’re — The identifier that you’re assigning to. You can just replace with the identifier that you will be assigning in. If it’s a constantly, obviously, there’s — If it’s a variable that can mutate the underlying value, you can’t do that. If it’s a constant and you’re assigning just that, basically, creating an alias, you can optimize that out.

     

    [SPONSOR MESSAGE]

     

    [0:33:40.3] JM: For more than 30 years, DNS has been one of the fundamental protocols of the Internet. Yet despite its accepted importance, it has never quite gotten the due it deserves. But today’s dynamic applications, hybrid clouds and volatile internet demand that you rethink the strategic value and importance of your DNS choices.

    Oracle Dyn provides DNS that is as dynamic and intelligent as your applications. Dyn DNS gets your users to the right cloud service, CDN, or data center, using intelligent response to steer traffic based on business policies, as well as real-time internet conditions, like the security and performance of the network path. Dyn maps all internet pathways every 24 seconds via more than 500 million traceroutes; the is the equivalent of 7 light years of distance or 1.7 billion times around the circumference of the earth. With over 10 years of experience supporting the likes of Netflix, Twitter, Zappos, Etsy and Salesforce, Dyn can scale to meet the demand of the largest web applications.

    Get started with a free 30-day trial for your application by going to dyn.com/sedaily.  After the free trial, Dyn’s developer plans start at just $7 a month for world-class DNS. Rethink DNS. Go to Dyn.com/sedaily to learn more and get your free trial of Dyn DNS.

     

    [INTERVIEW CONTINUED]

     

    [0:35:13.1] JM: Okay. You’re giving an example where you take a load and store operation and you test different ways of doing it. You might get memory savings. You might get time savings based on variable reuse, for example.

     

    [0:35:28.1] MW: Yeah. Any kind of variable that you don’t have to assign is a variable that you don’t have to get space from you stack for, is a variable that you don’t have to de-allocate the memory for. It’s always a plus to having fewer —

     

    [0:35:45.0] JM: Cool. Before we hop out of the super lower level stuff and talk about some of the flashier characteristics. We talked about this load and store. Just to close the loop for something people who may not like load and store. That doesn’t sound like anything I use in my programs. Can you just illustrate —

     

    [0:36:00.7] MW: That’s enough.

     

    [0:36:01.3] JM: Yeah. What will be a higher level line of code that might end up translating to a load and store operation?

     

    [0:36:07.4] MW: Assigning a variable from another variable would be an example of a load and store. Any kind of an assignment, it’s a single operation in Swift. You just do A equals B, but there’s an abstracted command, even in assembly, called move, which essentially does two things. You can use move from memory to memory. Anything that’s on the stack, you can move things from the stack, or within the stack. If you’re dealing with registers, there are certain instances where you would have to sort of read from a register, put that into memory, then take that memory and read it into — And write it into another register where you can do a flip. You would need to load and store that type of thing.

     

    This is something a programmer would never interact with in their daily life, because, thank God, these things are abstracted away and all we deal with is a few controllers and transitions and all that beautiful stuff.

     

    [0:37:12.7] JM: You’ve given us a beautiful, I think, from the top to intermediate representation explanation, and I think your earlier conversation sort of gave people a picture of what happens after the intermediate representation. It goes down to machine code, and there a process or stuff that happens. If people want to know more about that, they can look into how compilers work, or basically what happens after the intermediate representation.

     

    I want to talk more about why this intermediate representation is a big deal, because, essentially, if you can get any piece of code into the intermediate representation, the intermediate representation can do a lot of optimizer work, and we can have an open source collective working on the intermediate representation and driving gains for any of these other languages that can compile down into the intermediate representation. We’re talking about Swift, and Rust, and anything else.

     

    Maybe you could talk about what are the challenges that a language has to overcome in order to be able to convert into this intermediate representation?

     

    [0:38:25.0] MW: That’s all beyond what I can contribute. It’s a topic that I know a lot of people go through when they think about doing a hobby project of a sort of language, and most of them pick LLVM IR as a way to compile it into executable code, toy languages.

     

    [0:38:48.3] JM: Fascinating.

     

    [0:38:49.8] MW: From what I heard, it’s one of the easier, or probably the easiest, or maybe even the only viable option there when creating a new language. Whether the audience would be just you or even if it’s bigger.

     

    [0:39:04.6] JM: Maybe eight years ago, people might have said, “I want to write a new language,” and they write Scala, and then they say, “Okay. I want this language to compile down to a machine, so I’m going to write it for the JVM, or I’m going to write it to compile down to bytecode.”

     

    [0:39:18.0] MW: Most likely, what they would do is translate that into C, then just use GCC to their compilers to get the machine code. I think Haskell has this attribute where their functional programming source gets translated into C, super unsafe C, and that gets transferred on to a machine code.

     

    [0:39:43.6] JM: Ah! You’re saying, that in the past, people might have used C as the interoperability layer. Whereas today, we can do LLVM.

     

    [0:39:53.7] MW: It’s very important to say that GCC is the bid dog here, and I think it’s still is, since it’s been going for, I don’t know, 50 years now, 40. Who knows? It’s a super massive project, and inherently, it has a lot of optimization. Whether they’re good or bad, whether they’re modular or not, you can produce super quick executables with GCC. All you need —

     

    When you think about intermediate languages, you think low-level memory access, CPU instruction access, and you get a lot of that with C. Tweak it a little bit and you can get to run memory. A lot of these embedded systems use C as their sort of interface language.

     

    C, inherently, has a lot of properties that IR has, and so it was sort of a natural use for the language until something came out that have the sole purpose of being in the middle. C does still take up that a little bit, but, obviously, it’s being phased out by tools that were made specifically for that task.

     

    [0:41:09.5] JM: Safety is something that I have heard. You’re not the first person who I’ve heard mention C is somewhat unsafe if you want to build a systems level language, and Rust is something that I’ve heard is a language that has some safer properties than C. Perhaps, some of that is due to being able to be built on top of the LLVM, on top of the intermediate representation. Is there some notion of safety that is built into the intermediate representation?

     

    [0:41:43.6] MW: No, because when you think about safety, you don’t think about the language itself most often. What you think about is things that people build with the language. You have a human component there to abuse safety and turn it into something that’s unsafe.

     

    For example, a lot of people are taught C and when they go through sort of the initial tutorials, they see how to read and write data from the terminal. Obviously, that’s been outdated for God knows how many years, and it’s no longer safe to do it that way.

     

    When it comes to safety, either you’re using a framework that someone wrote that’s a systems engineer, or a compiler designer, and it’s unsafe, because it’s using some part of the language unwisely. You’re responsible for your own code and you don’t know something, or you have a leak, or you don’t check input, or something like that, and you create unsafe programmers. The intermediate representation does not, in and of itself, create safety issues, because the loop is pretty much closed there. You have that with higher level stuff.

     

    [0:43:01.9] JM: I jumped the gun on talking about Rust. What is Rust able to leverage from the LLVM?

     

    [0:43:10.2] MW: That’s as far as I know in terms of Rust. It’s using the backend for the source. It’s created by the open-source community and they worry about the definitions there and how to organize the language. The part that is the most difficult in optimizing with that would require the most resources is the backend, or how to make code run quickly on Intel, on other architectures other than X86.

     

    That’s where you get the build-in benefits from LLVM by using their backends for — I think they have backends for pretty much every single platform that’s big, definitely ARM and x86. That’s pretty much allows you to reach that whole market.

     

    If you’re developing any hobby language — And Rust is still at a point where — In most cases, I might be ignorant to any kind of big existing project that uses Rust as their main language. I haven’t heard of any at this point.

     

    [0:44:20.3] JM: Dropbox.

     

    [0:44:21.0] MW: Really? I heard they’re Python-driven mostly.

     

    [0:44:23.9] JM: I think that Dropbox — I think Dropbox is Rust. Anyway, sorry to interrupt you. Yeah, I’m pretty sure that — They moved off of the cloud recently. When they moved off the cloud, they rewrote a lot of stuff. I think that they used Rust. Anyway, I’m sorry that I interrupted you.

     

    [0:44:43.7] MW: There’s probably parts — Any kind of startup. Even individual developers have tools that they write. I think I deal with five different languages on a daily basis pretty much, and that’s just because you use different tools for different purposes.

     

    Regardless of that fact, it’s still a very nascent language, and you either dedicate your resources, and that’s probably the whole point of having these beautiful projects like LLVM, is that people can now work on things that there are the best at, or at least try to be the best at one specific part.

     

    With LLVM, Rust people don’t have to worry about being good, Intel architecture people, or ARM architecture people. They just need to worry about how to deal with memory and how to deal with a good structure, and so that it focused on the frontend. That’s a big picture commentary. I wouldn’t be able to do more than that.

    [0:45:48.9] JM: We talked about JVM versus the intermediate representation layer a bit, and Java Virtual Machine. LLVM stands for low-level virtual machine. I probably should have mentioned that earlier.

     

    [0:46:02.4] MW: No. It doesn’t stand for that anymore.

     

    [0:46:04.4] JM: Oh! That’s right. It used to. Yeah, now it’s just LLVM.

     

    [0:46:08.7] MW: It’s like BMW is BMW. You don’t enumerate what each letter means.

     

    [0:46:16.7] JM: Anyway. Where I was going with that was that there is an analogy to be drawn, because in the Java bytecode ecosystem, you have this shared layer, the JVM bytecode layer where people — People will have a big Ruby on Rails application. When they hit a performance bottleneck, they will switch to JRuby, which is a version of Ruby that runs on the Java Virtual Machine. Basically, as I understand, JRuby is Java, so you can compile Ruby to JRuby and then JRuby runs on the JVM, the Java bytecode, so it runs faster. You get to take advantage of those bytecode optimizations.

     

    Similarly, we’ve got this intermediate representation that we’ve been talking about where Rust can compile down to it. Swift can compile down to it, and we have these optimizations that are shared on a platform. How do the optimizations of — How does the Java — I should ask a bigger question. How does the Java bytecode ecosystem compare to the LLVM intermediate representation ecosystem today? How would somebody choose between writing their language to compile to Java bytecode, versus compiling to intermediate representation?

     

    [0:47:29.8] MW: To some extent, they are different animals, you can do an apples to apples comparison, because they take a different niches, I think. IR is substantially lower level than what you would get with bytecode. Meaning, even though IR is isomorphic and that you can translate it to bitcode, which is a super tight version of what those operations and commands look like to a human-readable IR, and memory storied IR.

     

    Human-readable IR is not source code that a person would be able to tell just skimming through it what the program does. Whereas JVM bytecode, you can actually take it and — It’s isomorphic to the source level. What you have is even though you lose the original identifiers, and that can take away some part of the meaning, or in some instances, a lot of the meaning. You still have a line-for-line representation of what the source code look like.

     

    That is probably the major different there. By the way, you can check that difference by just inquiring into — I know this for a fact. You can do that on Android Studio, so any kind of Intellij IDEs, where you can open up libraries that are compiled into bytecode and you can look through the actual Java code without the identifier names and all of that, but you can still look through it. Whereas IR does not have that quality.

     

    [0:49:16.2] JM: I want to begin to close off and just talk about where the LLVM ecosystem is at today. As you mentioned, LLVM was originally just called the low-level virtual machine. That’s what it stood for. Now, today, it’s called LLVM. It’s literally just called that, because it’s representing a larger ecosystem of compiler tools. Can you explain —

     

    [0:49:38.4] MW: Specifically — Sorry. The bigger parts would probably be the linker, LLD, and LDB, which is the debugger. If you’ve worked on Xcode at all, you would see LDB messages pretty often. When you add break points and stuff, that’s when you’re dealing directly with another piece of the LLVM architecture. That’s the debugger. Those three parts are probably the biggest, if you abstract away IR.

     

    [0:50:09.0] JM: Is that debugger — I guess that’s running — What happens is you compile your code, it goes to the different — It goes to the intermediate representation. It gets optimized, and then it runs, and then you are debugging against the intermediate representation that was settled on after the optimization. Is that right?

     

    [0:50:30.8] MW: You’re debugging against live code, but that code is obviously annotated, so that you can have access to the code that you’ve wrote in Swift, for example. It’s not like a stripped-down version. Any kind of debugger adds a layer to the intermediate executable code that can transfer some data.

     

    When you exhaust that, you often times are taken to IR, or some form of IR. Then, you just see a whole sequence of registers within a specific stack frame, and then God help you finding what went wrong there. The LDB debugger takes care of that specific part.

     

    In the Apple ecosystem, you probably don’t veer too far from the entire sequence there, because you’re linking your stuff with the LLVM linker against your static dynamic libraries and you’re debugging with your debugger. Yeah, Xcode is very much reliant on LLVM.

     

    [0:51:39.6] JM: Okay. I want to wrap up with one — I want to make one quick point, I guess. That people who are, maybe, new to thinking about compilers, the reason we’re spending so much time talking about this optimization stuff and why this is so important is because if you can spend a lot of time automatically optimizing your code, then every end user who is executing that code gets to take advantage of the optimization. Even though the developer who is compiling the code might have to wait around while the different intermediate representations are being tried. Once it settles on an optimal one, all of the end users who are actually executing that code gets to take advantage of the optimizations.

     

    With that in mind, is that the main thing that the ecosystem is focused on? When we’re looking at the future of the LLVM and the things that are going to develop out of this ecosystem, what should we expect? Should we just expect more optimizations that are going to be made on the intermediate representation level, or better debugging tools, or is there something bigger that is being worked towards?

     

    [0:52:43.5] MW: I’m pretty sure what you’ve mentioned would be a good characterization for it. Essentially, what LLVM allows you in the future, I guess, you can probably see more and new exciting different languages being created, because you don’t have the inherent bottleneck of worrying about sort of how that thing works on the different systems. That’s one possible outcome.

     

    You’ll have a lot of frontend sharing their optimizations between each other. That’s a big boom for the industry, because those resources are very valuable. Whenever you can share or collaborate with other people, that is a great, great benefit.

     

    Yeah, it’s going to be interesting to see what happens with the collection of tools here when Chris is no longer with Apple and no longer working actively on maintaining, as he was the primary person there since he moved to Tesla. It’s going to be interesting how they’re going to deal with the future related stuff come WWDC this summer.

     

    [0:53:55.5] JM: Okay, Morgan. Is there any social media plugs that you’d like to give for people who would want to follow you? What are the best ways to follow you?

     

    [0:54:04.8] MW: I use Twitter, and you can fine me @wildemorgan, last name, first name, on Twitter.

     

    [0:54:11.7] JM: Okay. All right. Morgan, thanks for this illuminating discussion of LLVM. I think you gave a really clear explanation. I liked it that we were able to dive deep end, go higher level, and I recommend to anybody who’s looking for further information on this check out your YouTube video, which is only about 30 minutes long. That’s why I liked it so much, is that it was concise and yet deeply informative. Thanks for producing that.

     

    [0:54:37.4] MW: Yeah, I was a love child, I have to say. It took probably three weeks to get the thing together. 20 minutes. Yeah, you can have a pretty good refresher on not only LLVM, but the whole ecosystem for compilers.

     

    [0:54:53.5] JM: All right. Morgan, thank you for coming on Software Engineering Daily.

     

    [0:54:56.6] MW: Thanks for having me, Jeff. It’s been a pleasure.

     

    [END OF INTERVIEW]

     

    [0:55:02.7] JM: Thanks to Symphono for sponsoring Software Engineering Daily. Symphono is a custom engineering shop where senior engineers tackle big tech challenges while learning from each other. Check it out at symphono.com/sedaily. Thanks again Symphono.

     

    [END]

     

     

    Share this:Click to share on Twitter (Opens in new window)Click to share on Facebook (Opens in new window)Click to share on LinkedIn (Opens in new window)Click to email this to a friend (Opens in new window)

    Related

    https://softwareengineeringdaily.com/2017/04/10/llvm-with-morgan-wilde/

    —Huffduffed by maicki

  8. The Future of React Native with Brent Vatne and Adam Perry | Software Engineering Daily

    http://traffic.libsyn.com/sedaily/FutureofReactnative.mp3Podcast: Play in new window | Download

    React Native has unlocked native mobile development to web engineers who may now apply their skills to build iOS and Android applications in JavaScript. For the first time, cross platform JavaScript-based applications feel as if they were written in the native language of choice for the platforms.

    Businesses who choose to adopt React Native for their native app development also see great benefits such as the ability to push new JavaScript code without going through the app store review process, and the ability to share code and business behaviors across the iOS and Android platforms.

    Expo is building a cross-platform native runtime for React Native. Expo brings the benefits of deployment and iterative development to native without sacrificing any user experience costs. Expo plans to do this with their native SDK, custom development environment, and tools built in collaboration with Facebook like create-react-native-app.

    React Native has the incredible potential to revolutionize all user interface development with its core set of cross-platform UI primitives, and React’s popular declarative rendering pattern. So in this episode Brent Vatne and Adam Perry join Caleb Meredith to first discuss Expo and the future of React Native to try and answer the question: can React Native become the one UI framework to rule them all?

    Sponsors

    Oracle Dyn provides DNS that is as dynamic and intelligent as your applications. Dyn DNS gets your users to the right cloud service, CDN, or data center, using intelligent response to steer traffic based on business policies, as well as real-time internet conditions, like the security and performance of the network path. Get started with a free 30-day trial for your application by going to dyn.com/sedaily.  After the free trial, Dyn’s developer plans start at just $7 a month for world-class DNS. Rethink DNS. Go to dyn.com/sedaily to learn more and get your free trial of Dyn DNS.

    SparkPost provides email delivery services for apps and websites with offerings from free, self-service start-up accounts to sophisticated enterprise support and services. Try SparkPost and send 100,000 emails/month for free at http://pages.sparkpost.com/sedaily 

    Incapsula can protect your API servers and microservices from responding to unwanted requests. To try Incapsula for yourself, go to incapsula.com/sedaily and get a month of Incapsula free. Incapsula’s API gives you control over the security and performance of your application–whether you have a complex microservices architecture or a WordPress site, like Software Engineering Daily. Incapsula has a global network of over 30 data centers that optimize routing and cache your content. The same network of data centers that are filtering your content for attackers are operating as a CDN, and speeding up your application. To try Incapsula today, go to incapsula.com/sedaily and check it out.

    Transcript

    [INTRODUCTION]

     

    [00:00:00] JM: React Native has unlocked native mobile development to web engineers who may now apply their skills to build iOS and Android applications in JavaScript. For the first time, cross-platform JavaScript-based applications feel as if they were written in the language of choice for the platforms. Businesses who choose to adopt React Native for their native app development also see great benefits, such as the ability to push new JavaScript code without going through the app store review process and the ability to share code and business behaviors across the iOS and Android platforms.

     

    Expo is building a cross-platform, native runtime for React Native. Expo brings the benefits of deployment and iterative development to native without sacrificing any user experience costs. Expo plans to do this with their native SDK, their custom development environment, and tools built in collaboration with Facebook like Create React Native App, which is discussed in today’s episode. React Native has the incredible potential to revolutionize all user interface development with its core set of cross-platform UI primitives and React’s popular declarative rendering pattern.

     

    So in this episode, Brent Vatne and Adam Perry join Caleb Meredith to discuss Expo and the future of React Native, and try to answer the question; can React Native become the one UI framework to rule them all?

     

    [SPONSOR MESSAGE]

     

    [00:01:39] JM: For more than 30 years, DNS has been one of the fundamental protocols of the Internet. Yet despite its accepted importance, it has never quite gotten the due it deserves. But today’s dynamic applications, hybrid clouds and volatile internet demand that you rethink the strategic value and importance of your DNS choices.

    Oracle Dyn provides DNS that is as dynamic and intelligent as your applications. Dyn DNS gets your users to the right cloud service, CDN, or data center, using intelligent response to steer traffic based on business policies, as well as real-time internet conditions, like the security and performance of the network path. Dyn maps all internet pathways every 24 seconds via more than 500 million traceroutes; the is the equivalent of 7 light years of distance or 1.7 billion times around the circumference of the earth. With over 10 years of experience supporting the likes of Netflix, Twitter, Zappos, Etsy and Salesforce, Dyn can scale to meet the demand of the largest web applications.

    Get started with a free 30-day trial for your application by going to dyn.com/sedaily.  After the free trial, Dyn’s developer plans start at just $7 a month for world-class DNS. Rethink DNS. Go to Dyn.com/sedaily to learn more and get your free trial of Dyn DNS.

     

    [INTERVIEW]

     

    [0:03:10.3] CM: I’m here with Brent Vatne and Adam Perry who work on Expo, a framework that helps JavaScript developers build native iOS in android applications. Brent and Adam, welcome to Software Engineering Daily.

     

    [0:03:20.8] AP: Thanks for having us.

     

    [0:03:22.4] CM: All right. First, I want to talk about Expo. We have had many cross-platform tools that allow developers to write web apps that can be used as a mobile app. Is the application experience of a web app so different than a mobile app that there is a tension that cannot be resolved in some of these previous cross-platform tools?

     

    [0:03:42.3] BV: I can take that one. I think that there are a few things that maybe need to be discussed about the differences between some of the other solutions that are available for the same problem and whether or not the approach of taking web applications and making them into mobile applications is a viable strategy.

     

    I think that some of the other solutions that have existed before have been, in many ways, trying out ideas and approving concepts that ultimately led to React Native. This is something like Expo as a result of that. Things like Titanium, which as far as I know were the first ones to pioneer the idea of having some app code running in JavaScript and sending any updates over the bridge in order to update some native UI.

     

    This was the concept that existed well before React Native itself. Even through Cordova or Phonegap, there was a way to communicate over the Cordova Bridge, which was admittedly more simplistic but the same idea where you have some app code running in this language that’s shared across platforms that then sends some commands over to a native side in order to either call into APIs such as open a camera or even APIs create a view and position it here on the screen.

    This is something that, I think, it’s just grown over time. As for whether or not web applications can or fundamentally at odds with the idea of creating a mobile application, I don’t think that is necessarily true. I just think that with the current state of tools that exist for the web, it’s very difficult. You hit a ceiling at some point where you just can’t take the UI any further. You can’t handle gestures any better. You can’t do it in a cross-platform way due to a lot of discrepancies around how different browsers handle certain events or support or don’t support different things.

     

    It’s less of an idea of it not being theoretically possible and more. I think that it’s just not practically possible right now, if that makes sense.

     

    [0:05:57.7] CM: Yeah, of course it does. React Native is an incredible tool that solves a lot of these problems and ultimately empowers web developers to build applications for iOS and Android that feel as if they were written in the native language for the platform because of bridge technologies. What aspects of React Native make it difficult to use and therefore warrant Expo’s existence?

     

    [0:06:21.9] BV: Adam, you want to take this one?

     

    [0:06:23.6] AP: Yeah. I think there are a number of categories of problems that people run into when using React Native on its own without using Expo’s tools. Most of them are in some way related to the effort required to configure, build, and manage updates to the native code in a React Native project.

     

    When you compare the iteration cycle of React Native to the web, once you gotten up and running with React Native, it tends to be quite strong but there are a number of headaches associated with getting to that point where you can be iterating quickly on your UI. Somebody thinks they’re just initial startup problems, xCode in Android studio, especially for beginners, are really difficult to wrangle.

    Then even for experts, there are ongoing issues with tracking the stability of React Native’s native header files and APIs for accessing the bridge. Keeping whatever set of open source native modules you’re relying on up-to-date and in sync with your project can be quite a challenge for a lot of teams.

     

    Finally, writing your own native modules to begin with is it’s not nearly as well-documented right now at least compared to the JavaScript APIs. The training, the tooling, and the culture around React Native are very much focused on working in JavaScript, and so it can be very difficult when developers want some native primitive available to them but don’t have the expertise or bandwidth or resources to dropdown to that native code and build their own native APIs.

     

    A number of these problems are ones that we attempt to solve at Expo. We provide a curated set of native modules that we’re growing that list and trying to offer the primitives that people can work with in JavaScript so they don’t have to dropdown to native code. We also handle all of the native build and configuration as part of the Expo client app that loads your JavaScript directly, so you don’t have to manage or configure or manage updates to the native part of your React Native Application.

     

    [0:08:34.5] CM: What are some of the native modules Expo provides to its users?

     

    [0:08:38.4] AP: We have a whole lot actually. They range from more or less what you’d expect like an image picker API that’s cross-platform. I should mention also that cross-platform APIs is something we prioritize so that developers don’t often have to worry about the platform differences.

     

    We also have GPS and video, and we’re building on audio API right now. We also have some slightly more exotic things. We have a very interesting end novel OpenGL implementation that’s compatible with WebGL. You can use three JS inside of Expo, and it works as it would on the web. It’s fundamentally operating directly on the native OpenGL APIs. Then, we have a whole list on the Expo documentation.

     

    [0:09:19.6] CM: I think a few more worth highlighting there, because just going back to the original explanation. One of the key things about Expo, I think, is that it just makes you productive out of the box as soon as possible. Whereas, when you’re just using React Native on its own, there’s a lot of overhead for learning how to configure an ex code or android project for how to get it somewhere where you can actually share with your teammates or other stakeholders, all sorts of things like that.

     

    Part of this is, we’ve identified, there are things that people just need from most apps. Some of these are Facebook login, for example, or Google login, and then we also just provide a generic wrapper around some platform-specific model web browsers. Going a little bit into detail about the APIs, it’s called SFSafariViewController on iOS and Custom Chrome Tabs on Android. What that does is it shares cookies with your actual browser app so that you’re able to easily implement OAuth and things like maps, which are very common.

     

    These are all sorts of things that you can, for the most part, just install in an existing or rather a new React Native App that doesn’t use Expo, but it just adds on all of this work involved with actually figuring out which one you should use out of these libraries that exist in the ecosystem, keeping it up-to-date with everything. The various kinds of configuration that are involved with that, that it turns out, if you’re coming from a web background, it can be pretty overwhelming when you need to start up a new project and add all these things in and learn so much at once. We’re just hoping to make the experience ultimately a lot more web development, where you just create an app and load it into this client and start working on it and you have the APIs that you need to build your app available to you right away. That, I think, summarizes it pretty well.

     

    [0:11:09.7] BV: Yeah, I think one other piece in addition to the develop tooling, the native modules that I would add is that we’re building up a number of services to make it significantly easier for people to leverage actual native-specific technology. We’re not shooting for parity with web applications, but we have a push notification service where you interact through JavaScript with our API, or with the notifications that are coming on the device, rather, and you have full control there, and we also have build services so that when you want to publish to the app and play stores, you just — Just a few commands on your command line and you have an IPA file to download and upload to iTunes Connect. Which really streamlines across us for a lot of people.

     

    [0:11:54.8] AP: Yeah, just one follow up to that. In case we missed anything here, you can check it out on Slack Overflow. We’re answered this question and it’s probably phrased more eloquently than what we’ve managed to put together on this box. Yeah, check that out.

     

    [0:12:11.7] CM: Yeah. I think you explained it quite well. Having those primitives are especially useful for JavaScript developers who are not familiar with the web platform. Saying that, one of the real powers of React Native is that even though it allows you to primarily write your app in JavaScript is that when the JavaScript is perhaps too slow or you need a native API that Expo or React Native doesn’t provide, you can jump down to that lower level and write a native module. Expo provides a bunch of native modules on its own, but is also discourages users from writing their own native modules or bringing in custom-native modules from the NPM ecosystem that aren’t available in Expo.

     

    Why would Expo discourage this functionality?

     

    [0:12:55.7] BV: I think the main reason for discouraging it is just that it limits a lot of the services that can be provided around Expo. Things like handling your builds for you or having an easy way to, immediately, as soon as you create the app, share the URL with somebody on the other side of the world so that they can load your app up and live reload as it’s happening.

    These sorts of things are only possible when you have a shared native run time. As we’ve seen with the web, there are quite a few things that you can do once you have the shared native runtime essentially, which is really what the web APIs are. We discourage that because we think that there are a lot of benefits to having that.

     

    That said, I think in practice, there are cases where, especially as React Native is still two years old or so and Expo around the same age, you’re going to two cases where you kind of will need to, in some cases, bridge a native API. What we’ve done is we made it possible for you to either call it eject, kind of the in the context of Create React app, or Create React Native App, or we like to call detach within the context of Expo itself. Feel free to read the documentation for more information on why that is.

     

    What it does, essentially, is it generates iOS and Android projects for you where, normally, with Expo, you just have JavaScript files. When you run this command, it generates the iOS and Android projects and links the Expo native SDK, so that you’re then free to add whatever native code that you like to the project. Of course, you lose out on a lot of the benefits of having the shared native runtime, but if it’s absolutely required, then it’s definitely a possibility.

     

    [0:14:42.0] CM: Yeah. Shared native runtime is a great way of describing it. Do you think Expo is the best choice for building greenfield React Native Apps, or will large apps inevitably eventually bring in their own custom native modules and eventually ditch Expo with?

     

    [0:14:58.5] BV: I think that if you know right out of the box that you’re going to need some custom native module, like maybe you’re making a video or chat kind of app or you’re planning on using Bluetooth. Someday, we plan on having support for those APIs. At the moment, you kind of just have to look at what’s available through, as we call it, Expo Kit, which is this native SDK that you get when you detach. Say, whether that includes other things that you need, or if it’s worth just starting from scratch with a plain React Native project.

     

    I think many cases, there is no downside to just starting out with Expo. If you hit a wall, you can just detach and continue on as if you had started from nothing before with a plain React Native project.

     

    [0:15:46.8] AP: That’s a pack that I would probably plug myself. I think there’s — At this point with Expo Kit maturing, there’s very, very little downside to doing some initial UI prototyping and like starting work with an Expo just because it’s so fast to get running and you don’t have to worry about a number of new project set of elements. There’s always the escape patch.

     

    [0:16:12.5] BV: Yeah. It’s important to emphasize as well that we don’t lock you in in any way, you’re free to take your code anywhere or use our native SDKs. It’s all open-source. By starting off, there’s not really — Like Adam said, there’s not really much the downside to doing it that way, and there’s a lot of upside and that you can just get going without having to think about a lot of these details that maybe you don’t even need to think about yet on your project.

     

    [0:16:36.3] CM: Okay.

     

    [SPONSOR MESSAGE]

     

    [00:16:44] JM: Every software project uses email. Every time an eCommerce site processes a transaction or a user makes a comment on a social network, email notifications are sent. SparkPost provides email delivery services for apps and websites. To try SparPost and send 100,000 emails a month for free, go to pages.sparkpost.com/sedaily.

     

    SparkPost has a range of pricing options from free self-service packages to sophisticated enterprise support and services. Start sending emails to your users today. Go to pages.sparkpost.com/sedaily to send 100,000 emails a month for free.

     

    Thanks to SparkPost for being anew sponsor of Software Engineering Daily. If you want to send 100,000 emails a month for free, go to pages.sparkpost.com/sedaily.

     

    [INTERVIEW CONTINUED]

     

    [0:17:51.3] CM: Next, I want to talk a bit about Create React Native App. At React Conf 2017, Expo announced a new project; Create React Native App. What was the need you saw in the React Native ecosystem, and I guess, in the Expo ecosystem, that led you to build Create React Native App?

     

    [0:18:09.0] BV: Yeah, we had some conversations with some folks at Facebook who work on React Native open-source and kind of the products of these conversations was that it would be really fantastic if there was a way to make use of a number of Expo’s high points that the qualities that make developing on top of Expo really wonderful without having to depend directly on our backend services.

     

    Our services offer a number of very useful things to developers, but when it comes to getting start to experience for a technology, there was definitely a gap for something that had the ease of use of the Expo client without having to go through an account registration and reading a lot of documentation. There’s also in the React Community at large, on the web and on native, then a lot of praise heaped on Create React App. It’s provided an excellent model for a CLI for React Project, something that React projects were the community hadn’t really rallied or on the standard standard. There were some attempts at doing it well, but there was not anything that was kind of the de facto tool to use and Create React App, as far as I can tell, has become that default.

     

    It’s a very familiar model to developers who want to work with React, and there’s also some nice benefits as an implementer of a tool when you’re doing it the way that Create React App does, but that’s kind of getting into the weeds a little.

     

    Ultimately, we identified a lot of work that would necessary to make Expo play well with no service dependency and with the Vanilla JavaScript that runs React Native normally. Expo projects, it’s very slim. There’s not very much different in it. Historically, we’ve used a fork to make sure that we can offer the best experience possible. There was a lot of work that went into these elements to make sure that Create React Native App was a polished way for people to get started with React Native in general without having to also, at the same time, take the plunge on buying into Expo’s model.

     

    [0:20:18.2] AP: Yeah, I think it’s really important to emphasize from that. The getting started process for React Native without using Create Native App can take up to hours depending on your internet connection and what you have installed already. You have to install xCode and the command line tools and various other things.

     

    A metric that was really important for some of these open-source folks at Facebook were considering was what is the time to Hello world? Before Create React Native App, the time to Hello world, say, could be hours, which is too damn long, frankly.

     

    With Create React Native App, one of the main objectives was we want to get this startup time, this time to Hello world, down to the minimal amount of time that we can possibly do. This is an ongoing effort as we’re improving various tools and removing dependencies. At this point, it’s pretty straightforward. If you have an iPhone and you have a Windows PC, you can install a couple of programs and essentially get started within 5 or 10 minutes, if not less. It’s a significant improvement and it opens the door to development for devices like iPhones, on Linux, and Windows where that wasn’t previously possible using the model suggested in the React Native documentation.

     

    [0:21:45.5] CM: Thank you for providing context.

     

    [0:21:48.7] AP: I’m in too deep.

     

    [0:21:51.7] CM: Just to provide context really quickly to our audience, we’re talking about Create React App and Crate React Native App. Create React App is a web version, and Create React Native App for iOS and Android. Yeah, the names are similar, it can be a little confusing. I just want to make sure that clarification is out there.

     

    What I’m hearing from you is Create React Native App was Facebook’s idea?

     

    [0:22:13.4] AP: I wouldn’t say it was entirely their idea. I think it’s difficult to attribute that when it’s the product of kind of an ongoing conversation. I’ve been the main committer on the tool itself, but we’ve been working on the Expo side on a bunch of things, and we’ve had help from Eric Vicenti and Martin Konicek on making sure that upstream thing happen to provide a smooth process to transition from Create React Native App to using the full React Native CLI. It’s definitely been a good collaboration, I think.

     

    [0:22:47.4] CM: Okay. The name of Create React Native App as we discussed previously was inspired by Create React App. What is Create React App and how is Create React Native App similar? If you could go into more detail in that.

     

    [0:23:04.2] AP: Definitely. Create React App is a command line tool for — Strictly speaking, Create React App, it’s a command line tool for initializing React projects, and it does this using this other NPM package called React Scripts. Basically, the way that works is Create React App itself is completely stable. Users don’t have to upgrade the global command line tool, and this stable global command line tool downloads an up-to-date scripts package.

     

    A scripts package contains all of the build and tooling configuration for this default React project. That includes CSS and JavaScript bundling and includes Babel configurations. It also includes Jest testing config, so users have a testing config out of a box. It includes a fantastic user guide on how to extend your React application with things like Flow type analysis and other things you might want to include in your project.

     

    This model for Create React App, it enables a few things. I think if you talked to the maintainers and creators of Create React App, they would have a number of other positives. Basically, it means that users don’t have to update their tooling globally on a regular basis, and so tooling in configured per project. It also essentially has the effect of hiding complexity from the user until they’re prepared to face web part configuration on their own. It bundles all of these best practices for React applications under this script package that it installs for you. We have a very similar model for Create React Native App. This is not something new to the world. We saw it working very, very well for Create React App and basically just went to the same route.

     

    We have a React Native scripts package, and this includes a number of tools both from React Native and some stuff we built at Expo to smooth out a few things that enables users to run all of their build commands for their project from the configuration. That’s just this one single dependency that they have in their project.

     

    We’re not quite as well abstracted as Create React App yet. There are a couple of points where we don’t have programmatic control over certain things like Babel configuration the way that you do with web pack. There is ongoing work to fully encapsulate all of that build and tooling configuration, so we’re not there yet, but we’ve managed to get, I think, the bulk of what a user would normally be confronted with if configuring all of these themselves and essentially hide it in this package. They just have to update a couple of developer dependencies in order to keep their build tooling current with the ecosystem.

     

    [0:25:51.8] CM: It’s important to stress that Create React App was incredibly important to the React web ecosystem. Before it create React App, as you mentioned, everything that Create React App does, you’d had to do manually before you could even set up projects. This would lead to hours of frustration before you could even start hacking on that.

     

    [0:26:10.7] AP: Absolutely.

     

    [0:26:11.0] CM: Create React App made starting a React Web app much, much simpler. Is Create React Native App saving as much frustration for React Native developers, especially when we consider that the cost of signing up a React Native project is mostly a one-time cost to install xCode and Android Studio? After that, starting a React Native project is pretty easy. Is Create React Native App saving us much frustration?

     

    [0:26:34.8] AP: That depends on which developer you talk to. You have the right to identify that the React Native CLI has definitely done a lot of the work for React Native that Create React App did for React dump, or React for the web.

    Create React Native App is — I think from one perspective, if you’re an existing mobile developer, Create React Native App is kind of closing that last mile. I think there is another group of developers that we would really love to see in the React Native ecosystem for whom the native dependencies were just a deal breaker for trying things out.

    That’s existing web developers and people new to software development. Basically, anyone who hasn’t dealt with xCode or anyone who owns an iPhone but not a Mac, because for React Native CLI project, you have to have a Mac if you want to develop for iOS. I think it’s important not to downplay the existing amount of work that went into React Native CLI and its template projects and its scripts.

     

    I think you’re absolutely right to identify how easy that is to do once you’ve gotten all of the build configuration startup. I also think that these people who just were not a part of the community before and who might have a chance to get involved and at least try things out, it is big.

     

    I also think that, and there’s been some work elsewhere on this problem, but upgrading React Native versions has historically been challenging. There’s been work on this React-native-git-upgrade tool, which I have not played as much as I would like to and as much as I probably should have, but it aims to essentially use Git Merge technology to help with upgrading your React Native version, especially when it comes to your custom native dependencies.

     

    This is something that is, for the most part, abstracted away for you when you’re using Create React Native App and by extension when you’re using Expo. I think that that’s also a significant boon to existing React Native developers if they were to try it out.

     

    [0:28:42.7] CM: Yeah, certainly. Being able to develop iOS on Windows is definitely a key seller there. You might have mentioned this already, but being able to develop iOS on Windows or Linux, is that excusive to Create React Native App, or does Vanilla Expo provide that functionality as well?

     

    [0:29:04.4] AP: Yeah. It’s possible in Create React Native App, because we load your project in the Expo client. This is enabled by the same underlying technology which enables cross-platform development on the Expo tool kit.

     

    [0:29:20.1] CM: Could you develop iOS on Windows with just the Expo tool kit?

     

    [0:29:25.1] AP: Absolutely. Sorry, I didn’t answer your question directly enough. I apologize.

     

    [0:29:28.2] CM: Okay. All right.

     

    [0:29:29.1] BV: I think another thing that is worth pointing out about this is although currently, the only way to open a Create React Native App project on your phone is with the Expo client, there’s no reason why it has to remain that way. Anybody can really build their own client. They can open a Create React Native project. It would be really interesting to see their people work on that and see what we will come up with.

     

    There’s an up chase on file, which defines the configuration for various things like what icon to show on the loading screen or various things related to, let’s say, push notifications and whatnot. This is all under the name space currently of Expo, so if you open up JSON, you’ll see curly braces and then at the top level, there will be an Expo key.

     

    The configuration that lives under that is specific to Expo, but you could imagine there being another key. Maybe Software Engineering Daily, and then you have your own client for Create React Native App. There’s nothing really stopping that from being the case. It would be really interesting to see that happen.

     

    [0:30:31.5] CM: That would be fun. We could download episodes in the background or something.

     

    Next, I want to talk a bit about React Native on other platforms. React Native is not limited to just iOS and android development but may theoretically target any platform where JavaScript may run. Some other platforms built for React Native today include one for the Windows phone virtual reality and, ironically, the web. Do you foresee React Native becoming a popular framework for building on other platforms than iOS and android?

     

    [0:31:03.9] BV: It’s worth pointing out that even the Windows implementation is not just for Windows phone, but it’s for the universal Windows platform. It runs on HoloLens. It runs on Xboxes or desktop. It’s pretty much anything that runs, I believe it’s from Windows 10 or higher. The API is considered universal Windows platform. Someone, I’m sure, will correct me on that, which is fine.

    To go back to the original question, yeah, I think we’re seeing this, and we have been seeing it for a couple of years now. It doesn’t necessarily have to be a mobile device or some new medium. It can be something that we’ve been using for years in a different approach on how to rate a UI for it. At React Conf this year, someone mentioned, I think it was Dustan Kasten, React-blessed, so you can write terminal UIs using React.

     

    They even use React-motion to create animations in that context, which was pretty interesting. There are other things. I think Dustin also built React-hardware, so you can use React to control Adruinos and that type of thing.

     

    Yeah, I think, ultimately, that what React has going for in this space is that the UI that you define or rather the virtual dom that you define through JSX really isn’t tied to any underlying implementation, and you can quite easily implement these renders that do completely different things than what you do in the context of a web browser or a native app.

     

    As far as I can tell, one of the more interesting approaches to having kind of a cross-platform configuration and declarative, I guess, in some cases, logic or UI, it’s out there. Ken Wheeler has also done some pretty interesting stuff around that. I believe he’s going to give a talk soon about powering a crossbow with React. I have no idea what that means, but I guess we’ll find out.

     

    [0:32:56.7] CM: Yeah, I guess we will.

     

    [SPONSOR MESSAGE]

     

    [00:33:05] JM: At software engineering daily, we need to keep our metrics reliable, if a botnet started listening to all of our episodes and we had nothing to stop it, our statistics would be corrupted. We would have no way to know whether a listen came from a bot or from a real user.

     

    That’s why we use Incapsula. To stop attackers and improve performance. When a listener makes a request to play an episode of Software Engineering Daily. Incapsula checks that request before it reaches our servers and filters bot traffic, preventing it from ever reaching us. Botnets and DDoS attacks are not just a threat to podcasts.

     

    They can impact your application too. Incapusla can protect your API servers and your micro services from responding to unwanted requests. To try Incapsula for yourself, go to incapsula.com/sedaily and get a month of Incapsula for free. Incapsula’s API gives you control over the security and performance of your application.

     

    Whether you have a complex micro services architecture or a WordPress site like Software Engineering Daily. Incapsula has a global network of over 30 datacenters that optimize routing and casher content. The same network of datacenters that is filtering your content for attackers is operating as a CDN and speeding up your application.

     

    To Try Incapsula today, go to incapsula.com/sedaily and check it out. Thanks again Incapsula .

    [INTERVIEW CONTINUED]

     

    [0:34:51.7] CM: React Native has become, I guess, you could say a popular framework on iOS and Android. Do you think it could also become popular on something like the universal Windows platform?

     

    [0:35:01.8] BV: Yeah, I think so. I think that the label of React Native is probably going to go away. I think it will just be React and there will be sort of React iOS and React Android and whatnot. There’s been a lot of work and I think that the universal Windows platform implementation of React Native is not only maturing relatively quickly and gaining kind of mainstream acceptance within Microsoft itself, which we saw by having the repository being moved from the React Windows organization to the official Microsoft organization on GitHub recently.

     

    There’s a lot of work going on to try and keep parity with the iOS and Android versions of React Native, which is no small task considering that there is a much smaller group of people who are working on the EWP React Native platform.

     

    Yeah, I really think that as long as work continuous on that, there — It’s kind of a limiting factor and that most people use React Native specifically for mobile UIs at the moment or mobile apps. Of course, Windows phone isn’t quite as popular as maybe it once was or could be. Yeah, it really depends on what people start to use it for. I could absolutely see that becoming more mainstream.

     

    [0:36:20.1] CM: You mentioned that you thought, maybe eventually, the native label would just disappear and just become React. What happens to what we classically think about React, the JavaScript library that does the reconciliation between the virtual Dom trees? What happens to that library of React Native becomes React?

     

    [0:36:40.6] BV: I think it’s pretty similar to what’s already been happening over the last couple of years where React Dom itself was pulled out of the core of React library and I think there might still be some vestiges of React Dom itself in the core. I think we just kind of see these different renderers becoming their own packages that using conjunction with the core library that’s responsible for doing this underlying reconciliation and whatnot.

     

    [0:37:10.7] CM: Do you think Create React App will eventually React Native under the hood?

     

    [0:37:18.3] BV: The future in which that happens is so far off that it’s very difficult to predict. I think there’s about five million sequential events that would have to happen before that. Now, I’m not sure about that. Whether it will happen or there’s desirable, I think it would be amazing if that were to happen. I would love to see moving mergence between React Dom and what we currently call React Native. I think that that would be incredible.

     

    There are a lot of opportunities for that Nicholas Gallagher at Twitter has done a lot of work on React Native Web and is continuing to push forward with that. Lillian Richardson who works at Airbnb has similar library called React Primitives, which is pushing for that.

     

    Ultimately, the — I was saying earlier that the platform is really — There’s no reason why, I guess, theoretically speaking, that web applications cannot also be mobile applications. As we see more convergence there, I think it will make this a lot easier.

     

    Also, as React Native matures and in many ways is becoming more spec compliant with the web APIs that uses, for example, with Flexbox, which is pretty close now. It makes this kind of thing a lot easier to do. I’ve heard of people who are working on apps internally at Microsoft who, one of the developers there, actually rewrote the implementation of CSS layout, which is now known as Yoga, in order to get better spec compliance so that they could reuse code from iOS and Android that involves using Flexbox layout on the web as well.

     

    Yeah, I think —

     

    [0:38:49.2] CM: Wait. Sorry. Microsoft is using Yoga now? Yoga is the implementation of Flexbox and React Native.

     

    [0:38:56.3] BV: Yeah. They actually re-implemented that also, I believe in C# for the universal Windows platform. Similarly, they’re using React Native on a couple of projects internally. This was something — I believe it’s been discussed publicly and you can actually try the private beta of it now. There is the Skype preview for Android which is build using React Native. Yeah, they’re really experimenting with a lot of things related to React Native over at Microsoft. They have their services side which is working on the — What was the name of this thing? [inaudible 0:37:47.4] is going to kill me.

     

    [0:39:35.2] AP: Azure Mobile center.

     

    [0:39:36.3] BV: Mobile Center, that’s the one. This is something that is kind of end-to-end integration where it builds analytics and error reporting and all of these kind of thing into your React Native project for you along with code push which gives you the over the air updates kind of out of the box. It’s sort of — Sorry. I guess — Lost the thread of the original question. I guess, that’s how it is sometimes.

     

    [0:39:59.5] AP: Also, I would add to this general discussion that in the long term, there’s a lot of interesting possibilities with a full-scale convergence of React Dom and React Native. In the near term, regardless of how the potential for that process work out, in the near term, there’s a lot of very interesting work going into improving — The same way that React Native improves co-chairing across iOS and Android for mobile teams. There’s a lot of very interesting work, some of which Brent mentioned on making it easier to abstract over the differences between Dom and the native UI layout so that you can share React code, and share UI components, and share business logic, and these things are becoming much more a reality in the near term, which I think is really exciting.

     

    [0:40:43.6] CM: Just going back to the Yoga thing really quickly. I want to make sure I’m understanding this correctly. Microsoft is thinking about using a Flexbox implementation, originally written by Facebook in Edge when Facebook isn’t even a browser company.

     

    [0:40:58.2] BV: Oh, sorry. They’re not using it in Edge. They’re using it in the UWP React Native implementation.

     

    [0:41:04.5] CM: All right. Okay. I’m sorry. That’s just how I heard it.

     

    [0:41:08.2] AP: I’m glad you clarified that.

     

    [0:41:09.7] CM: Yeah. Okay. The React for virtual reality project, or React VR uses React Native. Why would React Native be an attractive choice for a greenfield project like React VR?

     

    [0:41:22.5] BV: That’s a good question that I don’t think I have a good answer to, unfortunately.

     

    [0:41:27.2] CM: That’s okay. I’m just kind of thinking about it loosely, the build tooling, if nothing else.

     

    [0:41:35.1] AP: I think a JavaScript bridge to native API is a powerful abstraction, and when you have a robust working on. I can’t speak to the motivations for building it this way, but I can certainly sympathize with the desire to reuse that code. That seems powerful to me.

     

    [0:41:53.2] CM: Okay. All right. React started as a UI framework that only targeted the web, and we talked about this a bit earlier. Now it has grown to support more platforms, React Native. React Native. Ironically, one of the platforms that React Native now supports is now the web, which as we know, some employees on Twitter are working on. Why is it attractive for React Native to support the web platform when React itself already does a good job at that?

     

    [0:42:20.2] BV: I think that a big issue with the way that the interop works right now is — I think we’re not necessarily talking about replacing the React Dom package, or anything like that. I think a key part is on React Native and on the web, or React Dom rather, there are different component that you use to describe primitives. On the web, you’ll have a div, in React Native you’ll have a view. Currently, if you import a view from React Native, you essentially can’t use that component that imports the view. You can’t share that with the web.

     

    What React Native web and React primitives do is essentially give you this package that where you import these primitives from rather than importing them from React Native itself. They take care of mapping the properties that are common or that work on the web to the appropriate properties for a div and for spam and what not. It provides this layer that kind of translates between the way that React Native describes components and the way that React Dom describes components.

     

    [0:43:25.2] CM: From my understanding, the mobile Twitter website uses React Native for web, and it’s in the entire app. The Twitter iOS and Android app does not use React Native at least yet. Twitter is only React Native to target the web. Why would the mobile web Twitter team make the decision to user React Native for the web? I do want to emphasize, this is the mobile Twitter website and not the main Twitter website.

     

    [0:43:51.3] BV: I think that’s a fair question. One thing I’m not actually not entirely sure about is to what extent React Native web is used on the mobile Twitter site. I know that Nicholas has mentioned using React Native web and the way that styles are aggregated and de-duped and whatnot, and using that to build out style sheet. I’m not sure if that’s what’s being used in production or not. Maybe you have more information than me about that.

     

    It’s really hard to say. I think that Twitter already has a lot of mobile engineers and it’s a big cultural shift to go from having native mobile engineers to now starting to integrate React Native into various parts of your app. Some companies are slower than others at doing it, because maybe they’re more cautious, or have different philosophies around mobile development. We’ve seen Khan Academy has only recently started to look into integration React Native into their mobile app despite having a team that involves — For examples, Jared Forsyth who worked at Facebook before and worked on React Native and dev tools around that and was advocating for it for a while.

     

    I think people just have — And organizations have a different tolerance and what stage of maturity for a project they’re willing to start making big investment into it. That’s seems to me to be likely, but this is all speculation. You should definitely have Nicholas Gallagher on the podcast at some point to discuss Twitter mobile. I think he’d a great guest.

     

    [0:45:18.1] CM: Yeah, for sure. I guess my only reference point is I opened up the React dev tools once and I saw some views.

     

    [0:45:25.7] BV: Yeah, they are using React on the mobile site. That’s — Yeah.

     

    [0:45:30.9] CM: Yeah. Do you have any other unusual or ironic examples of people using React Native?

     

    [0:45:37.7] AP: I wouldn’t classify it as extremely unusual, but there’s been work going in to the tvOS target, I believe for using Apple TV. I think there are some other interesting, not targets that you don’t immediately think of when you think of web technologies. A lot of — I think there’s been work into — Before I misspeak, I’m going to stop. I can’t remember what — There’s been some work in the tvOS and other kind of kiosks-style technologies.

     

    [0:46:03.8] BV: Yeah. Maybe this isn’t a very outrageous example, or funny example, but more of a serious one. I was really surprised to learn that Flipkart which is a very large retailer in India, they actually use React Native on one of their mobile apps for Android, which is used primarily by people who have extremely low-end devices. They might have, at most, maybe 60 megabytes of RAM available when they open the app. I think React Native has a bit of a reputation for using a lot of memory, so they do all sorts of optimizations around that related to list views and whatnot.

     

    I think what that really demonstrates is even in really harsh conditions, you can adapt React Native to work for your use case. It might take a bit of work, but that seems like a — It’s been valuable, at least, in the context of Flipkart. That’s another person who would be a great podcast guest, is Pjani. I’m sorry if I’m saying the last name wrong. He is a really smart guy about progressive web apps and React Native. Definitely chat with him further about that.

     

    [0:47:10.8] CM: Okay. Does Expo ever plan to support platforms other iOS and Android?

     

    [0:47:17.0] BV: I would love to support the web as a target for Expo. I would love to have progressive web apps being a first-class citizen and the Expo ecosystem.

     

    [0:47:27.8] AP: I think we’re constrained by engineering time, not by desire or imagination.

     

    [0:47:33.3] BV: Universal Windows platform has been requested countless times at this point. That is just something where we’re iterating really quickly on our iOS and Android clients, and so it’s difficult to take the time to really throw a third one into the mix. Once we maybe get a few more engineers on board, we might revisit how what we’re targeting.

     

    [0:47:54.1] CM: Yeah, that sounds awesome. Given that we see React Native becoming popular on other platforms like iOS and Android and including some growth on the web, can we conclude that React Native is the best paradigm developers have today for creating user interfaces between declarative rendering and React Native’s common UI primitives.

     

    [0:48:16.8] AP: That’s a bold statement.

     

    [0:48:19.3] CM: I’m asking you to make the statement.

     

    [0:48:22.2] BV: Sign on the dotted line. I like it a lot. I don’t know if it’s the best one. There’s still — Different apps have different needs. For some applications, maybe React Native wouldn’t be a great fit for the entire thing. I think there are a lot of cases where it does make sense. I would maybe go as far as to day that for a large portion of apps, React Native may be the best way to build apps. That might be the most extreme statement that you’ll get out of me.

     

    [0:48:54.3] CM: Okay.

     

    [0:48:55.5] BV: I think that there are a lot of good options out there. Yeah, personal favorite, of course, being React Native. There are just some limitations currently to the Async model that React Native uses for communication across the bridge. Things that are related to, for example, gestures that if some of these issues were resolved, and there are ongoing efforts to try and come up with better APIs. If these issues were resolved, I would be confident in saying that it’s definitely a contender for most apps as being the best

     

    [0:49:28.0] AP: Taking a quick look through my phone home screens, I don’t see anything which jumps out to me as like, “I couldn’t build this in React Native,” which I think isn’t a pretty good endorsement. Granted that I don’t play very many mobile games. I think that’s an area where answers for — There’s been some interesting work including by one of our teammates. I think there’s a lot of promise there. But most app categories that I interact with on a day-to-day basis, I think React Native would be fantastic for them.

     

    [0:49:55.0] CM: Even the game case. You could see web assembly maybe

     

    [0:49:58.2] AP: Yeah. You can see using it, there’s more interest these days in mixing React Native with existing native iOS and Android applications. I could definitely see for a game using React Native for menus and for UI elements and using wasm and GL under the hood for the actual game. There’s a lot of possibilities.

     

    I think that a phrase that I — I don’t remember where I heard this recently. It was at React Conf. Someone described it as a very high-ceiling technology, where you’d get a lot out of the box, but you can also take it a lot further in a typical cross-platform mobile toolkits. My opinion is that’s a very apps description. People build some pretty impressive stuff with it, and I think it’s very powerful when you combine the expressivity with the iteration time and the UI performance that you get from using the underlying native primitives.

     

    [0:50:49.9] BV: Yeah. I think, Caleb, what you pointed out earlier about an advantage with React Native of always being possible to dropdown to native, is really important for this kind of discussion, because you’re really not limited in what you can do with React Native. You can use it for a single screen in your app, some small piece if you find it useful there, or you can use it for your entire app and just bright wrappers for components that you implement natively as you need it.

     

    Anytime you run up against potentially some limitation of, for example, gestures, or lists, you can absolutely just write a native wrap or a native view and drop that in. The flexibility is definitely something that makes it extremely valuable.

     

    [0:51:34.5] CM: In the future, will React commonly be used without React Native on the web, or do you see a lot of React developers adopting React Native for their web apps?

     

    [0:51:44.6] AP: I think, for that to happen, I would expect to see a lot more maturity in the compatibility layers that people are building. I think there’s a tremendous amount of potential and promise there, but my opinion at least is that’s a little early to make conclusive statements about how exactly that’s going to play out. I think it’s really exciting though. I think it definitely could be that way.

     

    [0:52:03.9] CM: If we say, hypothetically, the integration is perfect and up to standards with iOS and Android, do you think the idea, at least, the concept is attractive?

     

    [0:52:14.2] BV: I think so, yeah.

     

    [0:52:15.5] AP: Yeah, I don’t see why not. I’m not going to speak for other people who are picking their tools. I think having good abstractions for what a UI element is without binding directly to the language used by web browser could be very powerful.

     

    [0:52:30.4] BV: Well said.

     

    [0:52:31.9] CM: Given that Facebook has a lot of developer mindshare with React and, now, React Native, do you think it makes sense for them to build a React Native Facebook phone?

     

    [0:52:44.6] BV: I think they’ve tried to build a phone before in the past, haven’t they?

     

    [0:52:47.6] AP: Have they? I don’t know.

     

    [0:52:48.5] BV: I guess who hasn’t, really? It might make sense, are they going to do it? Probably not.

     

    [0:52:56.3] CM: Why not? Why do you think?

     

    [0:52:59.4] BV: Maybe years down the line. At this point, the way that I see it is the project is maturing and growing so rapidly that building a piece of hardware around it is probably not the greatest decision over this period of time. If the platform stabilizes, and I guess there is a desire for it at Facebook, then maybe — They have so many resources.

     

    [0:53:23.0] AP: For Facebook specifically, they’re not using React Native for the entirety of their mobile application. I think that — From an incentives perspective, I don’t see them doing that anytime soon. It’s a fun idea.

     

    [0:53:36.2] BV: Are you planning on building a React Native phone, Caleb? Is that why you asked?

     

    [0:53:39.0] CM: No.

     

    [0:53:42.5] BV: Is that something?

     

    [0:53:44.3] CM: I think that’s something at least Christopher Chedeau has talked about in the past where it’s the holy grail if you can the React reconciliation algorithm running as low as possible on the device. Yeah, it’s an interesting —

     

    [0:53:58.7] BV: Yeah. I think Cheng Lou’s talk from React Conf last week was kind of related to that —

     

    [0:54:05.8] CM: Very exciting stuff.

     

    [0:54:07.6] BV: Yeah, you have these abstractions and you just try and push them deeper and deeper so that you can then start concentrating on higher level problems. I think that’s related to this, is if you can get something like Dom reconciliation, or rather virtual Dom reconciliation and it’s just a built-in piece of the platform, then you can stop thinking about what library you’re using for that and whatnot and just continue on.

     

    [0:54:30.3] CM: Okay. Besides a phone, what are the other ways Facebook may use React Native to gain a business advantage?

     

    [0:54:39.2] AP: That’s an excellent question for Facebook, I think.

     

    [0:54:43.1] BV: It could be funny to speculate. I can’t think of anything off the top of my head. They’re already using it at business advantage in the sense that they attract, I think, a lot of developers to their company just based off of their reputation for building innovating open-source software like React Native and React, and Jest and Flow and that sort of thing. That’s really, I think, a huge point, because if a lot of people look at — Rather, if you were to look at the current hiring state, or rather even the reputation of companies currently in the Bay Area, I think Facebook is held in very wide regard because of the work that they do in open-source.

     

    I think, even, if you look at what Microsoft has done over the last four or five years, or maybe it’s even been less than that, where they’ve been really making a push to release more open-source software, and that’s improved not only the reputation amongst developers, but it kind of trickles down to non-developers, just a general sentiment towards Microsoft, I think. I think it couldn’t hurt to keep doing things that demonstrate that you’re an innovative forward-thinking company and it kind of creates that perception in their community.

     

    [0:55:53.0] AP: I also think that there’s something — It would be irresponsible of me to talk about the business advantage of React Native without addressing the technical implementation advantages that they get out of it. They’re able to share code across platforms. They’re able to iterate on user interface elements more quickly. It’s not like this technology is surely political, they get actual real world day-to-day benefit from it.

     

    [0:56:20.4] BV: This is the issue of being so deep in the weeds that I just assume that’s —

     

    [0:56:27.4] CM: This has been a great conversation, Brent and Adam. Thank you so much for joining me on Software Engineering Daily.

     

    [0:56:33.3] AP: Thanks so much for having us.

     

    [0:56:34.0] BV: Yeah. Thank you.

     

    [END OF INTERVIEW]

     

    [0:56:39.7] JM: Thanks to Symphono for sponsoring Software Engineering Daily. Symphono is a custom engineering shop where senior engineers tackle big tech challenges while learning from each other. Check it out at symphono.com/sedaily. Thanks again Symphono.

     

    [END]

    Share this:Click to share on Twitter (Opens in new window)Click to share on Facebook (Opens in new window)Click to share on LinkedIn (Opens in new window)Click to email this to a friend (Opens in new window)

    Related

    https://softwareengineeringdaily.com/2017/04/11/the-future-of-react-native-with-brent-vatne-and-adam-perry/

    —Huffduffed by maicki

  9. Facebook Open Source with Tom Occhino | Software Engineering Daily

    http://traffic.libsyn.com/sedaily/fb_oss_edited_fixed.mp3Podcast: Play in new window | Download

    Facebook’s open source projects include React, GraphQL, and Cassandra. These projects are key pieces of infrastructure used by thousands of developers–including engineers at Facebook itself.

    These projects are able to gain traction because Facebook takes time to decouple the projects from their internal infrastructure and clean up the code before releasing them into the wild. Facebook has high standards for what they are willing to release.

    Tom Occhino manages the React team at Facebook and works closely with engineers to determine what projects make sense to open source. In this episode, Preethi Kasireddy interviews Tom about how Facebook thinks about open source–what went right with React, why it makes sense for Facebook to continue to release new open source projects, and how full-time employees at Facebook interact with that open source codebase.

    We would love to get your feedback on Software Engineering Daily. Please fill out the listener survey, available on softwareengineeringdaily.com/survey. Also–Software Engineering Daily is having our third Meetup, Wednesday May 3rd at Galvanize in San Francisco. The theme of this Meetup is Fraud and Risk in Software. We will have great food, engaging speakers, and a friendly, intellectual atmosphere. To find out more, go to softwareengineeringdaily.com/meetup.

    Show Notes

    Pete Hunt: React: Rethinking best practices — JSConf EU 2013

    Sponsors

    It’s never been easier to hit the ground running: MongoDB Atlas is the only database as a service from the engineers who built MongoDB. With continuous backup, VPC peering, monitoring, and security features, MongoDB Atlas gives you everything you need from MongoDB in an easy-to-use service. And even if you’re already running MongoDB in the cloud, Atlas makes migrating your deployment from another cloud service provider trivial, with its Live Import feature. Get started with a free, 3 node replica set: no credit card required. As an exclusive offer for Software Engineering Daily listeners, use code SEDaily for $10 dollars of credit for when you’re ready to scale up at mongoDB.com/sedaily.

    Oracle Dyn provides DNS that is as dynamic and intelligent as your applications. Dyn DNS gets your users to the right cloud service, CDN, or data center, using intelligent response to steer traffic based on business policies, as well as real-time internet conditions, like the security and performance of the network path. Get started with a free 30-day trial for your application by going to dyn.com/sedaily.  After the free trial, Dyn’s developer plans start at just $7 a month for world-class DNS. Rethink DNS. Go to dyn.com/sedaily to learn more and get your free trial of Dyn DNS.

    Dice.com will help you accelerate your tech career. Whether you’re actively looking for a job or need insights to grow in your role, Dice has the resources you need. Dice’s mobile app is the fastest and easiest way to get ahead. Search thousands of jobs from top companies. Discover your market value based on your unique skill set. Manage your tech career and download the Dice Careers app on Android or iOS today. And to check out the Dice website and support Software Engineering Daily, go to dice.com/sedaily. 

    Transcript

    [INTRODUCTION]

    JM: Facebook’s open source projects include React, GraphQL, and Cassandra. These projects are key pieces of infrastructure used by thousands of developers–including engineers at Facebook itself.

    These projects are able to gain traction because Facebook takes time to decouple the projects from their internal infrastructure and clean up the code before releasing them into the wild. Facebook has high standards for what they are willing to release.

    Tom Occhino manages the React team at Facebook and works closely with engineers to determine what projects make sense to open source. In this episode, Preethi Kasireddy interviews Tom about how Facebook thinks about open source–what went right with React, why it makes sense for Facebook to continue to release new open source projects, and how full-time employees at Facebook interact with that open source codebase.

    We would love to get your feedback on Software Engineering Daily. Please fill out the listener survey, available on softwareengineeringdaily.com/survey. Also–Software Engineering Daily is having our third Meetup, Wednesday May 3rd at Galvanize in San Francisco. The theme of this Meetup is Fraud and Risk in Software. We will have great food, engaging speakers, and a friendly, intellectual atmosphere. To find out more, go to softwareengineeringdaily.com/meetup.

     

    [SPONSOR MESSAGE]

     

    [0:00:13.5] JM: For years, when I started building a new app, I would use MongoDB. Now, I use MongoDB Atlas. MongoDB Atlas is the easiest way to use MongoDB in the cloud. It’s never been easier to hit the ground running.

     

    MongoDB Atlas is the only database as a service from the engineers who built MongoDB. The dashboard is simple and intuitive, but it provides all the functionality that you need. The customer service is staffed by people who can respond to your technical questions about Mongo.

     

    With continuous back-up, VPC peering, monitoring, and security features, MongoDB Atlas gives you everything you need from MongoDB in an easy-to-use service. You could forget about needing to patch your Mongo instances and keep it up-to-date, because Atlas automatically updates its version.

     

    Check you mongodb.com/sedaily to get started with MongoDB Atlas and get $10 credit for free. Even if you’re already running MongoDB in the cloud, Atlas makes migrating your deployment from another cloud service provider trivial with its live import feature.

    Get started with a free three-node replica set, no credit cards required. As an inclusive offer for Software Engineering Daily listeners, use code “sedaily” for $10 credit when you’re ready to scale up. Go to mongodb.com/sedaily to check it out. Thanks to MongoDB for being a repeat sponsor of Software Engineering Daily. It means a whole lot to us.

     

    [INTERVIEW]

     

    [0:02:12.3] Q: I’m really excited to have Tom Occhino on the show today. He manages the React team at Facebook and he’s very, very involved in the open-source involvement within Facebook. We’re going to be focusing on talking about how open-source works within the Facebook organization. Before getting started, I love to just have Tom jump in and give a quick introduction of himself.

     

    [0:02:35.4] TO: Hi. Yeah, absolutely. Thanks for having me on the show. I’m excited to chat with you. Just a little bit about myself. I’m been here at Facebook for a while now, probably about a little over eight years actually. I’ve always been involved in our frontend technology stack, and that started out with HTML, CSS, and JavaScript and a little bit of PHP, but eventually moved on from building products to building, what we call, product infrastructure.

     

    Product infrastructure is the systems and frameworks and libraries and things that we build that power the products that we build. Part of that is React, so I got involved in React before it had a name, when this guy, Jordan Walke, created it. I’ve been managing that team ever since and heavily involved in some other things as well.

     

    [0:03:20.5] Q: Going back to the very early days, I know Facebook started open-source efforts very early in the company’s life cycle. There was the Cassandra database, the Tornado Web Server, and a bunch of other projects. Open-source was important by then and it’s becoming even more important today as more and more of the software that we use today is becoming open-source.

     

    As a role of open-source increases, I think people are starting to have this expectation for large organizations like Facebook and Microsoft or IBM to play a role in the open-source software that the community uses. I’m curious. What motivated Facebook to be one of the early movers in their efforts in contributing to open-source and being someone involved there?

    [0:04:07.6] TO: I think a primary motivation was the fact that we were such a large consumer of open-source software. Even before I joined Facebook, the stack that we were building Facebook on top of was basically your traditional LAMP stack, and all of the technology is — PHP was a huge thing that we use. PHP and all the other technologies that we — MySQL and all these other things were all open-sources. We were motivated to give back, I guess. We’re taking advantage of all of the stuff that exist in the community in trying to make it better ourselves. If we come up with new things, when it makes sense, we’ll try and contribute those things to open-source as well.

     

    Some of our early efforts like Cassandra, and even a little later on, Tornado, after the FriendFeed acquisition, I think; there was a lot of server-side and low-level backend infrastructure focus for some of our open-source efforts. Then, I would say back in about 2013, we refocused on the frontend or started focusing on the frontend a lot more with especially the advent of React.

     

    I think the answer to your question, why do we do this, or why do we feel compelled to open-source technology. I think it’s because we were such heavy users of open-source. We always knew we wanted to be able to give back to the open-source community.

     

    [0:05:29.5] Q: Interesting. That’s super interesting. I’ve seen a lot of enterprise companies jump into open-source, and it just makes sense there. I guess for a consumer-facing social media company, what are some of the benefits or things you get from being part of the open-source community?

     

    [0:05:50.3] TO: Yeah, there’re a number of them. I think anytime we open-source software, it forces us to give it an extra round of almost vigor and try and make sure that it’s in good shape. We make sure that documentation is in order, and things work, and it’s sufficiently decoupled from the rest of our infrastructure and things like that. One benefit is it just makes our software better, we think.

     

    Another befit is, obviously, on recruiting and brand recognition, a lot of people who have joined Facebook in the past three or four years cite one of the reasons they’re really interested in joining is because they want to work at a place where something like React can be created. It’s not even necessarily just about React or GraphQL or some of our other open-source technologies. It’s about wanting to work in an environment where you’re allowed to share what you work on with the world. That’s been a huge thing for us.

     

    I think we’ve also received tons of amazing contributions that have made the software better from external contributors, and it’s acted as a wedge, almost, for us to be able to collaborate and communicate more with other companies and in completely different industries or even in the same industry. The benefits of openness and communication are core to our mission as a company. Open-source enables us to carry that out on a software front, the technology front.

     

    [0:07:13.9] Q: Yeah, I definitely want to come back to that point about open-source being attracted to hiring new developers. I think that’s a very interesting and important point. Kind of taking a step back, you mentioned how Facebook started open-source mostly in a lot of the backend database technologies and then has more recently, moved into the frontend. Can you give listeners a lay of the land of all the different areas of Facebook has open-source technologies today?

     

    [0:07:42.6] TO: Oh, gosh. Yeah. Everything, basically. On the software side of things, especially on the frontend, we have frameworks for building UIs. We have frameworks for doing data fetching, big to small. Things as large as React in GraphQL and also things as small as — Recently, we open-sourced a single function called the existential function, IDX, which is a very, very small library that serves a single purpose and serves it well. That’s on the frontend JavaScript and side like that.

     

    We also have tons of server-side infrastructure around everything from database systems, and key value stores to caching systems, and build systems, and editors, and all sorts of different software on that side of things as well. We also have projects like our Open Compute Project, which is all about open-sourcing the specifications and designs for the hardware that we use to power all of our services.

     

    In our data centers, we have racks and racks of computers and servers, and the designs for those servers are actually open-sources. It’s part of the Open Compute Project. It’s everything from hardware to software and everything in between. It’s the variety of things that we open-source.

     

    [0:09:02.8] Q: Jumping into the team and how that comes together, I know that you’re mostly focused, or overstay in the React team. I’m curious, when you’re making a decision to open-source a technology, how do you find the right people to kick-start the effort?

     

    [0:09:22.7] TO: An interesting thing about the way that we write software at Facebook is the people that author the code or the people that support the code, that doesn’t mean just through open-source and things like that, it means when your code goes out to production, if you built a user-facing product or you built a library or something like that, when your code goes out to production, you are the QA. As an engineer, you’re on the hook for making sure that your software works.

     

    The process of open-source, something is very similar. It’s not like the authors author it, and then another team takes over and starts to maintain the open-source project. The key driver for whether or not it makes sense to open-source something is — One of the key drivers is are you committed to maintaining it as an engineer? If Facebook determines that it’s valuable to open-source, and we’re using it in production, and it’s working for us; those are the prerequisites.

     

    The next question is: are you going to maintain it? Are you going to be contributing to the project? Not necessarily indefinitely, but fostering a community in building up a first line of defense in things like this and getting other people helping and supporting, because what we don’t do — With some projects very early on in Facebook’s life, we did this incorrectly. We would throw things over the wall. You have something and you don’t necessarily even open-source it, you just make the source code available, and people can do with it what they want. That’s not the way we treat open-source anymore.

     

    I think the question was; how do you decide if something is good for open-source? There’s many other, actually, facets that go into figuring out if we should open-source something, but the big driver is; is the engineer motivated to build a community and maintain the project and be a good steward of the project.

     

    [0:11:16.5] Q: Interesting. It falls upon the engineer themselves?

     

    [0:11:20.5] TO: Exactly. And the team, yeah.

     

    [0:11:22.7] Q: Yeah. Then, if the engineer is not that interested — Because building an open-source tool and then maintaining it are very separate things and different skill sets, too, altogether. If an engineer is not interested in maintaining it, but they want to open-source it, is it possible for that to still be open-sourced?

     

    [0:11:44.5] TO: It’s definitely possible. They basically just have to find people who are motivated to be — Not necessarily just maintainers, but be the folks that are going to drive for even a small community to be created or set up an RFC process. There has to be somebody who is committed to the project or else, we wouldn’t open-source it, basically.

     

    It doesn’t need to be the engineer themselves. They just are responsible for finding the engineers that are willing to put in that efforts and make sure that we’re not just throwing something over the wall. Sometimes, I imagine, we probably have things that we would consider open-sourcing that are actually just reference implementations.

     

    We would say, “Hey, this isn’t actually a thing that we’re going to maintain, but it’s a problem that we solved. Maybe our solution is to couple to our infrastructure, or maybe we don’t really want to maintain it as an open-source project. We want to continue iterating, but we want to share our solution with the world.” That would be a different type of release if we were to do that. I can’t think of any examples where we’ve done that before, but I could just imagine us saying, “Oh, you know. Let’s not open-source it, but if people are asking for it, let’s still make the code available.”

     

    [0:12:55.6] Q: Wasn’t GraphQL one of these situations?

     

     

    [0:12:58.4] TO: GraphQL interestingly started out as — It had no intention of being open-source. It was a very specific problem to a set of problems that we were having with how we do data fetching in our apps. I think once we started deploying it to React applications, it became a natural candidate for open-source because if people are using it successfully alongside React at Facebook, that might be an indicator that it’s relevant elsewhere. Engineers were generally very happy with using GraphQL, plus React.

     

    At the first React Conf in 2000 — What was it? 2015. When we originally released and announced and talked about GraphQL, I think we were a little surprised and overwhelmed by the reception. It was amazing to see it, because we had been using it internally for a long time and we knew it was working, but we didn’t know that, necessarily, the problems would resonate with everyone. That’s one of those cases where it wasn’t originally designed to be open-source. It wasn’t originally built to be open-sourced, but it was a natural fed. It was a good candidate for it after the fact.

     

    Other projects are designed with open-source in mind. From the beginning, maybe they’ll start out with their source code on GitHub, in a private repository, and our intention will always be to eventually open-source this.

     

    I think one project that comes to mind is called Fresco; an image library for android that makes image rendering a lot faster and more performant and more efficient. From the beginning, we were like, “Okay, if we are solving this problem, we have talked to the rest of the community. We know a lot of other people are facing the same problems. Let’s go ahead and just set this up so that if it is successful here, it’ll be very easy to flip a switch and make it public.”

     

    We have both. We have projects that are after the fact, we go back. React was one of these as well. React wasn’t originally designed to be open-source as well, but when Instagram wanted to start using it, and we needed to decouple from out Facebook-specific infrastructure, it became a good candidate for open-source. We’d already done the work to decouple it, and it was a general purpose thing. Then, other projects, the other cases, from the beginning, you know that if this works, you want it to be open-sourced.

     

    I would say that case is becoming more common these days, especially as we hire more and more people who are passionate about open-source. Everybody that we work with in the open-source community, they all assume that everybody is really excited about open-source and passionate about it, but it’s actually not that. There’re actually quite a few people that appreciate and feel they benefit from their code not being open-sourced and not having to worry about any of the implications of other people being able to try their code in ways that they hadn’t considered. A very long-winded answer to your question, I hope.

     

    [SPONSOR MESSAGE]

     

    [0:16:04.6] Q: For more than 30 years, DNS has been one of the fundamental protocols of the internet. Yet, despite its accepted importance, it has never quite gotten the due that it deserves. Today’s dynamic applications, hybrid clouds and volatile internet, demand that you rethink the strategic value and importance of your DNS choices.

     

    Oracle Dyn provides DNS that is as dynamic and intelligent as your applications. Dyn DNS gets your users to the right cloud service, the right CDN, or the right datacenter using intelligent response to steer traffic based on business policies as well as real time internet conditions, like the security and the performance of the network path.

     

    Dyn maps all internet pathways every 24 seconds via more than 500 million traceroutes. This is the equivalent of seven light years of distance, or 1.7 billion times around the circumference of the earth. With over 10 years of experience supporting the likes of Netflix, Twitter, Zappos, Etsy, and Salesforce, Dyn can scale to meet the demand of the largest web applications.

    Get started with a free 30-day trial for your application by going to dyn.com/sedaily. After the free trial, Dyn’s developer plans start at just $7 a month for world-class DNS. Rethink DNS, go to dyn.com/sedaily to learn more and get your free trial of Dyn DNS.

     

    [INTERVIEW CONTINUED]

    [0:18:05.2] Q: That’s really helpful. Taking a step back to the question that we started at, which is, how do you find the right people, I think we act as a good example of one engineer creating — Or inventing it, sort to say, and then a whole other team of engineers actually bringing that to the real world and to the outside world. Do you want to talk about why React was so successful in that process even though the original engineer necessarily pushed for it? It still became what it is today.

    [0:18:35.4] TO: Yeah. I think the process for building up the team and finding the right people to contribute, the number one thing that you need is optimism, and interest, and excitement. Jordan showed React — Before it even had a name, he showed it to a dozen people, myself included, and everybody had the same reaction. Even me, I was very skeptical. I was like, “Look. I can see the benefits on the developer experience. I don’t know how this is going to be performant enough. I’m really not sure how we’re going to apply it to our problems that we’re solving here, but yeah. Let’s try it out.”

     

    There were a couple of other people like Christopher Chedeau and Pete Hunt who provide even more optimism, way more optimism than even I did. When you become surrounded by people who figure out what you’re trying to accomplish — And we had a couple of people that just were exposed to this through social connections or connections at work or because of projects they worked on. I think Pete Hunt and Christopher Chedeau both worked on Photos at one point, so they found out about it from a tie that we had there, and they were excited about it and they were interested, and they started playing with it and then they said, “You know what? I need to help. I need to make this happen.”

     

    I think that the thing that you look for is you want to bring people onto team that not only have the right skillset, but believe in the vision and believe in what you’re trying to accomplish and agree with it. It’s one thing to try and manufacture a team out of like, “Okay, we need two iOS engineers. We need one C++ programmer and one designer in this and that.” It’s another thing to let the team form organically based on the people that are most excited and most passionate. That was part of it.

     

    I think the next wave of team members that came on board were the folks that were excited to be early adapters. Especially if you’ve been in the industry a while and you’ve used software that is brand new, not everyone’s excited to be an early adapter. The great thing about early adapters is they have an exceptionally high tolerance for instability and bugs and features that are missing and things like this.

     

    If you can find a team to work with, this really easy-going and willing to work with you and willing to not only deliver their product, but also work to deliver the framework itself, they’re going to be your biggest advocates. They’re going to be the next wave of core team members.

     

    I think, consistently, one thing we’ve done with the product infrastructure at Facebook is we work with a single team first that is going to use the thing that we’re building. We never build software in a vacuum, we never build a thing, and then once it’s shrink-wrapped and finished, give it to anyone.

     

    We always build infrastructure, or abstractions, or frameworks, or libraries. We always build them in conjunction with a real user-facing product and we improve both simultaneous. We make the product better through improvements of the framework. We make the framework better though feedback from the product and the teams building the products.

     

    The next wave of people that work on React were people that used React early on. If anyone remembers the original announcement at JSConf in 2013, it didn’t go well at all. We didn’t communicate well what we were doing, but the people that did hear through that first talk became the next wave of contributors to the project. One of those people’s Ben Alpert from Khan Academy who is now — He’s been involved in React for a long time and he is effectively tech-leading a lot of the efforts from Facebook’s side.

     

    The next wave of people came from, “Okay, if you present about this and you get people that are interested enough to get into the codebase and hack on it and try and figure things out and understand what you’re trying to accomplish, that’s where the next wave of contributors came from as well.”

     

    I think it’s definitely a process, and it varies project to project. For react specifically, I think it was this idea of this slow adoption cycle a little bit at a time, get people to buy in and see it and then commit to it. The other thing that really helped with this is was the fact that at Facebook, we really value engineering mobility. We don’t want engineers to stay on the same team for forever. We want them to share ideas and cross-pollinate and move across teams and explore different opportunities across the company or really across the companies at this point.

     

    It really was easy for a user of React to become a core contributor to React at Facebook. It was perhaps easier than it is at a lot of other companies. When Christopher Chedeau wanted to switch from the Photos team to the React team, it was like, “I had a meeting with this manager. We set up a timeline, and then it was done.” That has really, really helped with a lot of team building around some of these open-source projects.

     

     

    [0:23:42.6]: Q: That’s very interesting. I know that you’re getting at that fact that organically building up a team has worked out really well, but if you had to talk about at least a few key roles that must exist for an open-source project to be successful, what would you say they are?

     

    [0:23:59.7] TO: Yeah, that’s a great question. I think one role that people might not think about early on, especially in the development of a project, is who is going to communicate about it? Who’s going to talk about what it is and what you’re trying to do and why?

     

    I worked with another engineer, a very good friend of mine named Marshall Roach. Early on, our relationship, the environment that we worked in was such that he was significantly better at solving a lot of the hard technical problems. He wasn’t really as interested in communicating about them to all of engineering, and he recognized that I was more comfortable with that with public posts and with speaking at engineering all hands and things like that.

     

    The partnership that we had was; we would come up with ideas together. I would vet his implementations and review the code and things like that, but then I would communicate about the stuff that he was enabling. That is the only reason that a lot of the work that he and I were able to do together was able to be accomplished. If it was just me, it wouldn’t have been able to happen. It wouldn’t have been technically the right solution. If it was just him, it might not have happened because it wouldn’t have been communicated about actively and proactively and efficiently enough.

     

    One role that you absolutely need is somebody who’s going to communicate what you’re trying to do, and this can be the same person who’s writing code. It can be the same people that are writing code, but you have to have that role. I think that is often overlooked.

     

    The reality of the situation is that as much as the technology that we’re building, these are problems of technology, they’re also problems of psychology. There’s a tremendous amount of, basically, communication that has to take place to enable people to understand and give the project to chance and enable them to get on board with the vision.

     

    The next set of people I think you need are the folks that feel so committed to the project and so committed to the vision. They’ve really bought into whatever the messaging was that they’re committed to doing all of the things that might not be super glamorous. It’s always fun to release a thing but who’s going to respond to issues and Stack Overflow questions? Who’s going to email people back and answer questions and all these other stuff?

     

    You need a set of people who are so heavily invested in the success of the project that we’re willing to do both the actual development work and the testing and fixing and cleaning up and things like that. Also, the software stuff, the maybe sometimes less glamorous stuff of support and repping people up and writing documentation and stuff like that. Other than that, I really do think every team is very different based on the technology itself and who their target audience is and stuff like that. Those are two that I think are really necessary.

     

    [0:26:40.5] Q: Interesting. Particularly on the first role with the messaging, do you have an example of maybe internally an open-source project that didn’t do so well in this one, and you think that was a good lesson learned?

     

    [0:27:07.5] TO: Interesting. A project that we perhaps didn’t message well enough. I think it’s harder once we get to the point of open-sourcing it, but I can certainly think of a several examples of internal projects that weren’t broadly adopted internally, because they didn’t have a person who was doing that communication.

     

    I can think of also — One example might be that we haven’t really communicated with the community, I guess, in open-source as much as Flow, especially when we first started out with Flow. We were building a thing that was going to work in our environment but we didn’t really have as much of a spokesperson that was very proactive with messaging about what we’re trying to do and almost persistent about it.

     

    It was like, “Hey, here is a thing that we’re building. It’s working well for us. We’re going to continue investing in it.” It was almost more of an internal project that happen to be open-sourced and we would work in the community and things like that.

     

    On that project, we might also have not invested enough in fostering a community and answering questions proactively and solving the issues of the community, because there are still so many problems just to solve for Facebook alone. Projects like that, which are open areas of research and exploration and just truly state of the art in academics, it’s really hard to balance trying to deliver value for both us and the community.

    Maybe that’s one example where a single person didn’t really emerge to become what like Tom Dale and Yehuda are for Ember or what Pete Hunt was early on for React. I guess that’s one example I can think of.

     

    [0:28:56.6]: Q: Interesting. How has that turned around today? I know Flow is increasingly being adopted nowadays. Just for listeners who don’t know, Flow is a static type checker for JavaScript, right?

     

    [0:29:08.6] TO: Yeah. It’s being adopted a lot more recently, especially in the React community. I think one of the reasons it started to take off is just because it’s gotten a lot better. Eventually, the technology speaks for itself, but the problem is that maybe that process took longer than it needed to, but it’s been working exceptionally well for us internally.

     

    I’m excited for — I managed the Flow team for a little while. Even though I don’t have programming language background or anything like that, I managed the team for a while. They’re just absolutely awesome, super, super smart. They’ve been able to extract a tremendous amount of value out of our Facebook JavaScript code base. I think that has just translated well to other people as well.

     

    Uber just announced their UberEATS app, which is a React Native app. They also use Flow and some other things. It’s good to see other companies adopting Flow and it working well for them, because the reason we originally built it was just to give ourselves more information about our JavaScript codebase and if it ends up being generally applicable in the long-term, that’s fantastic.

     

    As for what else has changed, I think, just organically, as more people have tried it and gotten value out of it. The hard thing, specifically, about that project is the JavaScript community is not only bifurcated amongst the different type solutions, like TypeScript and Flow, there’s the majority of people in the JavaScript community don’t even yet know why types are valuable.

     

    Unless you come from a strongly typed background, strongly typed programming language background, or have some experience, or you might not, at first glance, see why, “It seems like this is more work. Should it be —” It ends up really benefitting you in the long run when you have increasing size of your codebase multiplied by the increasing size of the team working on that codebase. That’s when systems like Flow and Hack have really, really shown their stars.

     

    [0:31:03.5] Q: Yeah, I agree. I totally agree. While we’re in the process of talking about success of open-source project, I’m curious, do you, internally, have any metrics that you use to track the success of an open-source project?

     

    [0:31:18.0] TO: It’s a good question. I think we do have dashboards and things to track the health of open-source projects. If there’s a lot of really old, really stale issues, or people getting frustrated, or open PRs, or something like that, we track that kind of stuff. Superficially, people track stars in an informal way. They’re, like, “Oh, yeah. We just crossed this milestone.” There was a post that we did for React when it crossed, I think it was 50,000 GitHub stars or something like that.

     

    I think that the metrics that we track that we care about are meaningful contributions from the community and maybe —

     

    [0:31:58.3] Q: How would you define meaningful contribution?

     

    [0:32:00.6] TO: Yeah. There’s a couple of little different levels of contribution, and I think they’re all amazing. Anybody who comes in and just fixes the website, or fixes documentation, is great. Especially if they find things that we overlooked or didn’t find, or if they complete some stuff that isn’t there. There have actually been contributions from open-source that have — I don’t know. Pretty meaningfully affected performance of certain things. Somebody submits a poll request and then all of a sudden, the main Facebook app is faster, or something like that.

     

    We track those types of contributions. I think we just kind of — That’s one of the ways that we sell the winds of open-source. That’s one of the reasons that the effort, and time, and energy that goes into open-source is worth it. We track some of that stuff. I can’t think of any off the of my head on this part here, but I don’t think we track too many metrics. I know we have internal dashboards and things like this, but the metrics that we care about are, “Is the project healthy? Is it adding value to people’s lives?” We track the sentiment and stuff around projects. What do you think would be a good metric for us to track?

     

    [0:33:14.4] Q: Yeah, it’s a tough one, because I think within the GitHub project itself, there’s hard metrics you can track like issues and making sure that there’s a certain time limit for how quickly you response or how quickly they’re closed or how many stale issues there are. I think those are kind of some of the more concrete ones. I think, in general, the sentiment is the one that’s hard to measure.

     

    [0:33:38.2] TO: Yeah, I agree.

     

    [0:33:39.4] Q: You’ve had very successful React Conferences, and each year they continue to get better, but how do you measure that. I really don’t know.

     

    [0:33:47.1] TO: What’s our net promoter score I guess is — There are some things that we get excited about when people do analysis of how likely are you to use — If you’ve used React, how likely are you to use it again? That has a really high percentage, something like over 90% of the people say they’d use it again. We don’t track those things, but we certainly — When they come up, we use it as one more input that we’re either doing something correct, or if there are negative that we’re doing something wrong.

     

    I guess adoption is good. Our intention when we open-source software is never to make it become just, “Oh! We’ve solved the internet.” Yeah, everybody in the world uses this. We’re not even — We don’t even have a goal around, for example, React Native adoption to make it be, “This is the only way that you build apps.” What we do with all of our solutions and all of our open-source projects is this is a thing that solved this set of problems for us, and if it solves those problems for you, we’d love to work together on it.

     

    We’ve had pretty amazing contributions from Airbnb and WIX.com, for example, on React Native and doing different things with React Native. That collaboration couldn’t have happened if those projects were closed source.

     

    To me, the best metric is the meaningful collaboration and adoption. Adoption for adoption’s sake I don’t think is interesting. I’m really not worried about or interested in every company on the planet using React. There’s actually cost associated with that. There’s more support cost and more maintenance burden and all these other things and trying to make it do things that it wasn’t designed to do.

     

    Tracking adoption, meaningful adoption, where you’re getting input and you’re getting new use cases that help you test your hypothesis and you’re getting meaningful contributions back. That type of adoption, I think, we do track and we do care about.

     

    [SPONSOR MESSAGE]

     

    [0:35:45.6] JM: Dice.com will help you accelerate your tech career. Whether you’re actively looking for a job or need insights to grow in your current role, Dice has the resources that you need. Dice’s mobile app is the easiest and fastest way to get ahead. Search thousands of jobs from top companies. Discover your market value based on your unique skill set.

     

    Uncover new opportunities with Dice’s new career-pathing tool, which can give you insights about the best types of roles to transition to. Dice will even suggest the new skills that you’ll need to make the move. Manage your tech career and download the Dice Careers App on Android or iOS today. To check out the Dice website and support Software Engineering Daily, go to dice.com/sedaily.

     

    Thanks to Dice for being a loyal sponsor of Software Engineering Daily. If you want to support the show and check out some new career opportunities, go to do dice.com/sedaily.

     

    [INTERVIEW CONTINUED]

     

    [0:37:06.6] Q: That’s interesting. I never thought about meaningful versus not meaningful adoption. I guess you’re talking about it in terms of — Why wouldn’t you just want everyone in the world to adopt React? Is it just too much pressure on the organization?

     

    [0:37:21.0] TO: No. There are other solutions to problems out there that are amazing, and I don’t think that React solves everyone’s problem everywhere, nor do I think that it would be as good of a tool as it is if it attempted to. I’ve played with lots and lots of other frameworks that are unrelated to React, but that I think could be influenced by React. I don’t know. I don’t think that — I guess there’s this tendency to always want kind of more, more, more, more influence, more adoption, more subscribers, more stars. Everybody kind of even tweets about this stuff when they have a new — It just feels good that you’ve been validated once you have a kind of high profile client or adapter, but I don’t think the world would be very interesting if everyone in the world use React.

     

    [0:38:15.4] Q: Yeah, that makes sense. I guess what’s interesting is, then, there’s the other side which is the ecosystem is completely fragmented and you have a fragmentation problem. Particularly in JavaScript, there’s seems to be an issue where it’s either — It’s just like so many different solutions for the same thing, or do you want one really good solution? That’s an interesting balance to have.

     

    [0:38:43.8] TO: When I think about that question about the fragmentation and maybe even bifurcation, the concrete downsides of that in my opinion are a less of a willingness to share ideas and what I would call siloing and closeness.

     

    If we can solve closeness and siloing and enable more engineers to collaborate, then I think it is a worthy goal to say, “Yeah, we want more people using React or using something, anything.” If we can find some webs that gets more engineers that wouldn’t traditionally be talking to talk, I think that is absolutely valuable. I also think that you do want some amount of fragmentation, because that’s how new ideas form. If we had just used what everyone else was using when we created React, we literally wouldn’t have been able to create React.

     

    You want experimentation. It’s not so much like, “Let a thousand flowers bloom,” but it’s kind of similar, it’s, “Let’s innovate independently and then come back together and share ideas and share code wherever we can and hack. Let’s share languages. Let’s share programming languages. Let’s share tool chains and tooling and things like this.”

     

    [0:39:56.3] Q: It’s a very interesting topic, because I think as you open-source technologies, one thing that naturally happens is people create their own solutions off of what you open-source, because they need some part to be different. Even within organization, they’ll have their own alternatives of React, or whatever it is.

     

    Have you thought about how to not only encourage that, but also encourage them to be open about what their ideas are so we can all come back together and create an even better solution together instead of the silos?

     

    [0:40:29.7] TO: Yeah, this is a really hard problem. How do you get folks whose livelihood is dependent on them having a better solution? How do you get them to share their solution back? I don’t know the answer to this, but I think that the answer involves more communication and collaboration and us fostering an environment where we have as much inclusion as possible.

     

    One thing you’ll notice about the React community is no one will ever bash or complain about any other frameworks or libraries or anything like that. If they do, they’ll be basically, not scolded, but they’ll be reached out to by somebody from the React community that says, “Hey, that’s not cool.” We celebrate wins. We celebrate new things that happen, new developments.

     

    Yesterday at Ember Conf, the Ember team released Glimmer. I can’t wait to play with it. We should celebrate each other’s accomplishments and create an environment where people are more likely to want to share their solutions, because they’re novel and new, and not because they’re a strategic advantage for them or a strategic sort of source of — I don’t know — Proprietary worth. If that makes any sense.

     

    I think it involves all of us creating an environment where we celebrate the developments of others rather than — I don’t know — For lack of a better way of saying it, crapping all over their ideas. I basically don’t read Hacker News or Reddit anymore, because I can’t stand to see people hating on everybody else’s ideas.

     

    [0:42:01.4] Q: Yeah, I totally agree. That’s interesting. I kind of want to transition off and move into talking about contributor policies and rules. This is a very interesting thing for me, because I think React follows a more close core team approach, whereas Ember, which is another frontend framework, follows a more open RFC type approach. I was wondering if you can quickly, in a couple of sentences, just explain to listeners what the closed approach versus open RFC approach is and why React has chosen to go with the former and not the later.

     

    [0:42:36.4] TO: Yeah. Real quick, just to compare and contrast a little bit. An RFC approach, I think you sort of accept any type of proposal from anyone in the community. If it garners enough support, it will be considered for inclusion by the core team, and maybe some RFC say, “If it garners enough support, it will be included. There’s no discretion.”

     

    I think the model that React has, which I think you referred to as closed team, or what did you call it?

     

    [0:43:05.7] Q: Closed core team.

     

    [0:43:07.1] TO: Closed core team. This is a purely an implementation detail and a side effect of sort of the way that the projects kind of grew organically. I think what you mean there is the development of the framework is sort of at the discretion of the core team, the people that are stewards of the project and are maintaining it and working on it. Most of them, I think at this point, probably work at Facebook, although there’s a handful of non-Facebookers.

     

    I don’t necessarily think one approach is fundamentally better than the other. I think, at the end of the day, someone needs to have a long-term vision for where the project wants to go in their head, and whether that is a group of contributors, a group of a closed core team, or something like that, or it’s a single person. A lot of projects just have a single visionary. Somebody has to be kind of responsible for deciding what this should be and what it should not be.

     

    It’s really hard for people to list out non-goals when they’re thinking about planning and things like this. If everything was allowed to be everything, then our software wouldn’t be valuable. Everything would just be huge frameworks and they would do everything. You have to have somebody who’s sort of in charge of the vision and where we want to go.

     

    After that, I think the process for getting changes into the framework, or getting changes into the project, to me, it’s kind of do whatever works. I think the reason that React has the approach that it has is probably because the folks that are investing directly in React, a lot of them work here at Facebook and they’re trying to solve real problems for real engineers that happen to also be at Facebook while simultaneously meeting the needs of the community.

     

    We tend to — While we would happily accept any sort of RFC process and any proposal and things like that and we will evaluate it, we tend to focus on the roadmap that we’ve planned out for the past six months, to a year, first and foremost. Then, the other things, like the other parts of the — Anything that Elsa had suggested is, “Oh, yeah, Definitely. We want to get to this.” We’ll add it to our list of things to focus on in the future when we do our next round of planning.

     

    Right now, we’re driven by — We have a very specific goal. If you contribute to that goal, it is very likely that your contribution will be not only accepted, but appreciated very much. If you’re working on something else, it might take a little bit longer to get it than — I don’t know if that answers your question about the RFC process versus the closed core team. I guess it catches me a little bit by surprise, because I don’t necessarily — I don’t think we’re actively trying to be a close core team. I think it is just a sort of implementation detail of how the team is currently structured, but we would be happy to revisit it for sure.

     

    [0:46:03.5] Q: Yeah, interesting. I think the RFC process if interesting, especially Ember’s, and I’m curious to see, I don’t know what other projects have that similar process. Even the communication of that makes it seem a little bit more opening, if that makes sense.

     

    [0:46:22.5] TO: Yeah, that makes sense. I think if folks feel, right now, they aren’t allowed to or aren’t able to contribute to React because of its sort of model for development, then this is certainly something that we should definitely consider changing it. I don’t think anyone on the core team is actually thinking about this, so I will bring this up with them.

     

    I do love the RFC process, at least the couple of RFCs I’ve read. I haven’t read an Ember RFC in a while, but there’s also — I think the Graphic UL team tried to adopt a Graphic UL RFC process, and seeing some of that stuff is great. We had a proposal for JSX 2.0 that I think is still under consideration, and we’d love to do when we can find the time here. I don’t think it’s actively trying to be close-source, but maybe we can make it even more open.

     

    [0:47:10.9] Q: Yeah, interesting. Do you think it’s a requirement for companies to dog food their technologies before open-sourcing it? Because, for example, there’s — I’m not sure if this is true, but I’ve heard React Native is not used in large parts of the Facebook app just yet, but it is open-sourced. Do you think it’s a requirement for companies to dog food it first before they open-source it?

     

    [0:47:37.4] TO: Yeah, it’s hard to judge the scale, because we have sort of — I don’t know — Many dozen engineers writing React Native code every day, and we have something like 400 screens across a couple of dozen apps that are using React Native. Because people don’t see many apps that are entirely written with React Native and they don’t see, “Oh! The Facebook main app doesn’t use React native in newsfeed, so React Native is not used by them.”

     

    It’s kind of a little bit — Or maybe our messaging is just wrong on this, but we are using it very heavily internally, but the scale at which we operate, when you have so many engineers, it’s like if all of those engineers aren’t using React Native, is it being used internally?

     

    We have literally hundreds of engineers that write React in React Native every single day. I think this is pretty critical. I actually think we won’t open-source something if we’re not already using it, or if there’s a very special extenuating circumstance. The reason for this is because we’ve done it in the past. We open-sourced a couple of things that we weren’t fully rolled out on in production and we’re like, “Oh! This doesn’t work.” Meanwhile, a bunch of other companies adopted that technology, and then we left them in the dust when we went and pursued something else.

     

    For me, as a manager, whenever somebody comes to me and says, “Hey, can I open-source this thing?” My first thing that I’m looking at is, “Okay. Let me talk to the people that are already using it and make sure they’re happy with it,” because if they’re not happy with it or they don’t exist, the project that you’re releasing isn’t guaranteed to be maintained.

     

    A lot of companies will sort of build something first, open-source it, and then try and get internal adoption through open-source, and I really don’t agree with that approach. I actually think this is one of the reasons that our open-source projects have been at all successful is because they are relied upon heavily by Facebook. We have 1.8, or something, billion users hitting React every single day, and we use a nightly of it. You could rest assure that we’re not going to easily break your app because we always have to find an incremental path from where we are to where we want to be, because it is in production.

     

    Yeah, sort of feel pretty strongly about this, that I recognize that it should be okay for companies to open-source things before they’re using them, but I personally won’t really kind of allow that at Facebook.

     

    [0:50:07.2] Q: Yeah, that makes sense. I think the — Particularly talking about the whole release upgrade path, I think that’s super important. If you’re not testing it internally, it’s hard to know once it goes out in the wild.

     

    I guess I kind of want to move on to some of the lessons learned along the way as you’ve done open-source. Maybe because you’re more focused on the React team, what are maybe some mistakes that you made along the way or things you think you could have done better?

     

    [0:50:37.4] TO: Yeah, one thing we could have done better was skip to the first talk where we presented what React was and then just have Pete Hunt give his second talk from React Europe.

     

    [0:50:48.6] Q: We’ll put that talk in the show notes.

     

    [0:50:51.1] TO: Yeah, that’s perfect. Yeah. Pete Hunt gave a talk entitled Rethinking Best Practices, and the title was actually adopted from a Tweet that was sort of a jab at Facebook after the initial presentation of React. The reason was like we just really didn’t communicate about the problems that we were trying to solve very well, and people got sort of superficially hang up on either Syntax, or the idea that we were going to combine HTML, and JSS, and JavaScript, “Oh my gosh! This is the worst thing ever. I can’t believe Facebook. They’ve been under a rock for so long.”

     

    One thing I think that I would do different if I could go back and do it again, and maybe this actually — Maybe I shouldn’t say this, because I think as a result of it not being super — Not having a lot of people super excited about it. We have this slow burn where we were able to get a couple of key people onboard and make it a lot better before we have to start facing the influx of adoption about a year later. That’s kind of one thing.

     

    I think another thing is React was kind of the first project, or one of the very first projects from our new open-source regime, if you will. Basically, before that, it was a lot of stuff that wasn’t maintained and we didn’t really — It was okay, and it sat there, and it wasn’t super active. With React, it was something that we were actively developing and making better.

     

    Maybe I wouldn’t change that messaging as much. Maybe it was kind of, “Yeah. Look, we announced this thing. Nothing to see here. We’ll call you in a year.” I would like to have been more open about what went into it. I think we were still learning as part of this new open-source initiative, and I would have like to be more open and communicate about what problems we were solving.

     

    I really kind of like — I hate these very splashy launches that claim that they’ve solved everything. I always wanted our messaging for our open-source program to be pretty consistently, “Hey, here is a thing we built that solves a problem for us. Try it out. Let us know if it works for you. We’d love to collaborate if so.”

     

    Often times, our messaging was probably either not that or maybe too grandiose or something like that. One thing is just making sure our messaging is always consistent and our motivations are always consistent. Yeah, communication and sort of being really open about what we’re trying to do and why and fostering a community of even more contributors early on I think would be good.

     

    Another thing I think I’d do differently is just like — No one really knew for a really long time how to contribute to React. It’s super intimidating. The codebase is kind of hard to make your way through, and we’re really improving that with Fiber. The new codebase is a lot more approachable. Even though these underlying sort of architecture is a lot more sophisticated and complicated.

     

    [0:53:42.9] Q: Maybe for listeners who don’t know what Fiber is, do you want to give them a quick —

     

    [0:53:46.4] TO: Absolutely. The short version is we rewrote React and we did so in place. The idea is that we’re going to enable more advanced scheduling over the next couple of years of work that needs to be done rather than the traditional model of just, “Oh! Just render everything.”

     

    Yeah, we’re really excited about Fiber, but along with it comes a new set of contributors, and a new codebase, and it’s fully Flow typed, and it’s a lot more approachable. One thing I might do differently is, early on, document how to actually contribute to React. How did you think in React? Especially since it was such a novel and new concept at the time. There’s so many ideas that we now just take for granted. We’re sick of hearing about them all day, like Virtual Dom. It’s like, “Please. Don’t talk about the Virtual Dom anymore.”

     

    At the time, we didn’t really document what that meant. We didn’t really document what we were going for with that. I would sort of, if I could change something, I would say, “Let’s go back and create an environment where it’s easier to get new contributors on boarded, especially from outside of Facebook.” I would really love to have an even stronger and larger community of actual core contributors, not just around the ecosystem. The React ecosystem is unmatched. It’s amazing. We have so many people building so many awesome things that either work with React, or for React, or on top of it.

     

    I would like to have even more core contributors that are comfortable making decisions on behalf of the framework. Right now, I think, because it’s just been so intimidating to contribute to in the past, we don’t have a ton of core contributors that feel empowered to make decisions on behalf of the framework.

     

    [0:55:21.0] Q: Interesting. That’s a very good answer to that. I guess sort of in similar around of things, kind of going off of some of the lessons you learned, do you have recommendations or tips for people, or companies that are newer to open-source, best practices, or things to avoid, or things to make sure you do.

     

    [0:55:43.5] TO: Yeah, we touched on a couple of them. One of them is at no point should you claim to have solved everything. If you solved a problem and you solved it well and you’re happy with it, ask some others to verify it. Work with one single client. Find one person whose life you’re going to make better. Find one team whose product you’re going to make better or find that first client that’s going to help you vet your hypothesis a little bit.

     

    Then once you have that, then you’re messaging — I think all messaging for all open-source projects should be relatively consistent. It’s like, “Hey, we faced these problems; X, Y, and Z, and this thing helped us solve those. Here is the tradeoff, because everything has a cost, here is what it cost us and we believe that this is the right tradeoff. Let us know what you think if it works for you or if you have any other ideas.”

     

    That would be my first thing, is like just stop coming out with the better React, or the better angular, or the better this, or the better that. Say explicitly what the problems are that you set out to solve. Say how you solve them, and then open-source your code and offer it up to people that can vet and help prove your hypothesis a little bit. I feel like there’s a culture of everybody wants a few minutes of fame. They want something to go viral. They want some top post on Hacker News, or whatever it is. If our messaging was a little bit more humble and a little bit more honest about the problems that we’re solving and the tradeoffs associated with that solution, I think that would be good for everyone.

     

    Another thing is just trying to bring collaborators in early no in an open way and trying to create an environment of inclusive contributors. I think most frameworks, and libraries, and products, and things I’ve seen that are open-source are pretty good about this these days.

     

    [0:57:36.3] Q: Yeah, interesting. That’s really cool. One thing that is less applicable to, particularly, open-source a Facebook — Open-source in general, burnout and abandonment is such a common theme amongst open-source projects. When it’s a small one that one developer put out and it’s not used by that many people, maybe it’s not a huge issue, but once it kind of goes in popularity, that becomes a huge issue.

     

    I guess the problem though is that we’re human and we — A lot of engineers, particularly, they like to build stuff. They like to solve problems, but they’re not necessarily into the whole maintenance part of it, and the support part of it. It’s completely natural for someone to have found excitement in solving the problem, solving the problem through the open-source technology, but then losing interest later on. How do you kind of manage this within Facebook, as well as how would you — What are some recommendations you might have for just the general open-source community around this?

     

    [0:58:38.5] TO: This is very real. It happens absolutely all the time, especially

    —Huffduffed by maicki

  10. Ron Gilbert: “From Maniac Mansion to Thimbleweed Park” | Talks at Google

    Veteran game designer Ron Gilbert has been making games since the 1980s, most notably as writer, programmer, and designer for LucasFilm Games / LucasArts, producing classics like Maniac Mansion, Monkey Island, and Indiana Jones and the Last Crusade. Today he is putting the finishing touches on his crowdfunded pixel-art puzzle adventure Thimbleweed Park.

    In this lunchtime interview at Google, we use the rare opportunity to talk to a developer who knows both the technical side - Ron likes to code the engine behind his games himself - as well as the creative side of designing games that are still remembered 30 years after their release. We retrace his path from the early days of DOS software into the post-Kickstarter world of crowdfunding, learning how he initially got into the industry and why his latest ode to the 80s still flaunts its big blocky pixels.

    ===
    Original video: https://www.youtube.com/watch?v=KgzWorfLjeE
    Downloaded by http://huffduff-video.snarfed.org/ on Tue, 11 Apr 2017 03:38:20 GMT Available for 30 days after download

    —Huffduffed by maicki

Page 1 of 29Older