React Native 2017 roadmap

blog-post-09-01-2017.md

React Native 2017 roadmap

Don't get confused by the name this is not by any mean a roadmap for React Native. Just something what I would like to see happen.

I started working with React Native soon after it was open-sourced by Facebook. Since then the small experimental project grew a lot. Thanks to 1140 contributors, many of us can build cross platform native apps for iOS and Android with zero or a little knowledge of Objective C and/or Java. A few years ago I didn’t even think that with just web dev experience I could jump and make an app which will be working on iPhone and Android devices.

In this post, I’d like to focus on the things that we can do to make React Native even better.

Please don’t treat this as a rant, these are the things which I find that could be improved.

1. Better error handling (there are a lot of generic errors which can mean multiple things). Usually to solve some issues is just a matter of searching issue tracker on Github or searching through SO, but this certainly discourages new comers and sometimes can be frustrating.
2. Upgrades - there is already work being done on the releases side to stabilise them (see: http://facebook.github.io/react-native/blog/2017/01/07/monthly-release-cadence.html). I’m sure that now that we have more time to test RCs the upgrades will be less painful. But we still can do better here - maybe codemods?
3. Debugging - at the moment debugging slows down the whole app a lot. The application is usually hardly usable.
4. Create React Native App - I think CRA had a big success of breaking the ice between setting up the whole environment and the actual app development. Even if that’s a separate project (not a command in react-native-cli) it would be great to have it. At the moment a great solution to this is Exponent.
5. Android performance/development. I think the Android development is not great, and this is not because React Native, the development tooling (i.e. emulators) is far from great. This area could be improved massively.

I’d like to know what you think and maybe say what are the things that you find that could be improved to make mobile development easier.

Reason -> React implementation in Reason -> compilation to native -> bindings to native mobile APIs -> Outrageous speed improvement

@wokalski I'd love to see that! the main points from here is the DX though. I think that React Native is pretty good in terms of performance RN -> Native.

I think you can have a lot better debugging experience with native code because it will be faster and no JS -> native bridging. however I guess that the tooling for debugging compiled OCaml might not be great and would boil down to debugging generated C code which might be poor experience at the moment but I'm not sure.

https://hal.inria.fr/hal-01245840/document
Ha, I was wrong. It might be actually awesome (at least on iOS side).

debugging experience with native code because it will be faster and no JS -> native bridging

How? Won't every change need a recompilation making it slow?

I don't think I ever had to debug the bridge during my past year of RN development, even though I have worked with a lot of native modules.

Every change won't need a recompilation.

hm, I had to debug a JS module and native code simultaneously. I had two debuggers open and the workflow was a bit of a mess.

@satya164 debugging the bridge happened to me once, but it was because of React bug - passing NSDate was causing a hard to spot exception. But it's been only that.

I believe we should start think of codemods more seriously. Probably it may become a rule: if you add a breaking change - be sure that you covered it by specs + added a codemod. Then react-native upgrade script can work like a "migration"

Codemods can be hard because it's usually not about changes in JavaScript only but Objective-C, C++, Java, and even configurations files, a lot of different syntaxes that should be supported. Let's take 0.40: You have to upgrade .xcodeproj, .xcscheme, *.h headers. And in this case, codemods should be available for upgrading plugins too, to help maintainers keep up with APIs changes.
That being said, I'm pretty ok with react-native-git-upgrade and https://github.com/ncuillery/rn-diff, it really helps a lot.

@Kureev not sure if this is good, I might implement the breaking change and tests, but I'm not so familiar with codemods, it may just discourage from contributing.

also I think @ptmt has a point here. And personally (as I'm not an expert in Objective C or Android) the changes to the native files was the biggest issue for me.

2 @knowbody:

@Kureev not sure if this is good, I might implement the breaking change and tests, but I'm not so familiar with codemods, it may just discourage from contributing.

I have mixed feelings about it. I'd rather have N less features with painless automatic migrations than X more, but with a crazy manual migration.

For instance, 0.40 broke all third-party native modules. There are 15k repos with "react-native" in title on Github. Imagine that 30% of them has some native code inside. ~5k repos needs to be manually updated. Even if we talk about 10 min change, it's about 50k minutes (833.3 hours!) + release notes for each. IMO, that's insane.

2 @ptmt:

Let's take 0.40: You have to upgrade .xcodeproj, .xcscheme, *.h headers.

Most of it can be made using sed -i bak -e s/BEFORE/AFTER/g <file>. Probably you'll have to re-compile your project after that, yeah... But I don't think it's a big deal. Codemod for 0.40 changes can be super small.

@Kureev I totally agree with you, I'd love to have codemods!

I would think debugging would be better if you could attach directly to the jsc on the device using remote debug. Rather than running the js code in the browser.

@knowbody What are some specific problems with Android development? Android emulators crashing, setting up dev environment for the first time (see Getting Started) too much work, or something else?

@mkonicek it still feels to me like the development on various emulators is fragile. Usually very slow, crashing randomly, then working fine after the refresh.

So I'm thinking here about overall experience. I'm not sure if this is Facebook's type of a problem. For example I would love to actually build a new emulator for android, something what would compete with iOS simulator, would that be in fb interest? Not sure if you also face the problems I mentioned above.

Just in top of my head I remember that sometimes things wouldn't work because the cache needs clearing which needs to be done manually. Things like that bring a poor dev experience

@knowbody even when writing pure Android apps, the best emulator I found/tried has been Genymotion. Although premium version is very $$$.

Create React Native App

We have actually started this project, in collaboration with exponent! It should also alleviate upgrading pains for some users because there will be no need (or ability) to maintain native files.

Totally agree on many of the other points, especially improved error handling. Here's a good example of something that should be pushed through: facebook/react-native#8188 (Errors in promises should be redboxes. The louder the error is shown, the better chance there is of it getting fixed.)

I also like the idea of codemods to help with the upgrade path, but we really need to nail the experience if we're going to get much adoption.