Hacker News new | past | comments | ask | show | jobs | submit login

Having worked on a large native codebase with RN features integrated for a couple of years now, there are a lot of downsides for our particular use case. I am aware that some of these are organizational rather than strictly technical issues, but I think there are very few organizations that would not face similar hurdles:

- Instead of 2 platforms to support, we now have 3

- Debugging issues that cross Native <> Javascript is a nightmare. Only a few developers are skilled enough to do it well. Even then, the overhead involved in determining with certainty that the issue is on the native or the JS side and engaging the relevant developers negates most savings.

- Code that's shared across teams is difficult to share with the JS teams and vice versa. Consistency between native and RN is poor.

- Adding JS to the codebase exploded our dependency graph. One feature team introduced over 700 (!) dependencies via npm, which brings me to:

- Enforcing code/quality standards is difficult. Same app, completely different tech stacks

- Educating JS developers about ensuring compatibility with native dependencies is an ongoing expense

- Massive new attack surface area is now exposed via the increased dependencies (see https://hackernoon.com/im-harvesting-credit-card-numbers-and...)

I can go on. I think it's actually a super cool and ambitious technology. I had the opportunity to hack on some of the internals as part of an exploration to see how easy it'd be to share our native UI components with it, and that was pretty darn fun. It's just very, very poorly suited for integration with an existing large codebase, and decidedly not a miracle solution.

If I were bootstrapping a startup with no existing codebase and needed to target web, Android and iOS it'd be a no-brainer to use RN, but that's a quite different scenario.

Is there some subset of native capabilities that one can still attack with an RN codebase and not have to deal with the native <> JS issues you ran into? Say, my app "only" needed to access contacts and images (no GPS; no bluetooth; not take pictures; not worry about accelerometer; etc.) - in your experience, does that put RN back in the picture (somewhat)?

You can do just about everything a native app can do with RN. If you have a very small, capable team that's all on the same page, it's a good choice. For large existing codebases in large organizations, it's a very poor choice.

Having worked alone with react-native for about 3 months now and building our production application, I'll go further and state that for certain kinds of tasks React Native is definitely the way to go, but if the requirements seek heavy background work or involving multiple threads native code seems to be way to go. I'd love to hear your thoughts on Flutter. Cross compiling to native seems to give us the gains with respect to almost close to native performance too.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact