[t1amat]

I've been playing a lot with React Native over the last year; professionally for almost 4 months now. This really aligns with my experience. I don't share the same opinion of going back to native code though.

This really is a fantastic platform. You really can, today, write native cross platform and web apps with the same code base. With few exceptions, everything from including native modules to upgrading is painless. The UI metaphor is fantastic, the tooling is superb, the editor support is there, the community is growing. It's a great place to be.

It's not without it's warts though. From my experience, the real problems stem from the 3rd party native modules. It's not even their fault, the platform is just moving so fast. As recently as the 0.40 release, every native module out there was broken on iOS for a short period of time. I was the first to submit PR's to two fairly widely used ones, and that was multiple days after the release. On this point, I believe this is more indicative of a community that generally doesn't upgrade their projects right away- a combination of painful prior experience and a deep seeded distaste of having to re-release their app on all stores as you can leverage a tool like Microsoft Code Push to change the bundle as long as it is compatible with the native shell.

Of the two RN projects I'm working, both have at least one dependency pinned to a Github fork I have of a project, waiting for my patches to be released. This sounds worse than it is, as the majority of native modules are hilariously small and easy to modify, but it still is worth mentioning as a point of friction today. As the community grows, I expect this will diminish.

[htormey]

Yep, exactly my experience. I love React Native but if your not used to the Javascript style of million's dependencies your in for a world of pain.

It's critical to spend more time vetting third party React Native/Javascript libraries as the quality level varies way more than with native libraries.

As a native developer I hadn't spent a lot of time working deeply with npm. One thing to be careful about when saving packages to your project is the use of ^ versus ~. See:

http://stackoverflow.com/questions/22343224/whats-the-differ...

" the tilde matches the most recent minor version (the middle number). ~1.2.3 will match all 1.2.x versions but will miss 1.3.0.

The caret, on the other hand, is more relaxed. It will update you to the most recent major version (the first number). ^1.2.3 will match any 1.x.x release including 1.3.0, but will hold off on 2.0.0."

Considering the volatility of some third party Javascript libraries, this can cause quite a bit of pain.

It's worth doing the following in your home directory add save-prefix=~ to your .npmrc and all npm install's in the future will automatically add ~ instead of ^

[cageface]

I recommend pinning to exact versions and using a tool like npm-check-updates when you want to upgrade to newer versions of libraries. We had a lot of problems with breakage due to different developers having slightly different versions of dependencies.

React Native is a great platform but it's still very fragile, particularly on Android.

[Matthias247]

I recommend that too. I only used the npm ecosystem for a short time, and still had dozens of silent breakages from libraries which were expected to update in a backward compatible fashion. And even if a dependency itself is pinned to an exact version, it might be that the transitive dependency of this thing changes and breaks. npm shrinkwrap and yarn are supposed to fix that.

[devmunchies]

facebook actually recommends using yarn instead of npm. it has faster install times.

[t1amat]

Yarn is categorically better than npm at dependency management, in addition to its speed. Yarn uses a lock file to pin exact versions no matter what semver range you choose. When you add another dependency, it does not have the side effect of updating other modules. When you run yarn install it downloads the exact package versions described in the lock file rather than the latest version it can get from npm in that range. This ensures you get back to the last working state. Updating modules to the latest in their range is a separate command.

[mamcx]

My main gripe is that for practical purposes is all react-native or nothing.

I will be happy if use React ONLY for the UI, and use swift/.net for all the rest. But merge both is problematic (as far I know).

Exist a way to achieve this? Where I can use react only for the design of the UI and fully native elsewhere?

[macavity23]

It's fairly straightforward but you need to write some Obj-C, I don't think you can do it entirely in Swift yet. It's pretty painless in iOS, YMMV on Android. See here for details: https://facebook.github.io/react-native/docs/native-modules-...

[menckenjr]

All due respect, it isn't really the same code base at all. RN assembles your app from a large list of components based on what your JSX file tells it needs to be imported. If you went and counted LOC you'd probably find that most of the lines of code (outside of the RN backbone) live in those modules. The common code you can share is your JSX.

[t1amat]

While technically correct it's not very meaningful a distinction in context. I'm not tasked with developing all the code required for every platform, I simply have to describe it once. Native platforms will all run off the exact same JavaScript bundle in a different, platform-specific shell. You wind up with a different bundle if you target the web.