Live data from Hacker News

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

news.ycombinator.com

111–120 of 149 posts

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

#111
post #99

Earlier quoted context omitted.

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

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'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!

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

#113
post #104
post #90

Earlier quoted context omitted.

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…

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

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

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

#114
post #107

Earlier quoted context omitted.

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…

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.

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

#115
post #76

Earlier quoted context omitted.

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

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.

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

#116
post #80
post #44

Earlier quoted context omitted.

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

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

#117

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

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.

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

#118
post #56

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

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 's or '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 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 () => (
    
      
        Hello world!
      
    
  )
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.

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

#119
post #41

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

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.

One control per screen

It's actually quite easy

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

#120
post #79
post #70

Earlier quoted context omitted.

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

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

Post reply on HN