Live data from Hacker News

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

news.ycombinator.com

61–70 of 149 posts

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

#61
post #41

Earlier quoted context omitted.

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/

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.

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

#62
post #41

Earlier quoted context omitted.

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/

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

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

#63
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.

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

#64
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.

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

#65
post #42

Earlier quoted context omitted.

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 A…

> 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…

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.

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

#66

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…

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.

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

#67
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.

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

#68
post #36

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 pi…

> - 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 perio…

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.

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

#69

Earlier quoted context omitted.

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

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.

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

#70
post #42
post #32

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 re…

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 A…

> 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

Post reply on HN