Ask HN: Companies who adopted React Native over a year ago, do you regret it? | Hacker News Reader

Ask HN: Companies who adopted React Native over a year ago, do you regret it?

363 pointstekstar145 comments

I'm interested in the opinion of React Native from companies who chose to build their mobile apps with React Native and have been doing so for at least a year. RN passes the first-week smell test really well. How has it held up for you in production? How has it held up for dev teams of ~10 or more? Pros and cons?

I run a mobile team of ~30 folks. In 2015 we experimented with RN for 3 months before deciding that it was not a good fit for us. I'm interested in stories from the alternate reality where we took the react-native path instead.

I'm NOT particularly interested in stories about single devs making prototypes for a weekend. React Native has a delightful experience for this use-case, but it does not directly transfer to being a good experience for a larger team with serious product goals.

Thanks

View on HN

We have a 15-person engineering team and converted our mobile app to React Native at the beginning of this year. We do not regret it. Our pace of delivery is much faster with React Native than what we were able to achieve building natively. Our app has over 100 screens, and only needing to implement features once to have them on both platforms is nice. The feedback loop when making code changes is much faster, especially when writing unit tests. There are some rough edges, but the benefits far outweigh the costs for us.

Our iOS app: https://itunes.apple.com/us/app/root-car-insurance/id1021256...

Our Android app: https://play.google.com/store/apps/details?id=com.joinroot.r...

How do you manage 100+ screens?

I started building a react native app but decided against it because switching activities seemed to be very hacky compared to native development. Seemed like it'd really get out of hand with 10+ screens.

Wix's "React Native Navigation" was too opinionated / inflexible.

The best nav experience I've had with RN is React Navigation: https://reactnavigation.org/

Looks very good, will have to try it out.

I've had an ok experience with React Navigator, but still feels very immature (I was unable to implement relatively straightforward animations on the parent view in a transition), and it also feels like interface builder/storyboards leaves it in the dust in terms of wiring together interfaces and getting a high-level overview of the information architecture of an app.

How does it compare with react-native-navigation?

Kind of difficult to parse the adoption/ecosystem based on download trends[1] for these two

[1]: https://i.imgur.com/etEa7WT.png

I recently gave a talk at Chain React in Portland (first ever React Native only conference) where I compared these two nav stacks:

https://www.youtube.com/watch?v=kFyaj5HmMEY&t=1059s

The situation with navigation and React Native is a bit of a mess right now.

