185

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


Introduction

1:20: React Native

  • Functional reactive programming
  • Reactive architecture
  • Inconsistent state

7:15: Context of iOS app

9: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

Picks:

How to Disagree by Paul Graham (Ariel)

Bullet list of what real programmers are (Ariel)

Chainsawsuit comic (Ariel)

 

Hired.com/iphreaks

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

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 Native
Developer? 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 that
time. I had worked on a couple of apps for that company and a dozen more prior
to that. The idea was to make this new internal app using React Native and also
evaluate its potential for migration towards React Native away from Xcode and
Android studio.

Jaim:             We’ve discussed React Native on the show but can you give us a real brief
introduction 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, you
would have an Objective-C or Swift code base for your iOS apps and then you
have to make a separate Java code base for your Android apps. The idea behind a
cross-platform framework is just have a single code base written in a single
language and [00:01:59] a compiler and then you get binaries at work on iOS and
binaries 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 or
using reactive architecture to build an app? How was that different from what a
normal 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 super
view of the child UI view updates that variable, then whatever is on the code
on the property observer automatically updates user of the interface on that
child 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 in
writing a typical UI are basically problems where you don’t correctly maintain
state. State becomes inconsistent. That is the state that is determining how
your UI looks or reacting to changes in that state to update the UI reactive
programming 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 they
react 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 to
generate a new React Native project and that generates an Xcode project with
build settings, build phases required to work properly with the React Native
STK. One way to go about it is to create a JavaScript file or use a pre-existing
JavaScript file, make a route component, class route extends component and then
you override the render function of that component and that rendered function
should return all the child components of that pre component. There, you would
just 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 the
project?

Ariel:            Many things, many things. To start with, we’re talking about the declarative style
of programming was a breath of fresh air. I found that to be a really useful
way to think about user interfaces and they were good to be relieved that the
responsibility of manually updating views myself. All you update is state. The
plumbing 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 using
React Native for the project you used it for. But the title of your blog post
is Why I’m not a React Native Developer? Let’s get into a little bit of your
reasoning 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 a
React 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 own
personal reasons, I’d like to point that out. There were a set of deal
breakers. To briefly go over them, there is at that time, the road maps where
the development of React Native was [00:16:50]. The league of these was really
not scary. React Native also required you to use JavaScript, which is for me is
a problem for a set of reasons. Finally, the fact that you have to deal with
many, many dependencies as a result of using JavaScript but you also rely on a
hundreds 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 JavaScript
but I think the patent that you talked about is something that probably most
people don’t consider it right away. It’s just out of most developers minds
anyway 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 any
patent assertion against Facebook or any of its subsidiary or corporate
affiliates against any party such patents assertions arises in all earning
point from any self toward technology product or service of Facebook under that
against 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 I
accused Facebook of patent infringement against my intellectual property, then
my license to use React Native would be immediately terminated as a result. The
precise interpretation of this additional grant of patent rights clause is one
that’s more for IP lawyers, software IP lawyers rather than for the software
engineers. I’m not in the position to provide any qualified advice, but I do
know that one lawyer has provided a pretty pessimistic interpretation.

                    It basically says that if, because the scenario that this could lead to is that, you
are 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 of
things. They’re doing news and analytics. They have their hooks in a lot of
different areas. If you’re a large company, this is a real concern. I’ve talked
with 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 they
do. 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 really
a question for lawyers to decide and I would also like to add that to my
knowledge, this is never been taken to court. There have been no precedents
where Facebook actually had to invoke this clause. But a lawyer did point out
that 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 me
little if it possible for Facebook to become serial IP infringer tomorrow and
punish retaliation for my side by revoking my license to use React Native. This
is pessimistic but it’s a good idea to think of worst case scenario in computer
sciences but we do to evaluate are algorithms. We don’t care if an algorithm
does extremely well one percent of the time. We care how badly it can possibly
to take the typical linear search algorithm.

                    Linear search algorithm will perform extremely well if the target value is the first
one on the list, they will perform ultimately. But they will perform very
poorly if the target value is at the end. It’s possible for the target value to
be at the end. If we evaluate our algorithms based on worst possible case, we
should evaluate software licenses in the same way.

