185 iPS Why I'm Not A React Native Developer with Ariel Elkin

00:00 2654
Download MP3


  • Ariel Elkin
  • Why I Am Not a React Native Developer 1:20: React Native
  • Functional reactive programming
  • Reactive architecture
  • Inconsistent state 7:15: Context of iOS app9:50: Developing in React Native
  • What went well
  • What didn’t go well 18:45: JavaScript patent
  • Example with Facebook
  • Example with Airbnb
  • Patent trolling 29:30: More concerns with React Native
  • Ubuntu
  • Parse


How to Disagree by Paul Graham (Ariel)Bullet list of what real programmers are (Ariel)Chainsawsuit comic (Ariel) Hired.com/iphreaks


Jaim:             Hey everybody and welcome to the iPhreaks show. Today on our panel we have Andrew Madsen.Andrew:       Hello from Salt Lake City.Jaim:             I’m Jaim Zuber from cold Minneapolis. Today we have a guest, we have Ariel Elkin. Ariel, can you say hi?Ariel:            Hi everybody, I’m from London, England.Jaim:             We brought you on the show because you had done an article a month or two back on your experiences with React Native entitled Why I’m not a React NativeDeveloper? Can you tell us a little bit about that?Ariel:            The article came about because the company I was working on at that time had asked me to give React Native a trial. I was working as an iOS developer at thattime. I had worked on a couple of apps for that company and a dozen more priorto that. The idea was to make this new internal app using React Native and alsoevaluate its potential for migration towards React Native away from Xcode andAndroid studio.Jaim:             We’ve discussed React Native on the show but can you give us a real briefintroduction of what it is?Ariel:            React Native is a cross-platform development framework that allows you to write apps in the target iOS and Android using a single code base. Traditionally, youwould have an Objective-C or Swift code base for your iOS apps and then youhave to make a separate Java code base for your Android apps. The idea behind across-platform framework is just have a single code base written in a singlelanguage and [00:01:59] a compiler and then you get binaries at work on iOS andbinaries at work on Android.One of the strong selling points of React Native is that, the contrary to many of other cross-platform development frameworks that we have seen up to now which produce what’s really a mobile website wrapped inside a webview. React Native allowed you to write code that produce an app that’s used Native, fully Native user interface components. You’re not seeing JavaScript and HTML inside a web, rather UI Kits, UI Kit objects, UI controls, UI views, UI buttons being produced out of JavaScript or JXS code. That’s why they added the Native bit to Swift.At the same time, another thing that’s really appealing about React Native is that, it reuses the React framework which allows functional reactive programming which is a pretty compellingly to think about user interfaces and your app as a whole.Andrew:       Can you briefly say what that really means, functional reactive programming orusing reactive architecture to build an app? How was that different from what anormal iOS developer does when they’re using UI Kit?Ariel:            What we normally do on iOS is we specify all of the steps required for the OS that generates the UI. We subclass a UIview and then when I like the difference is to have a public variable which has a property observer and whenever the superview of the child UI view updates that variable, then whatever is on the codeon the property observer automatically updates user of the interface on thatchild view.The point is you specify the steps required to update the UI. In React’s declarative paradigm, just going to take this from the documentation, you simply express how your app should look at a given point of time and React will automatically manage all UI updates when your underlying data changes. When you update the state inside the app, when the model on your data itself changes, React takes care of all the plumbing required to make a change in the UI.This is much easier to see and code. An easy way to think about it is that you compare a for-loop, suppose you have an array of numbers and you want to sort them, you can sort them using a for-loop, but you can also sort them, which should be an imperative way but you can also sort them using the sort function on an array. The latter is the declarative functional way to do it. Don’t specify all the steps required but write a function that had a list required within it. I think of it as essential, I think it’s a bit of difference between a for-loop and that step in that sort function [00:05:53] an array.Andrew:       One of the big draws of using this is that, a lot of the bugs that come up inwriting a typical UI are basically problems where you don’t correctly maintainstate. State becomes inconsistent. That is the state that is determining howyour UI looks or reacting to changes in that state to update the UI reactiveprogramming you don’t do that kind of programming. You say how you want the UI to look in terms of [00:06:25] instead of managing all of that yourself.Ariel:            That’s exactly right. You don’t manually update the views yourself. One of the results of this is that, you end up thinking about UI elements and other things in your app as functions rather than instances of classes. They take an input and theyreact with the result. The purpose of a React component is the basic building block of the React app. The purpose of the component is to return itself on the state it’s supposed to be when requested.Jaim:             What does this mean in the context of iOS app? If you’re data file iOS developer would choose your background, [00:07:22], now you’re doing it in JavaScript. If you want to create a simple app that shows itself on the screen, how do you do that?Ariel:            The first you do after installing React Native is call, use a command line tool togenerate a new React Native project and that generates an Xcode project withbuild settings, build phases required to work properly with the React NativeSTK. One way to go about it is to create a JavaScript file or use a pre-existingJavaScript file, make a route component, class route extends component and thenyou override the render function of that component and that rendered functionshould return all the child components of that pre component. There, you wouldjust write JS Xcode which specifies the component that should returns.Once such component again is a class child component that extends component and again will have a render function which you override and then you check the state is. According to the state of that component, you return views. View in this case is a kin to a UI view. You style it similar to the way you would style things in the CSS, specify a background color with [00:09:14] and put it in the data syntax similar to, it looks like a blend of HTML tags and CSS in between which is a JSX of JavaScript+, this extension that lets you fix something similar to HTML and CSS which is really useful for expressing this kind of UIs.Jaim:             You spent a number of time developing a React Native, what went well with theproject?Ariel:            Many things, many things. To start with, we’re talking about the declarative styleof programming was a breath of fresh air. I found that to be a really usefulway to think about user interfaces and they were good to be relieved that theresponsibility of manually updating views myself. All you update is state. Theplumbing is already taken care of for you. That was a big breath of fresh air.Another thing I loved on the React Native was how fast the development cycle is. We’re used to writing our Swift or Objective-C code and hitting a command arm and then waiting for the app to compile, waiting for the binary to form and then transferring that binary over to the simulator or device and then you’re taking to the app it’s in the state it is upon start up. For medium to large apps, you’re talking about 30 seconds or 20 to 30 seconds on average  for you to see the changes that you just wrote.The more you code on iOS, the more used you can get to this delay. But it’s something that really surprise me, how fast an iOS development could be. React Native does the extremely fast development cycles because it’s not recompiling your whole app. Your app is compiled just once and then the changes you make to the JavaScript code are injected into the running app whether it’s on simulator or the device. You hit command R on the simulator or on the device and the app is instantly reloaded, the JavaScript is instantly reread and the app is instantly regenerated. You have to wait probably less than a second or two and you get the same result you’d get if you hit command R in Xcode.The React Native team went even further and decided to implement something called the hot reloading. This is something that addresses those development scenarios when you’re working on a particular piece of UI that’s deep down in your navigation stack. Think about a table you sell that’s inside a table that you reach by another table view that you reach by another table view. If you were to modify its UI, whether it’s on the storyboard or whether it’s in a code, whenever you run the app again, you're back at where the app is at start up. You need to literally click on the simulator, drill down in that table view to see if the UI looks the way it’s supposed to.If hot reloading or React Native, the STK reloads just the file that you recently edited. It is not reload the set of all files that you’re app discomposed off. You don’t have to navigate from the start of the screen to the cell to see the changes. The cell, deep down in the navigation stack changes before your eyes. That’s something that web developers are used to. That’s something that came as a innovation to me as an iOS developer. Java was my first language and again, you have to compile and learn your own Java code. It took a while.Over many programming sessions, you’re talking about hours of development time where you’re just sitting, staring at the screen waiting for the app to compile and run and for you to then drill back to the seed you we’re at. That’s a lot of time that saved, a lot, a lot, a lot of time that saved. Of all the benefits that can afford, one of them is that, it doesn’t kill the buzz. I don’t know if you guys had it, you’re working on an app and you’re at the zone, you have this sweet spot of great concentration and then you have to wait for the whole thing to compile to run unto your device. That breaks the momentum a little bit. That pain point is entirely removed with React Native and I loved that. I really, really loved that.One last lovely feature of React Native which is it it’s a cross-platform. I got to make my first Android app, thanks to React Native. All it took was modify the Android great old file, plug in an Android device and it run. It looked exactly the way it looked on my iOS device. The advantages were obvious. You get to reach the millions of users who we’re asking for an Android version. You don’t need to rewrite it all from scratch in Java. Your code will produce the same app on Android. It’s incredibly advantageous.Andrew:       You’ve just gone through all of the things that were really pretty great about usingReact Native for the project you used it for. But the title of your blog postis Why I’m not a React Native Developer? Let’s get into a little bit of yourreasoning there about why is React Native not the perfect solution?Ariel:            To get back to return back into that title again. It’s why me, Ariel, I’m not aReact Native developer. There are many reasons for which it didn’t work for me.But I do acknowledge that it worked out great for other people. Neither my ownpersonal reasons, I’d like to point that out. There were a set of dealbreakers. To briefly go over them, there is at that time, the road maps wherethe development of React Native was [00:16:50]. The league of these was reallynot scary. React Native also required you to use JavaScript, which is for me isa problem for a set of reasons. Finally, the fact that you have to deal withmany, many dependencies as a result of using JavaScript but you also rely on ahundreds of other people’s code to use the React Native.Andrew:       I think we can spend plenty of time on some of the shortcomings of JavaScriptbut I think the patent that you talked about is something that probably mostpeople don’t consider it right away. It’s just out of most developers mindsanyway most of the time. Let’s talk a little bit about that.Ariel:            Sure. You have a standard [00:18:59]  style license and in addition to that, a lot of other Facebook open source projects, we have a file that’s the additional grant of patent rights version 2.0. It’s a document that’s a bit schizophrenic, that’s multiple personality. It starts by granting you a perpetual worldwide royalty free, non exclusive, irrevocable license to use React Native and then you get the falling clause. “The license granted hereunder will terminate automatically and without notice if you initiate directly or indirectly or take a direct financial interest in anypatent assertion against Facebook or any of its subsidiary or corporateaffiliates against any party such patents assertions arises in all earningpoint from any self toward technology product or service of Facebook under thatagainst any party relating to the software.”                     I’ma lawyer and as a lawyer, we should probably clarify this, what this boils down to is that if I, according to [00:20:39] that if I initiate any lawsuit where Iaccused Facebook of patent infringement against my intellectual property, thenmy license to use React Native would be immediately terminated as a result. Theprecise interpretation of this additional grant of patent rights clause is onethat’s more for IP lawyers, software IP lawyers rather than for the softwareengineers. I’m not in the position to provide any qualified advice, but I doknow that one lawyer has provided a pretty pessimistic interpretation.                     It basically says that if, because the scenario that this could lead to is that, youare a  company with wide variety of products. You develop your own IP and you develop your own apps and you use React Native on your apps. Say you make jetpacks which can be controlled with virtual reality or something. You have an app for it that uses React Native. Facebook could, say, steal your IP for the jetpacks. If you were to get into any kind of litigation against Facebook for IP infringement, the license granted hereunder by the additional grant of patent rights would terminate automatically and without notice.Jaim: That seems a little farfetched but Facebook is a huge company that does tons ofthings. They’re doing news and analytics. They have their hooks in a lot ofdifferent areas. If you’re a large company, this is a real concern. I’ve talkedwith other companies like [00:23:15] breaker for us because, if you get to a [00:23:19] with Facebook over something and they can shut off your code, that’s a real problem. Maybe if you’re a startup, you’re going to the radar and you have no chance of going after Facebook with any patent stuff regardless of what theydo. But if you’re a large company, that risk becomes pretty large.Ariel:            Airbnb uses and contributes to React Native. They’re happy to [00:23:49] and obviously this is because they did not believe that this patent situation imposes any threat to them. Does it propose any concrete threat to anybody? This is reallya question for lawyers to decide and I would also like to add that to myknowledge, this is never been taken to court. There have been no precedentswhere Facebook actually had to invoke this clause. But a lawyer did point outthat there was good reason to be worried. Even a generous reading of this additional grant of patent rights does seem to lead the possibility of Facebook to look further [00:25:08] patents and with a lot of breathing room.                     The fact that Facebook happens to be a serial IP infringer today reassures melittle if it possible for Facebook to become serial IP infringer tomorrow andpunish retaliation for my side by revoking my license to use React Native. Thisis pessimistic but it’s a good idea to think of worst case scenario in computersciences but we do to evaluate are algorithms. We don’t care if an algorithmdoes extremely well one percent of the time. We care how badly it can possiblyto take the typical linear search algorithm.                     Linear search algorithm will perform extremely well if the target value is the firstone on the list, they will perform ultimately. But they will perform verypoorly if the target value is at the end. It’s possible for the target value tobe at the end. If we evaluate our algorithms based on worst possible case, weshould evaluate software licenses in the same way.Jaim: That makes a lot of sense. The people at Facebook might be benevolent now butshareholder takeover, someone else is in charge, they suddenly decided so theirfiduciary duty they go after people like this. It just happens and this is alot.Ariel:            Patent trolling is a thing. People make money out of patent trolling other people.Facebook is doing very well now with their core businesses. Will this situationbe the same 50 years from now? 100 years from now? We don’t really know. Iguess the main reason for which I worry about is, it’s not really that I haveany particular grudge against Facebook as the company itself because Facebookhas kept very silent, too silent about this document. I’m not the first one toraise this issue. You’ll find many GitHub issues and form posts wheredevelopers voice their concerns about the additional grants of patent rights inReact and then React Native 2.0.The only response from Facebook was given from developers.No lawyer, to my knowledge no member of Facebook’s legal department spoke out in clarifying matters. We assured everybody as we hold [00:28:37] the case that we have nothing to worry about and there’s nothing sinister about this additional grant patent rights. If there is nothing sinister about the additional grant of patent rights, why wouldn’t Facebook say so? It wouldn’t really custom anything to publish to make a formal statement and say, “Guys, there’s no reason to worry. We will not patent troll anyone in the future. You have the wronginterpretation because of A, B and C or motivations including the additionalgrant of patent rights such and such.” Why the silence?Jaim: There are undoubtedly an army of lawyers within Facebook saying to that [00:29:20].Ariel:            You can neither confirm nor deny, there will be patent trolls in the future.Jaim: So Ariel, along with the patent stuff, let’s talk about some of the other concernsthat you had with React Native.Ariel:            One of them was the fact that at the time I wrote the article, there was no clearlong term explicit long term commitment from Facebook for the project. Therewas no road map of features.What were the upcoming features for React Native? What is this thing going to beimplemented by the end of this year? Was it ever going to be implemented? Werethey aware of this bug? What should developers be on a lookout for? What was ofFacebook React Native team going to work on for the foreseeable future for thiscoming year for the next year, that’s something that a common practice in opensource platform makers so you can think about Ubuntu.                     Ubuntu has a long term support plans. Ubuntu will publish a desktop and server release every six months and that will come out reliably. If you go to their website, you’ll see that your version of Ubuntu will be supported until 2016 and then you’ll know that any graph shows that your version of Ubuntu will be superseded by a new version until 2019. It is a concrete form of commitment by the Ubuntu makers. It will keep releasing suggestion updates to your platform because this is the crucial bit.                     The React Native is not a component of your app. It’s not a networking library. It’s not a JSON parsing library. It’s the entire platform your app is developed on.If it were to develop on [00:32:07], if Facebook were to give up React Nativefor any reason then the community would have to keep developing it. That mightnot be a situation you would want to be. That has happened in the past before.One such example was the Parse platform which Facebook acquired and then killed for some reason and many people, I mean myself included was heavily relying on Parse.Jaim: Parse is a platform that made money [00:32:50] charge for their services for ReactNative is probably that driving revenue for Facebook.Ariel:            Yeah, there is that. Even if Parse lets you have a local database and a remotedatabase for you to store data from your app, if that [00:33:17] called fromother that and you have to switch to something else, it wouldn’t be at thecomplete end of the world. It still a component, it’s not the entire underlyingsoftware development platform. Your app is entirely dependent on React Native.It’s not just [00:33:37], it’s the own platform. Will the community ensure thatthe project survives? Maybe? Maybe not?                     I was not particularly satisfied with the Parse open source service. It workedgreat for very basic functionality at the time we adopted it which was a coupleof months after the Parse server went open source. But in projectionenvironment, that’s not a satisfactory. [00:34:26] has improved the situation onthat respect a month ago, the React Native wiki on GitHub now has a roadmapwhich, I quote, outline some of the upcoming plans for React Native. It’s agreat step forward and I guess it’s very important to know when the change isto the core library to the, will there be breaking changes in the future?That’s great information. We haven’t heard anybody from Facebook say, “Guys, we will maintain React Native for lifetime of your app.” That’s an important concern.Jaim:             I agree. If you’re investing tons of money at your app, if you’re hiring team ofdevelopers, five, ten developers, you could have millions of dollars investedin your app and also the platform that you’ve been working on disappears.That’s a big source of risk for companies. It’s something you can’t just reallydiscard. You have to take it on. I don’t think it’s the end of the world for alot of companies to think something will come up. That’s okay but you should beaware of the risk.Ariel:            Another thing is that, neither Apple nor Google have offered to coordinate [00:36:05] with Facebook nor did they consider React Native as a first class citizen on their ecosystems. Facebook isn’t counting, to my knowledge, with any formal support or coordination from the makers of the platforms that React Native is targeting which is a bit ironic when your aim is to reduce silos. It takes 15 minutes to drive from the Facebook headquarters to the Google headquarters and another 15 minutes to drive from Apple headquarters.                     If Mark really cared about coming costs on mobile development, then he would take Larry and Tim out to lunch one day and ask them to support whether in tech or in spirit his cross platform mobile development efforts. But to this dayneither Larry nor Tim have pronounced one word in favor of React Native. Infact, Tim pushes for improving Apple’s software development platform to make ita superior to any alternatives. Larry is pouring money into competing crossplatform development framework, mainly Flutter which allows to write crossplatform iOS and Android apps in doc.                     This speculation admittedly but the problem is that there is too much room for speculation if you trust Facebook. If you trust having no promises from Facebook then if you trust Facebook enough to not have any promises from them to keep maintaining your software development project then that won’t be a problem. If you don’t, then that will be a problem. But I don’t want to have to trust, I just want to form a commitment.Jaim: That’s good. We’re running a little bit low on a time. Anything else you want to tellus about before we get to the picks?Ariel:            There’s one thing I would like to point out, that is I don’t wish in any way, it is notmy intention in any way to demonize React Native or Facebook. I believe thatthe Facebook and React Native team made an incredibly strong and fantasticeffort to make a great cross platform development framework. They haveobstructed the sense of essential UI Kit components, they ported CSS [00:39:22].They wrote and assembled development tools needed for you to endlessly seeJavaScript files come to life as an app on an iOS simulator or device and anAndroid too.                     They’ve done an amazing effort. It’s just that I believe that there was none in theright direction. At the same time, one of the reasons that I wrote the articleis because I saw that there was a lack of critical evaluations of React Native.There’s a general lack of critical evaluation to new platforms and frameworks.A typical blog post you see lacks lyrical about how great a platform is and howgreat a library is.                     It’s of course, it’s extremely important for us to point out the strong points oflibraries but these articles should be more balanced. This is part of a trendwhich I guess we’ve all noticed which is critical [00:40:42] not being nice.You should be. Therefore, you should not be critic. I think there are ways tobe nice and critical at the same time. I think we should not confuse the two.Jaim: That makes a lot of sense, I think. It’s important to have a culture where you cansay that things aren’t perfect and there’s always tradeoffs. If you’ve beendoing this long enough, if you realize there are tradeoffs with any approachyou take, it’s going to work in some cases and not in some cases. Let’s get tothe picks. Ariel, what do you have for us?Ariel:            I have three picks. One is directly relevant to what we’re just talking about isone of the world’s greatest essays written by Paul Graham which is How toDisagree. He explains how to disagree, what’s hard to distinguish good qualitydisagreement from bad quality disagreements. That’s one of the foundationalguidelines of the Wikipedia community for instance. He basically makes abeautiful [00:42:06] case for disagreeing critically and [00:42:14] passionforce but also constructively.                     The second one is a bullet list of what real programmers are. It’s a funny list ofdefinitions of what real programmers are. One of them for instance is realprogrammers never work nine to five. If any real programmers are around at nineam, it’s because they were up whole night. Another one, to poke fun at myselfand my criticism to JavaScript is, real programmers never program [00:42:57] noobjects.                     Another one of my picks is a comic chainsawsuit which I love. In this particular comic is a criticism on how people tend to do a lot of research nowadays. Maybe I’m also deserving of that criticism.Jaim: Awesome. I’m looking forward to checking those out. Thank you so much for coming on the show, Ariel. It’s been a good [00:43:30] of you of some of the downsides of React Native. As you mentioned it’s a great tool but it might not be for everyone. Thanks for sharing your experience.Ariel:            My pleasure. Thank you again for having me on the show and one last thing, let’snot confuse criticism with contempt. I do not have contempt for React Native. Ijust want to offer some criticism to make the discussion more balanced. That’sit.Andrew:       I think that’s good. Thanks, Ariel.Ariel:            My pleasure. Thank you guys. It was great talking to you. 

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.