Basically all navigation stacks can be broken down into two categories, those that are native (i.e built on top of the OS's existing navigation stack) and those that are not (pure javascript, emulates what the native stack does).

Examples of Native navigation stacks:

-> React Native Navigation (wix)

-> Native Navigation (Airbnb)

Examples of Javascript navigation stacks:

-> React Navigation

-> React Native Router Flux

-> React Router Native

An example app I wrote with React Navigation + Redux:

https://github.com/hgale/ReactNavigationDemo

Same app but built with React Native Navigation + redux:

https://github.com/hgale/ReactNativeNavigationDemo

The main differences are that the native nav stacks have better performance, stuff like accessibility works right out of the box and they work the same way that the underlying native system works.

The main downside to using Native navigation stacks right now is that setting then up & upgrading them can be a real pain. It can also require native knowledge when things go wrong.

I would recommend staying with react navigation (Javascript based nav stack) unless you absolutely need some feature from one of these native nav stacks.

It's going to be a lot easier to upgrade and you won't run into issues doing over the air updates with your production apps.

It's also the one that Facebook promotes in their docs:

https://facebook.github.io/react-native/docs/navigation.html

Right now both React Native Navigation and React Navigation are under heavy development. No matter which one you choose, budget for some pain in the next year when upgrading.

I would think that having to learn a little about iOS/Android would be a small price to pay for decent performance and accessibility. The idea that those are only sometimes important rather than a necessity is alien to me as a software developer and as a user.

I agree, accessibility is important and in many countries required by law. However using React Native Navigation can be quite a lot of work for a shop that only has JS dev's who've never done native. Using React Native Navigation (or any native dependency) also has implications for your CI system, debugging and over the air updates.

Also you can make an app that has no accessibility problems using React Navigation, you just need to be careful about scenarios where you might have a deep stack. I.e during signup or something that requires several screens on top of one another.

Here is a summary of the bug:

https://react-native.canny.io/feature-requests/p/navigator-b...

It's painful but possible to work around these issues using React Navigation.

I agree and even go one step further by saying that I'd never publish an RN app without native navigation.

I found quite the opposite, it's much easier to manage many activities, I am guessing you were using your own 'routing'? Take a look at react-navigation or react-router (it supports react-native too)

I was looking for libraries that use native code but react-native-navigation was too opinionated and Air BnB's solution wasn't and isn't production ready.

I pretty much put the project down after that and started learning Swift (I already do Android).

Now I decided to go all out on iOS dev with the hope of making a career change from web.

One control per screen

It's actually quite easy

Do you share any of your code base with a web app?

We don't right now. We're a car insurance carrier that uses our mobile app to gather data as people drive. Since all of our customers have our app installed, we haven't looked to building a web app version yet. Although we could reuse some logic on the web, the overlap would be minimal. Most of the code is centered around the UI, and a web app would likely have a very different interface. It would be nice to share some business logic functions, although we tend to not put much of that in the client anyway. Most of it happens server-side, with client hitting APIs to check business rules.

It benefits your dev team, but does it benefit your customers?

How's the battery usage of your RN app vs a real native app? Does your app require the latest phone hardware to run with decent performance?

As one of the designers of this app, I was skeptical initially if there would be restrictions on customizing common UI components, the smoothness of animations/interactions, usability, performance, etc. You definitely have to put in a bit of extra work (isn't that always the case with making things nice though), but you can get very nice results (and battery usage) with RN for sure on both Android and iOS. Personally, I think it does benefit customers to be able to quickly roll out iterations across operating systems at a high quality. YMMV though, what works for one team, industry and customer base naturally doesn't automatically work for everyone. Do you maybe have experience or data points on RN vs. native in terms of battery usage and performance? Would love to hear any insights you can share. Thanks.

One of the reasons I brought this up was a recent article about energy efficiency of programming languages.[1] JavaScript is ~2x less energy efficient than Java, so it will eat twice the battery.

[1] https://sites.google.com/view/energy-efficiency-languages/re...

Wow, that's a great analysis. In addition to being less efficient, there's definitely more overhead with the extra layer of JS underneath. Just of the top of my head, this might be a bigger issue with apps that constantly refresh the screen or have real-time interactions (e.g. games or Slack), and not so much apps that are essentially a series of forms (code only runs when you interact). With our app, what affects battery usage most is the location analysis that happens in the background. It's one of the areas the development team spends a lot of time testing and optimizing.

> JavaScript is ~2x less energy efficient than Java, so it will eat twice the battery.

While the citation you provide is interesting, it doesn't inherently prove that in real-world usage, React Native apps consume twice the power of their native counterparts.

"so it will eat twice the battery" may be nearly true on headless boxes running CPU heavy workloads. Mobile apps are about as far from that as you can possibly get. Sure it's probably a measurable impact, but I would expect it's less of an impact than things like how bright the backlighting is, whether you keep GPS usage to a minimum, how well you minimize and batch network communication, etc, etc. CPU is a small part of a phone's power budget and mobile apps spend a lot of time with the cpu largely idle.

React Native is native. It's nothing like trying to shoehorn rich client functionality and animations into a web view.

JavaScript still much slower and more memory-hungry than Objective C.

Yes, and 99% of the code running in a React Native app is written in Objective-C, because they are native widgets and native libraries (often just the AppKit widget or a wrapper around it). That's why it's called React Native.

The JS runtime is only used to choreograph different native components. It's like a .xib or storyboard but with the ability to do logic. This code runs at user input speed so the relative performance characteristics are irrelevant.

This is worth a look[1]. Make sure to see charts at bottom.

> Swift won overall in the CPU category, React-Native won the GPU category (barely), and React-Native won big time in the Memory category.

[1]: https://medium.com/the-react-native-log/comparing-the-perfor...

Yes, we regret it. Our app is just a wrapper around a webview, and handles things like in-app payments and SDK integrations like Facebook login, in a team of ~10.

Our version of React Native is quite far behind which makes using libraries not already in the project difficult: you have to track back through versions to find a compatible version, which then may not be doing what you want since it's an older version.

We're also having trouble upgrading the version of React Native due to versions having breaking changes. I know it's technically still not v1.0, but in reality a lot of companies are using it so having a stable version would be nice. Since it's unstable, many libraries haven't updated to compensate so you run into the same problem as above, tracking down precise versions of dependencies which also still do what you want.

The build process feels pretty rickety and seems to rely on a lot of global state - I spent a while checking how we could update dependencies, but when I rolled back to a stable version I was unable to build even after re-installing node modules etc. I was only able to fix it after opening Xcode, removing all pod libraries and re-adding them; I have no idea why that worked, and there are very few clues on Github or Stack Overflow as to what specific errors mean. Fixing my build step took the best part of a day.

Overall, for a small app like ours, we're just spending far too long on non-development overhead, like fixing build systems or checking dependency versions, and will probably move to native versions at some point in the future. It may be a pain maintaining two separate versions, but we'll have solid integrations with payment gateways and lots of documentation and info on Github/SO for problems.

I like React and the idea of React Native, but at the moment it just feels far too unstable and unpolished to use. I'd like to use it in the future, but probably not until it's had a major version release.

Why are you using RN if your app is just wrapping a web view?

If you have to ask questions like this, you haven’t been working in the industry long enough.

Haven't been in the industry long enough to do what? Ask questions? It appears you have been working in the industry too long to answer them, which is much worse.

> Haven't been in the industry long enough to do what? Ask questions?

To be jaded.

It's merely a jab at the way we tend to overcomplicate solutions to simple problems. I think.

Yes, that’s right

I was wondering the same thing. It seems like the this may be a case of choosing the wrong tool for the wrong job. Some clarification around the context of the problem could eliminate that possibility. Seems like a fair question.

It's a reasonable question. It's not clear how much interactivity is required outside of the webview, but if there's very little or none, then it would be perfectly reasonable and simple to use the native mobile APIs to wrap the webview.

And thus avoid all the problems mentioned above.

Yep, that's our long-term plan, but saying we want to get rid of our working app and re-write it as two new apps from scratch doesn't go down particularly well with the business.

OK. Let's say that's completely true.

Is snarkily telling someone they're not good enough helpful?

Seems like a moment where you could share what you know (as someone, presumably, has been in the industry long enough) and help someone.

(FWIW it sounds like a decent question to me: but then again undoubtedly I have not been in the industry long enough!)

I wasn’t meaning that at all. I meant that if you have to ask why people solve problems with over complicated solutions, you haven’t been doing this very long.

The answer is: it’s in our nature to make simple things difficult.

It shows more maturity if you just accept people do stupid things without trying to pry a rationale out of them IMO.

That is a reasonable opinion to have for sure, I think it just wasn't too obvious what you meant unfortunately!

A different way to ask that would be, if it's just a webview why not strip out RN instead of struggling with breaking change upgrades?

On top of that my question to the OP would be, why do they need to search around for libraries that are older than RN. In a team of 10 you can most likely create your own ones, or fork already made libraries and upgrade them to fit your purpose. One of the greatest things with RN so far for my team has been that we can actually write native components and bridge them. Yes RN is changing quite fast in general and most libraries out there might not fit your exact purpose, but I find it quite easy to integrate what I need in our app. (Team of 3, been on production for 8 months, its pretty alright so far)

The main problem we're having is that newer versions of RN use React 16. React 16 has breaking changes, particularly the changes to PropTypes and createClass, which some of our dependencies have already fixed but others haven't. This means to upgrade RN, we need to either submit fixes for all these libs or use a version of RN which still uses React 15, both of which have their own problems, especially since React 16 is still a release candidate and not a full release.

We're not creating our own libraries for a couple of reasons: firstly, this was supposed to be a quick project to see if an app is viable (but has now lasted long enough that we've run into this issue), and secondly we've already got forks of key libraries, which is taking more time away from implementing actual features since we now need to maintain them and pull in updates from the original repos.

Yes we should have kept dependencies up-to-date, but constant breaking changes are just taking too much time away from development time, so it's not a good fit for our project as it stands.

Imho, I think you got it wrong here.

I don't think you are supposed to make a production RN app out of the bat, by just using 3rd party dependencies.

RN isn't wordpress where someone can employ you and say I want this and that and then you go off install 50 plugins and thats it, your project is completed.

If you are installing a lot of RN 3rd party dependencies for a production environment then you are doing it wrong.

The best thing RN has to offer is being able to write React for parts and write Native code for heavy tasks.

You do need to go down and write your own components natively, sure if someone has done it before and its well maintained and you tested it and works for you then fine use that library, if not then don't install it but make your own.

For js components only components, then again if its very well maintained then use it, but nothing stops you for making the component that works for you.

RN is a bit less work than writing a Native app, but not too far apart. It's not meant to be for webviews and for people that just want to make a complex production app using 3rd party dependencies in very little time. Its meant for dev teams that JS is their main language but do have someone that has an understanding of native code.

Cool I'll just roll my own Facebook and Stripe integrations then

it depends, on my app I don't use Stripe so can't speak for its sdk, but I do use FB. At start I was using react-native-fbsdk but found that it was very limited and when I submitted a PR and went through the NDA procedure with facebook etc, then they delayed putting my PR which was fixing an issue out. I decided it would be easier for myself to bridge facebook's sdk, and so I did which was helpful as I've added quite more features to it which the react-native-fbsdk isn't providing.

That said it always depends on your usage and if it fits your purpose, but I wouldn't rely on 3rd party devs to solve my issues.

In-app payments and integration with Facebook login, Stripe, Apple subscriptions etc. It was in the first sentence ;)