Jaim: That makes a lot of sense. The people at Facebook might be benevolent now but
shareholder takeover, someone else is in charge, they suddenly decided so their
fiduciary duty they go after people like this. It just happens and this is a
lot.

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 situation
be the same 50 years from now? 100 years from now? We don’t really know. I
guess the main reason for which I worry about is, it’s not really that I have
any particular grudge against Facebook as the company itself because Facebook
has kept very silent, too silent about this document. I’m not the first one to
raise this issue. You’ll find many GitHub issues and form posts where
developers voice their concerns about the additional grants of patent rights in
React 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 wrong
interpretation because of A, B and C or motivations including the additional
grant 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 concerns
that you had with React Native.

Ariel:            One of them was the fact that at the time I wrote the article, there was no clear
long term explicit long term commitment from Facebook for the project. There
was no road map of features.

What were the upcoming features for React Native? What is this thing going to be
implemented by the end of this year? Was it ever going to be implemented? Were
they aware of this bug? What should developers be on a lookout for? What was of
Facebook React Native team going to work on for the foreseeable future for this
coming year for the next year, that’s something that a common practice in open
source 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 Native
for any reason then the community would have to keep developing it. That might
not 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 React
Native is probably that driving revenue for Facebook.

Ariel:            Yeah, there is that. Even if Parse lets you have a local database and a remote
database for you to store data from your app, if that [00:33:17] called from
other that and you have to switch to something else, it wouldn’t be at the
complete end of the world. It still a component, it’s not the entire underlying
software 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 that
the project survives? Maybe? Maybe not?

                    I was not particularly satisfied with the Parse open source service. It worked
great for very basic functionality at the time we adopted it which was a couple
of months after the Parse server went open source. But in projection
environment, that’s not a satisfactory. [00:34:26] has improved the situation on
that respect a month ago, the React Native wiki on GitHub now has a roadmap
which, I quote, outline some of the upcoming plans for React Native. It’s a
great step forward and I guess it’s very important to know when the change is
to 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 of
developers, five, ten developers, you could have millions of dollars invested
in 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 really
discard. You have to take it on. I don’t think it’s the end of the world for a
lot of companies to think something will come up. That’s okay but you should be
aware 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 day
neither Larry nor Tim have pronounced one word in favor of React Native. In
fact, Tim pushes for improving Apple’s software development platform to make it
a superior to any alternatives. Larry is pouring money into competing cross
platform development framework, mainly Flutter which allows to write cross
platform 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 tell
us 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 not
my intention in any way to demonize React Native or Facebook. I believe that
the Facebook and React Native team made an incredibly strong and fantastic
effort to make a great cross platform development framework. They have
obstructed the sense of essential UI Kit components, they ported CSS [00:39:22].
They wrote and assembled development tools needed for you to endlessly see
JavaScript files come to life as an app on an iOS simulator or device and an
Android too.

                    They’ve done an amazing effort. It’s just that I believe that there was none in the
right direction. At the same time, one of the reasons that I wrote the article
is 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 how
great a library is.

                    It’s of course, it’s extremely important for us to point out the strong points of
libraries but these articles should be more balanced. This is part of a trend
which 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 to
be 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 can
say that things aren’t perfect and there’s always tradeoffs. If you’ve been
doing this long enough, if you realize there are tradeoffs with any approach
you take, it’s going to work in some cases and not in some cases. Let’s get to
the picks. Ariel, what do you have for us?

Ariel:            I have three picks. One is directly relevant to what we’re just talking about is
one of the world’s greatest essays written by Paul Graham which is How to
Disagree. He explains how to disagree, what’s hard to distinguish good quality
disagreement from bad quality disagreements. That’s one of the foundational
guidelines of the Wikipedia community for instance. He basically makes a
beautiful [00:42:06] case for disagreeing critically and [00:42:14] passion
force but also constructively.

                    The second one is a bullet list of what real programmers are. It’s a funny list of
definitions of what real programmers are. One of them for instance is real
programmers never work nine to five. If any real programmers are around at nine
am, it’s because they were up whole night. Another one, to poke fun at myself
and my criticism to JavaScript is, real programmers never program [00:42:57] no
objects.

                    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’s
not confuse criticism with contempt. I do not have contempt for React Native. I
just want to offer some criticism to make the discussion more balanced. That’s
it.

Andrew:       I think that’s good. Thanks, Ariel.

Ariel:            My pleasure. Thank you guys. It was great talking to you.

 

x
New to Programming? Learn to build a career at Newbies Remote Conf
x