When using RN with a web view you can easily communicate with RN using the postMessage API. From there, you can use RN for all of the native specific functionality. Most of the "native" code is shared between ios and android at that point. If you only need to support iOS then this is less valuable. This is the reason why things like Cordova exist. However, I find the communication between webviews and RN far more enjoyable to using Cordova + plugins.

Sounds like Ionic is a better solution for your app.

The team I'm a part of (~14 people) started building two new Android apps and transitioned our iOS apps to React Native a little over a year ago.

Overall, I would call it a great success; we have four apps (2 iOS and 2 Android) built from the same codebase, soon to be 5, and React Native has allowed us to be incredibly nimble in developing the framework and features for them.

Some things I do regret:

1. We didn't go all in on React Native, keeping large portions of code in native in case of performance or security needs.

This means that any given feature requires iOS, Android and React Native development. All of us are now fluent enough in each to do the work, but the context switching and debugging of actions moving across the bridge are a velocity killer.

2. We didn't realize that RN's cross-platform integrations testing story was so poor; we thought that we'd "just use Appium, it's perfect." Nope - design decisions made by the React Native team actually make Appium unusable for our Android apps.

This has forced a lot of churn in our testing strategy and we still have a lot of manual testing at this point. This is, IMO, the #1 thing that should be focused on either by Facebook or the React Native community.

same experience with testing on my side of the woods. but I'm not directly on that team...

I'm on the React Native team and focusing on testing. Can you elaborate on your experience with testing and what you'd like to see?

Absolutely not. We went all in on it. We even developed our own open source framework based on it called Gluestick. It's original purpose was to make it automatically isomporphic by running the same code in the browser as on the servers, using node.

We also built a component/style library that allows us to make responsive designs into web and mobile apps quickly and easily. Gluestick also allows easy creation of native apps (native/react native/web views) with 90+% code sharing. We also added a bunch of features (regex based routing, etc) to help with seo. We do all of this from our single framework based on react.

We had a lot of front end 'frameworks' in use and no consistency. Now we do. It's been a lot of work, but for us totally worth it.

We also have done a bunch of optimizations to make react fast, including how we handle webviews in a react native/native app. It's seamless. I'd like to link a video, but proprietary work that isn't done...blah blah blah, company secrets, blah blah blah. We will be releasing another blog post, detailing all the native enhancements soon.

what's the company name?

TrueCar is the company behind Gluestick.

TrueCar

A Google search for "Gluestick react" says the company is TrueCar.

How are you doing code sharing between web views and native? Is this an (open-source??) high-level component library that conditionally compiles to either <div>'s or <View>'s? Or did you actually find a way to render ReactDOM components within React Native inside some sort of controlled web view? The latter IMO would be a holy grail for companies trying to transition large ReactDOM codebases to native apps gradually.

So we've tried a lot of things to maximize code sharing. Our initial goal was to share non-visual code like reducers/action-creators/libs/utils etc… This was pretty interesting but it didn't give us the amount of sharing that we wanted. We were still building multiple versions of many things.

The next approach we started on was using https://github.com/necolas/react-native-web. This was very exciting and very fun to work with. However, we found it difficult to optimize the web experience. Most of our traffic is on the website so we are spending a lot of time optimizing the web experience. This might not line up with other's experience but we kind of came to the conclusion that react-native-web works great for apps where the native app is the primary driver and you want to offer a web experience as a secondary experience. This became more clear when we started trying to work with our SEO team. And again when we started trying to build responsive designs with react-native-web. Doable but we ended up spending a ton of time to make the web work the way we wanted to.

Eventually we decided to go a different direction. Most of our display logic is the same or very similar between the mobile web/ios/android with a few exceptions. We found that mixing ReactNative with the webview component gave us the ability to use webviews to share the majority of the code that can be shared. When we need more native functionality we communicate with postMessage and we have access to ReactNative. Once in ReactNative if we need to go down to iOS specific or Android specific code we have the ability to do that too. We found this to be much more powerful than Cordova and the user experience is honestly amazing. This is still a work in progress but we are excited about what we've seen so far.

Very cool. Are you driving the webview from React Native, or driving React Native from React/Redux code running in the webview? I imagine the latter would provide a seamless transition path for web-first shops, and you could probably do cool things with JSX syntax to make proxies for native components that feel like web components.

I think long term most of the things will be driven from the webview. Currently we are experimenting with taking existing native apps and replacing entire "tabs" with a RN/WebView experience. So it kind of feels like we are steering from the native/ ReactNative side kind of? Over time I think it will tip the other direction as we replace more and more of our native apps with RN/WebView.

One of the things we swap to react-native was to do a barcode scanner. With WebRTC support in iOS11 we may not even need to do that for long.

So React Native's packager actually has a really cool piece of functionality that conditionally loads modules with platform specific extensions where present: https://facebook.github.io/react-native/docs/platform-specif...

Currently I use this functionality exclusively for platform specific branching, without any platform-specific conditional logic in my codebase whatsoever. So to give a really trivial example, you can have something like this:

In App.js (shared as-is across platforms):

  import * as element from './element'
  
  export default () => (
    <element.View>
      <element.Text>
        Hello world!
      </element.Text>
    </element.View>
  )

In element.js (for web components):

  export const View = 'div'
  export const Text = 'span'

In element.android.js (for android specific components):

  import ReactNative from 'react-native'
  
  export const View = ReactNative.View
  export const Text = ReactNative.Text

This way once you build up a set of reusable lower-level cross platform components that share the same APIs, you can compose these components together without any platform specific branching, since the differences between platforms will be abstracted away by these lower level components, which will automatically get loaded by the React Native packager for the appropriate platform.

In practice, a lot of elements don't map one-to-one between web and React Native, and will require a lot more shimming to get at a reasonably close API (forms, inputs, and lists have been especially painful so far), but React's component model gives you all the tools you need to handle and smooth over those mismatches. This approach works great for utility functions that need to provide platform dependent functionality as well, so it's not just for elements.

Disclaimer: My project is still in a super early stage right now, so I'm not sure how well this approach can scale, but so far I'm enjoying the experience a lot more than I thought I would thanks to this approach, due to the lack of need for platform-specific branching logic in my code.

I've just recently started exploring React Native, so I'm curious if you have any pointers on how to implement responsive designs in a way that's compatible across web and native apps? Actually, I'd love to hear some suggestions on what to do w.r.t responsive design on React Native in general, since the solutions I've seen so far don't seem very well adopted and battle-tested. Once I settle on an approach, I should be able to just shim it out into a utility function or higher-order component like I'm doing for everything else.

I have been leading two React Native projects for most of 2017 with experience using the platform since early 2016. I would definitely recommend it today.

The two pain points have been 3rd party native modules and platform upgrades but both situations have improved greatly in the last year. Both the platform and the major 3rd party native modules have stabilized a lot, and platform upgrades are pretty easy via the react-native-git-upgrade tool.

I've used React Native with a number of languages: JavaScript, JavaScript + Flow, TypeScript and ClojureScript. All of the above, and soon, if not already, ReasonML, are viable language choices. My personal preference is TypeScript and ClojureScript.

The projects I have worked on professionally tend to be highly company branded with a common UI, and I am able to share ~100% of the JavaScript code-base between them (ignoring platform entry points).

An anecdote: recently one of the applications (React Native + TypeScript) was audited by a respected independent security consulting firm to rave reviews by the security team. On the spectrum of risk (Info, Low, Medium, High, Critical) the worst reported issue was a Medium that was due to the platform default ProGuard setting that disabled binary obfuscation for development; enabling required a 1 line config change.

This is a really solid answer. The point about ProGuard can especially bite you if you are adding React Native to an existing application.

Also, upgrading native dependencies in React Native is a really big pain point. The quality of Native modules also varies enormously.

An example react-native-camera:

https://github.com/lwansbrough/react-native-camera

Works well on iOS but has all sorts of performance problems on Android devices. Even newer ones.

One question I have is why did you prefer Typescript over flow? I have just started using the latter and I would be curious to hear your thoughts on the matter.

I'd also love to hear why ReasonML is good.

> I'd also love to hear why ReasonML is good.

Not the OP but I've spent the last couple weeks diving into ReasonML [1]. I'll give you the synopsis:

1. Type system is great. Way better than Flow/TypeScript in terms of both ergonomics (my opinion) and soundness

2. Comes out of the box ready to build React apps. Project init is very easy (there's reason-scripts for create-react-app and already boilerplate/generators for React Native apps as well).

2. Writing your own bindings for JavaScript code requires some elbow grease and semi-advanced knowledge of both OCaml and BuckleScript; harder than adding flow annotations or typescript definitions IMO. But once written, it's as easy as an `npm install` for everyone else.

3. Still lots of open questions and unfinished stories - especially around async programming. The built-in promise bindings kind of suck right now. I wrote bindings for Most.js [2] that I hope alleviates some of the pain for now until they get their head on straight.

I've spoken a lot with Cheng Lou and other people working on ReasonML in the discord channel, and they're just great - very helpful and friendly to a beginner like me. The community is small but very good. Feel free to hop in and ask questions and try it out!

[1] https://reasonml.github.io/

[2] https://github.com/Lokeh/bs-most

Great answer, thank you so much for writing it. Given all of the con's, would you advise building an app from scratch with ReasonML?

My main hesitation with stuff like this & Clojure is that the learning curve for React Native + the JS ecosystem is already pretty steep. Do I want to add another layer into the mix? For me personally, it would have to come with a big return on investment to justify the cost. I feel it would have to offer more than just an incremental improvement over flow/typescript.

An example: I'm considering synching some time into learning RxJS & ReactiveSwift. My reasoning is that Reactive programming helps eliminate certain types of bugs and makes it much easier to chain events together in a complex app.

I think if you (or your team) are not already comfortable with React and the JS ecosystem, ReasonML probably isn't for you right now. It's still a very leaky abstraction, with multiple layers. Often errors can occur that in order to decipher require knowledge of both Reason/OCaml, BuckleScript (the compiler), React and JavaScript. Adding React Native is another layer.

The ReasonML team are pretty amazing, though, and I do believe that they will rectify these problems quickly. A lot of effort is being put into documentation, error messages, tooling and design. The vision that they have for the project and the way they want people to be able to develop software is one that I admire and support. I'm putting in my own spare time to help them out, in the small ways I can.

Right now, though, I would honestly recommend ClojureScript before Reason. I do believe the maturity of that ecosystem really has hit the point where the gains (REPL, data-driven development, reagent + reframe + figwheel >>> react + redux + webpack, and CHANNELS!) outweigh the costs (unfamiliar language, unfamiliar ecosystem, additional layer of abstraction). I've built some internal tools using Electron + CLJS and it was great. Haven't messed around with using it and React Native yet but I know that the renatal [1] project has come a long way over a short period of time.

Your note about reactive programming is similar to the ReasonML vs CLJS vs JS conversation; reactive programming is great for certain things! But it comes at a cost; the abstraction makes certain problems harder and introduces it's own set of bugs (lifecycle bugs/crashes and memory leaks being the biggest one I've encountered with RxJS & RxJava), and can make your app code harder to reason about. Is it better than using callbacks or promises and imperative programming? Probably! Is it always? Nope! Are there other alternatives? Yes (CHANNELS!)

TL;DR: Not worth it right now; give it 6 months :D

[1] https://github.com/drapanjanas/re-natal

Great answer! Lots of food for thought. I'd love to hear more about any problems you have encountered with RxJS & RxJava.

> One question I have is why did you prefer Typescript over flow?

I don't want to start a holy war on this, as it's generally accepted that Flow's type system and inference is superior. I believe TypeScript is a generally better solution despite this, for other reasons. This is just the list I can come up with offhand:

Upsides for TypeScript:

* bigger community

* more definitions (This cannot be overstated; the gap is wide)

* great IDE tooling and support via language service

* great compiler

Downsides for Flow:

* less definitions

* smaller community

* .flowconfig is difficult to get right, and often requires hacks to pass type checking

* dodgy IDE support

* type discovery is more difficult

Thanks for this. I'm still relatively new to the Javascript world (mainly native developer) and I've only just started using flow.

Could you tell me a bit more about the following points:

* more definitions (This cannot be overstated; the gap is wide)

and

* great compiler

I'd love to hear more about this and or read some good articles comparing flow to typescript.

typescript wants to be in your project from day one

flow can be added to an existing project

i feel that almost everyone underestimates how important this is

This seems to be a common misconception. TypeScript can be added gradually as well with strict settings disabled, and supports JavaScript with a config setting. With Babel now supporting TypeScript[1], none of these arguments prevail.

[1]: https://www.npmjs.com/package/babel-preset-typescript

Especially those who have positive experience, could you share your experience with 3rd party libraries particularly in these particular areas:

  * Layout  
  * Infinite scrolling  
  * REST client  
  * Image handling (loading, displaying, caching) for popular formats  
  * Push notification (Apple's and Google's)  
  * Built-in (not server-side) SQL for storage  
  * Animation (like transitions, fading)  
  * [Added] In-app purchases

The reason I ask is, from my experience with non-native platforms, they look appealing and "production ready" ("Look how quick and concise you can make default UI using our platform!"), but once you go beyond default UI, things get ugly.

These days, those things I listed are arguably pretty standard for modern apps.

Layout: It's the main reason to go all in with RN. You're much faster building these with RN then using native stuff.

Infinite Scrolling: ListViews and RN are a thing. There's a new List Type since a few Versions - if you're following the book regarding DataStrucure everything should work.

REST Client: RN provides basic API so nearly everything which works in Browser works in RN too. I use Redux Sagas and fetch. Working great so far.

Image Handling: It's built on top of fresco and works great so far.

Push: Can't say mush about it, because i don't use it but should work ok.

In-App: There's a great Plugin.

Animation: Native Animations are around for some time. Should work ok, but depends what you're planning to do.

Basically it's extremely easy to go native if necessary. But at that point you need to implement it on every platform. Even though for usual use cases it shouldn't be necessary. You just need to keep Track of your renderings and make sure you use PureComponents at the right point, so there are no unnecessary rerenders congesting the bridge and slowing everything down. But if you do it right you will achieve performance and an feature level that is on par with every native development in less time. And with 95% Code Share.

Push works great!

From your list I have had no experience with in app purchases or client side sql.

I had a fair amount of trouble with push notifications on android (callbacks not being called etc), but those issues were eventually resolved (and had no issues with iOS).

Everything else on your list I found much simpler &a quicker than working with the native platforms

> I run a mobile team of ~30 folks.

That's a... big mobile team. RN's been a good move for our smaller 2-3 person teams (2-3 devs, plus part-time designer, QA, various other roles full or part time—call it 6 personnel) though not without trade-offs. Big wins:

1) JS devs can contribute quickly and comfortably.

2) Can still easily write native code if needed (win over other native-but-not-native frameworks)

3) If you decouple business logic (Redux, even) and, say, REST client code, that stuff's largely portable to an awful lot of platforms. RN's supported platforms (including kind-of supported, like FireTV and Apple TV), plus desktop (well, "desktop"—Electron) and (depending on what you're doing) web.

4) It actually does look pretty OK on both iOS and Android with few special considerations (conditionally rendered sections, different views) for each. This surprised the hell out of me.

5) Papers over a lot of stupid, badly-designed, and/or broken crap on Android, and does a decent job of it.

These add up to a ton of time saved, which manages to overcome:

1) Immature, kinda poorly managed ecosystem. If you stray from RN+Redux and one or two other core libs, Here Be Dragons. Like, good luck ever upgrading RN if you load up on dependencies like a typical JS project, if those dependencies touch RN itself at all. Part of this is just JS "culture", part of it's the relative youth of the project, and part of it's FB's choices.

2) It's Javascript. We've fixed this by using Typescript, which is great. Makes Redux actually manageable—way less bouncing around between files, bouncing out to documentation, more just writing code. Fewer red screens due to typos or related dumb mistakes.

I can see, though, how it'd be challenging to divvy up work efficiently on even a fairly large mobile app for 30 people (are they all devs?!) unless you've got a lot more going on than just layout/CRUD/client-server, in which case I'd think RN wouldn't change things much, as far as division of labor goes.

Can you speak more about how you've integrated Typescript? As far as I've seen it's not officially supported, so I am wary. I also use Expo

Facebook have decided they won't support it (Flow is their thing, so that makes sense) but Microsoft has stepped up with some pretty serious support, including good docs for the process of converting a new RN project to TypeScript:

https://github.com/Microsoft/TypeScript-React-Native-Starter

Not sure whether that'd play nicely with Expo without a bunch of extra work. It is quite a bit harder to convert an existing project than to start a new one with TypeScript.

This transformer: https://github.com/ds300/react-native-typescript-transformer worked perfectly for me so far. You don't have to change your code at all but just add a single file to your project and the packager will do all the rest for you.

My team has been working on our app for 1.5 years now and of all the technical choices we've made, React Native is probably our favorite. It's taken us through the prototyping stage and all the way to production without many issues. Granted, we're a very small engineering team of 3.

Pros

- We haven't done performance tuning and haven't had any user complaints about performance (it's a multi-channel chat app)

- Most of the time, changes "just work" on both platforms

- Javascript :D

- Development velocity is great, especially w/ UI changes

Cons

- Wish we had better text input control

- You still need someone who knows about native app development on each platform

- Upgrading versions can cause breaking issues (this has gotten better)

- Lesser used 3rd-party packages are often incomplete across platform, so a fair amount of patches

- Changes on one platform have the potential to break the other platform (so testing can require a lot of back and forth)

edit: formatting halp

I've tried making a chat application using Ionic and it's been tough.

The main issue is infinite scrolling by scrolling upward.

The user scrolls to the top, we make a note of the current top comment, load the next set of results, add them to the page.

At this point, the scrollbar is still at the top, so we need to manually scroll down to the previous top comment.

It can be a little jumpy. It certainly isn't smooth like WhatsApp etc.

Does RN have a list view that deals with this issue out of the box?

We're building a chat app in RN. Last I checked, the RN components do not support the functionality that you mention out of the box.

We are using a fork of GiftedChat which has generally been a positive but not stellar experience (https://github.com/FaridSafi/react-native-gifted-chat). I understand includes some fairly clever (perhaps hacky?) and extensive changes on top of RN's components to mimic the interactions we generally expect in a chat UI. It's been performant for the most part but is quite opinionated.

I would love to know if there's a better, more modular solution out there.

We're also using a fork of gifted chat; pretty much use it for the layout measuring and the inverted scroll view. Hoping to move to FlatList at some point!

I still cannot wrap my head around the fact that there are people willingly choosing Javascript over Swift.

A little off topic, but I really, really wish that people would stop trying to make JavaScript be the language of everything. I have zero interest in JavaScript, I don't believe it's a nice language to work in, and the ecosystem is insane. However, given the way things are going, and the way jobs are trending around me, it seems unavoidable.

I have zero interest in farming, so I am not a farmer.

I don't think it's likely there will ever be a true "one language to rule them all" in the foreseeable future. Gripe as you may about a tool you don't use, it doesn't sound like you're in a field where knowing JS is mandatory knowledge.

Mobile development. And as I said, it's getting there. JS is being shoehorned in everywhere, and most of the job ads I'm seeing are requesting web tech in mobile developer ads.

There should always be a job available for you that doesn't require writing JavasScript. However, as a counterpoint, I have been writing ruby/javascript for a while now and the last couple of years I agree the JavaScript has taken over my career. I have 0 complaints, I love modern javascript, the ecosystem, the engines, debug tools and everything between. You don't have to like it but lots of people do and lots of high quality software is being made with JavaScript.

Agreed with your counterpoint. I used to try to avoid JavaScript, nowadays I wish I could use it for everything (C++, C#, and some others are still unavoidable for some of my work). Modern JavaScript is my favorite programming language at this time.

For the native platform I feel that "make JavaScript be the language of everything" was basically forced on people if they wanted something to work on iOS because it's one of the only languages that are allowed on the platform. It is especially useful because you can do minor updates to your app to support bugfixes and faster iteration times.

iOS doesn’t restrict the languages on its platform. Restrictions only come into play if you want to download code from the internet and run it.

Of all the niches one might worry JS will/has claimed an unavoidable status.... native mobile app development doesn't seem like it should be high on the list.

Any language with as critical a mass among devs will probably see tools to help people leverage it across different environments, so JS will likely continue to move into and live in all sorts of niches. But it's quite avoidable on the server, desktop, native mobile, embedded, and it's even becoming partially avoidable on the web.

You're safe enough that you don't have to make everyone else dislike it in order to not have to touch it.

You should give it another try. The modern ecosystem / DX environment is really fast and slick. I've known a number of native devs from different languages who now love the lang and what it has to offer. But you've gotta go into it with an open mind :)

Modern JS is not that different from old JS. A couple more keywords and some syntax sugar. No proper integers yet.

Builds are very complicated. It's not as simple as 'JS is your whole app'. The package manager is getting better at injecting native code (react-native link) but has a long way to go.

I spent a lot of time debugging RN. The instant reload feature comes with hangups. Tracebacks don't always appear.

Navigation isn't cross-platform.

Interacting with native APIs is nightmarish. JS wasn't built for java interop.

No, I don't regret it. We picked it for our startup as we wanted a cross platform solution, that genuinely felt native (without the huge effort it takes to make a webapp feel that smooth), and that still gave us a chance to easily native code for certain features. Big wins:

- With a little effort, it genuinely feels native.

- The talent pool is much larger. We didn't hire React Native folk, just good JS people who picked it up quickly.

- Blending native code with JavaScript is easy.

- There are methods to perform app updates without going through the app store release processes of either platform (and waiting for end users to actually download the update).

- It moves quickly, so bugs are squashed pretty quickly, and features arrive at a fast clip.

There have been challenges:

- It moves quickly. Backwards compatibility is doesn't seem to be high on the maintainers priority list, so almost every update will break _something_. We instituted policies of never falling far behind the public release (to avoid needing huge changes at once), and using very few external components (which are often not kept up-to-date with RN).

- If your use cases are outside of the maintainers, there will be problems. The release process seems to be "Does it work for the contributors projects? Ship it". Things like Pod based builds broke for months because they just weren't tested.

- The JavaScript ecosystem is still insane. Our project has ended up with one of the most complex build processes I've worked with (and I've worked with autotools).

My key advice would be:

- Stick with their release cycle, and follow their processes. Don't colour outside the lines, or you will have pain.

- Don't include third party modules unless you have _no other choice_.

- Test on both iOS and Android regularly (i.e. continuously). Things that work well on one platform may be broken on the other.

Based on our outcomes, present me would happily tell past me I'm making a good call, as I'm confident we'd otherwise never have shipped two native-feel applications with 5 developers.

> - The JavaScript ecosystem is still insane. Our project has ended up with one of the most complex build processes I've worked with (and I've worked with autotools).

God is that true. The JS ecosystem as a whole is actually, no BS, crazy, and their build jenga-tower especially is insane.

With RN, though, we've only really had problems with it when using Expo. Taking that out of our stack pretty much solved our periodic whole-day-wasting build problems, and excising it and other tightly-coupled libs freed us to upgrade RN from time to time, which is nice. A++++, would aggressively remove RN-specific 3rd party libs again.

I don't use react native for work, just for my own projects, but what you said about expo is resonating with me. I thought it would be a clear winner but it's much slower to do anything with it, the app is constantly crashing, etc. Feels much less productive.

how long ago was this? our experience with expo has been pretty great so far.

At Artsy, my team of long-time native developers, started using React Native on valentine’s day 2016 in our pre-existing iOS app. Overall it has been a net-positive for us. In short, the developer experience and ability to be productive is much better, we now are able to leverage the product engineering skills from devs that would previously only work on web projects, and our initial tests in porting our React Native iOS code to Android are looking promising.

I think there’s no binary answer to whether or not React Native is a viable option. I can definitely imagine a bunch of situations where that would not be the case, but in our case the app is largely just a collection of views that show remote JSON data. Some small animations are done using the React Native animations API, but e.g. our navigation completely relies on native APIs and also has custom native transitions.

In short, I think that the companies that will succeed with RN are those that have native experience and a can-do-self attitude, both to ensure proper platform UX and deal with lower-level details such as RN bugs and limitations that would prohibit the product design from being possible to implement at all (for instance, in our case nested scrollviews); or those that are willing to sacrifice on UX and product design. (Not making any judgements here btw.)

We’ve written a bunch about our experiences https://artsy.github.io/series/react-native-at-artsy/ and I recently spoke about our specific case of integrating RN into our existing native app at React Native EU https://github.com/alloy/react-native-eu.

We developed a card game on React Native almost a year back. We were initially developing the game using cordova but were taken by the performance issues. We switched on to React Native and were very much impressed with the performance. One year since we released the game, we are working on the next version and we have decided to stick with React Native. The development is much faster and easier. We very much liked the native animation support that has since been available with React Native. The only problem we faced was with admob integration. No regrets so far.

iOS app: https://itunes.apple.com/us/app/marriage-card-game/id1161818...

Android app: https://play.google.com/store/apps/details?id=com.bhoos.marr...

Note: It was our very first attempt on mobile gaming. The rules for the games are available here if anybody is interested to learn https://www.pagat.com/rummy/marriage.html The game is meant for players who already know the game rules.

I'm a react native consultant, so I've seen several different projects (of all different sizes). Overall, I've been super happy with React Native, and would easily recommend it to anyone looking to build an Android and iOS version of the same app.

There have been a lot of changes since 2015 - and the overall experience has gotten quite a bit better. There are many more modules available for both platforms (in 2015 you probably found a lot of modules only supported iOS and not Android) - and in general the whole ecosystem is more stable.

That said: not everything is perfect. React Native moves quickly, so there are sometimes frustrating bugs (especially in new releases) that can take a bit of time to resolve. Also, it's not a great fit for every type of app. 3D games are an obvious example of when you'd want to go native (or use unity).

However, after having done native iOS development and react native development, I can say that react native is still faster (development speed). In practice I find that I can reuse 95% of the code between iOS and Android, so it's been a great win for the teams I've been on.

In 2015 I began using React Native for a client because I was led to believe that it would be a nice way to bring their web app to iOS and Android. After months of alternating happiness and frustration, we cancelled the project due to many horrible problems involving crashes, lagginess, and poor behavior. I definitely regret that. Probably the ecosystem is more mature now, but back then I found its advertising and hype to really stretch its actual quality.

1.50 years since app development started 0.75 years since app was released

stuck with old version of rn, upgrades break app

new team members onboarding takes forever, environment is extremely tenuous

would i use again? no

>stuck with old version of rn, upgrades break app

so you have problems you need to sort out with your own codebase. this is not unusual when using any framework. willing to bet this also stems from poor code practices due to the lack of react 'standards' 1.5 years ago / lack of es6+ code

>new team members onboarding takes forever, environment is extremely tenuous

in terms of onbaording, this is something that can always be improved on. better docs. getting started docs. if you've done it once and realized what new hires are struggling with you can reduce that in the future. the environment isn't really that bad, if you had someone who understands javascript ecosystem then they really only need to know how to bundle the packages through the device specific IDE.

just seems like you've got a bad taste in your mouth for a standard everyone else seems to have figured out.

I had similar issues taking over a project using an older version of React Native. Upgrading is incredibly painful since there's no stable version and libraries don't always update to match. The current release of React Native uses a release candidate version of React, which many of our dependencies haven't yet updated to match, so we're either stuck with an old version with poor compatibility or have to fix dozens of third-party libraries to try to catch up - both are not ideal, and both are caused by constant breaking change releases.

We switched to React Native for Bitesnap after developing the initial prototype using swift. We've been using it for almost a year now and have no regrets. It allowed us to ship our product to a much larger audience without slowing us down.

Users seem pretty happy with the product as well, we've had no complaints about performance aside from a barcode scanning issue on older android devices.

https://itunes.apple.com/us/app/bitesnap-photo-food-journal/...

https://play.google.com/store/apps/details?id=ai.bite.biteap...

Great product! What navigation are you using?

Nice! I tapped that version number a few times and got the dev menu... gold!!!

Does seem like non native, but performs well ;)

Our team and clients are pretty happy with the decision to adopt React Native.

I'm part of a JavaScript-only consultancy, we've now built RN apps for three companies in the Fortune 500: a retail, healthcare, and data storage company. Performance-wise, all three applications performed to our clients' standards. However, we also encountered issues concerning debugging, new releases, and other limitations.

That being said, the biggest advantage the RN has (which is why our clients decided to take the plunge) is that it significantly decreases the development time when you want to scale for various platforms. At the end of the day - your decision should be based on you and your team's willingness to play with JavaScript.

This is such a great concept for a thread - the replies are fascinating. I love the focus on "larger teams who adopted it at least a year ago". Thanks for posing such an insightful question!

I'm a native iOS developer who does a lot of React Native consulting. Earlier in the year I gave a talk on the pro's and cons of React Native which you can watch here:

https://www.youtube.com/watch?v=cZ4zQWgajBg&t=746s

The main reasons I got into React Native was a combination of frustration with the state of Swift last WWDC and an opportunity to try it out with a client who just had a React Web team.

I don't regret the decision at all. If you are thinking about using React Native in a project here are some things to consider:

Maybe we should use React Native:

- We know JS / React

- We have lots of web developers but few mobile

- Our design is brand-focused

- We're willing to invest in RN

- We want to get into OSS

- We want OTA code updates

Or maybe we shouldn't:

- We don't know JS / React

- We already have an iOS team and an Android team

- Our designs are heavily platform-specific

- We don't have the time or money for an RN team / OSS

Pros:

- Cross-platform

- Performant, native feel (with some effort)

- Great developer experience

- Push updates over-the-air

- Strong community

- Backed by Facebook

Cons:

- Early

- Unstable (bugs, APIs)

- Ecosystem not fully developed

- Polished apps are high effort

- You may need native code (so JS + Obj-C + Java)

If you are a fully native shop, with no JS dev's that use React, it doesn't make all that much sense to rewrite your app using React Native.

If you have no native team, are familiar with React, then React Native makes a lot of sense.

If you are are a company with native apps and a web team that knows React then using React Native inside your existing app for growth, etc, makes a lot of sense.

Going all in on React Native is a big investment and I wouldn't recommend it for many use cases (multimedia, etc). Right now it definitely has some rough edges (navigation, upgrading versions, etc) but it can dramatically increase the productivity of your front end teams.

We're using it in production apps since 18 months, and even if it still sometimes feel like it's a 'beta' (interfaces change, navigation keeps changing too) it has become more reliable. The real struggle has more to do with XCode and native apps in general (Expo definitely fits in the prototype thing in my opinion).

The good (great) part comes from the fact we're a small team (4 devs) and and thus we can do / test / debug things only once for our different platforms (we're using Electron, with all its caveats too).

Apollo and GraphQL availability is also a great plus.

There are performance issues, and data transfer from RN to Native code and the other way is complicated (and different on each platform).

With 30 persons working on an App you've got more than enough to have 1 version for each platform though.

Haven't used it. Was considering it till I read the license rubbish. I use ionic and I'm quite happy with it. It's not Native, but for 80% of the apps out there it's create and there are lots of native Cordova plugins and you can write your own if you need missing native capabilities.

I'd recommend reading this article about the licensing language that's being disputed now: https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revok...

The author is the same person that has an article on the front page currently arguing that the license for Graph QL DOES have issues (and is following through with Facebook through Github Issues to resolve them), so I think this position is really worth considering.

Just delete the PATENTS file. There is nothing that says you can't do that, and you then have a plain BSD licensed project.

The downvotes suggest no one is taking this seriously, which is good. Because as soon as the first React patent issues such a project would be an immediate willful patent infringer. At least in the US or anywhere else software patents are recognized and have been filed.

Same here. We were seriously considering it, until the licensing issue.

In fact, we continue to use Reactjs - because it is something that we can rip out and replace if push comes to shove. But a React Native app once released will live in the wild - which means the patent exposure cannot be mitigated easily.

I don't regret adopting React Native for a big project, since I think we've been able to prototype and iterate much more quickly than we would if writing in Swift or Java, and it's enabled us to get webdevs up to speed on mobile without having to teach them entirely new programming paradigms and languages.

But... RN still has huge blocking bugs like this one: https://github.com/facebook/react-native/issues/14209 that seem to pop up at random times, and not always for the same developers. I thought yarn would solve some of these issues, but they still kill our dev team and halt all work every once in a while. And it's annoying as heck.

React Native is painful to upgrade, it usually takes a developer day to upgrade to the latest version but I'm used to this reality at this point, XCode is not the most developer friendly platform to build on. Integrating GraphQL (game-changer and enjoyable way to do mobile api calls), into an existing react native app was a smooth process, GraphQL has a learning curve but the GraphQL, React Native, Node stack seems like a viable option, there are pros and cons to every stack. The React Native ecosystem could save you time, companies like Wix and Microsoft are contributing good software.

OP, I would like to learn more about your story as well. How did you arrive at your decision that RN is not a good fit?

I really don't want to rail on RN. My experience is 2 years old at this point, and even then it was the internal decision we made based on our use-cases and needs. Yours are likely different and maybe RN would be a silver bullet for you.

We tried it for a few months in earnest.

There were a lot of bugs or incomplete APIs for our use-cases. Off the top of my head, if I remember correctly - intricacies and bugs around input handling, the JS navigator implementation didn't properly support swipe back/forward and we could crash it with a couple well timed taps, landscape mode was non-existent, same with master/detail view. We were able to make a few screens in a few days, but polishing them to a shippable standard took exponentially longer or was relatively impossible without doing more native work than what would have been necessary to build it natively from scratch. There were also serious perf issues, like around list views.

Our team members submitted a few PRs to the github repo and they took months to get merged, if at all. Back then it felt like nobody was really at the helm. I suspect this has gotten better since then.

Was RN available for Android when you were testing it?

RN for android was publicly released during the time we were experimenting.

We are a team of 4 developers who work on iOS and Android app for Copart. iOS - https://itunes.apple.com/us/app/copart-app-online-salvage-ca... Android - https://play.google.com/store/apps/details?id=com.copart.mem...

RN has worked really well for in delivering functionalities to both the platforms and even in maintaining a single code and a small team. Our app is a real-time high-intensity auction platform which uses web-sockets to stream data. When we were using native languages to develop app it was very tough to maintain the same feature for both platforms. RN has helped us in tackling this really well. I understand there are some drawbacks of RN but with proper optimization of native code, we can achieve the results really well. I still believe that RN Android is lagging behind RN iOS but it still does a great job compared to other Cross-platform tech stacks.

I've had a React Native based fitness tracking app live in both stores for over a year now. If I had to do it over again, I would still choose React Native. It's made the whole cross-platform development process incredibly simple, and it provides excellent tooling out of the box.

Some dependencies on third party libraries made upgrades difficult, but the core library added the functionality I needed eventually, so I no longer run into those issues. Overall it's been pleasant to work with.

iOS app: https://itunes.apple.com/us/app/plansible-weight-lifting-jou...

Android app: https://play.google.com/store/apps/details?id=com.plansible_...

I'd love to know this as well, as we're currently evaluating making the leap between RN and Xamarin for our startup.

(ideal world, I favor just using the native stacks for iOS and Android but we are short staffed)

Consider Flutter (https://flutter.io/) as well. The advantage over RN in terms of performances is interesting.

Beware though: "Note: Flutter is an alpha, open-source project."

It's missing some polish (notably, check accessibility) https://flutter.io/widgets/accessibility/ "Make your app accessible. (This is a work-in-progress.)"

I haven't dug into how much is done though. It's alpha after all, but I'd be wary of choosing it for a production project at the moment.

I remember putting the Flutter demo with a simple counter on a no-name Android device and having the Flutter app completely chug.

The hardware had a really wimpy SoC, but a native app would never chug for something as simple as pressing a button to change a number.

It made suspect that while in phones with strong GPUs the acceleration makes things buttery smooth, it doesn't graciously scale to poor GPUs (but someone please do correct me if it might have been something else)

It got me worried about shipping an app and finding out it doesn't run on low end hardware even though it doesn't do anything that would be demanding on native

Do you happen to remember what device that was? On my crappiest Android device (Moto E LTE 2015), the Flutter Gallery app runs fairly smooth.

It's not a "normal" device that I could really name, but it's internals are shared with several brands of no name Android tablets you'd find at Walmart, for example

I've never used React Native, but I've had negative experiences with Xamarin at my current company. It's buggy as heck and the development experience isn't great.

Most teams are committing to native development after trying Xamarin.

I found Xamarin development to be about 30% faster on average, than native. But, even with Xamarin Forms, one often needs to customize the UI and code to target android or iOS specific features. And that is when it's a pita, b/c now you need to know native and the Xamarin platform. And it's all on you to figure out.. b/c the community and resources available are much smaller than the native community.

Even with the 30% development savings, I prefer native. It's just less hassle and more enjoyable.

OP, I’m curious when you tried it in 2015? Of course, a lot has changed since then, but Jan 2015 vs Dec 2015 are worlds apart as far as React Native goes.

If any folks on this thread have especially enjoyed working with React Native, I'm hiring for a role completely focused on our RN app: https://angel.co/goaero/jobs/280128-react-native-lead

You might be interested in this: https://blog.discordapp.com/using-react-native-one-year-late...

We use it over at Discord.

JavaScript is a terrible language. Please don’t ruin your app by having it written in JS.

Lots of things have changed since es5. It's actually more than suitable for front end. I am certain that by using react/redux and es2017 you could cut pretty much any native codebase in half and still have it appear and behave cleaner in the end. This is why they are porting these principles to native, for instance in Kotlins Anko, Litho, ComponentKit, ReactXP, or react-native itself.

JS + npm/node also has more modules and components to choose from than any other repository combined. The crippling factor was always the browser, now that that's out of the way, it can build applications native counterparts could not get at given the same amount of money, time and workforce.

Actually looking at examples of the apps shown here JS does not matter. They still look like webviews. Cross-platfrom is really a misnomer, it should be no-platform. Yeah, it kind of runs on both, and alien on both too.

Having developed native android and ios apps in the past the greatest benefit i saw immediately using react native was the use of flexbox for layouts, it's so much simpler compared to ios' autolayout and android's xml layout.

Why was it not a good fit for you? 30 devs seems like plenty to build native?

Nice question by OP which piqued my interest. Unfortunate to see such polarized opinions. Based on the responses so far, I'm still up on the air on whether RN is a good choice or not. :(

Can you explain the comment about a "larger team"? What issues do you see being any different for RN vs any other mobile tech regarding team size?

the important question, will you regret you used flutter tomorrow?

Used it for 1.5 years now. Love it.

Reply on news.ycombinator.com