Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Native for Android

code.facebook.com

Post reply on HN
Print view View original

151–160 of 248 posts

Re: React Native for Android

#151

Post by amelius »

z3ugma wrote: post #148
amelius wrote: post #109

I can't believe people (especially computer scientists) are buying into the React craze. They took an O(1) algorithm, and turned it into an O(N) heuristic, and popularized it by portraying it first as an O(N^3) problem [1] [1] https://facebook.github.io/react/docs/reconciliation.html

Can you explain the assertion that DOM rendering is O(1)?

Of course. For example, suppose that there is a button in your UI that changes color whenever you click on it. Changing the color of that button in response to a click can be done in a simple Javascript function that takes O(1) time. However, doing it the React way, all buttons on the screen have to be traversed, O(N), and diff/patched into a new DOM, which is heuristically O(1). However O(N+1) = O(N), so React takes O(N) time for something that can be done in O(1) time.

Now, while React may still be fast enough in practice, I can't understand why computer scientists find the situation acceptable. It feels like using bubble sort instead of quicksort or mergesort because you expect your problem space to never grow.

Re: React Native for Android

#152

Post by lewisl9029 »

mixmastamyk wrote: post #133
lewisl9029 wrote: post #117

Earlier quoted context omitted.

I was mostly referring to development paradigms and methodology in my original post, but in terms of tooling, I personally haven't see any tooling on the native side even approach the increased productivity provided by the instantaneous feedback loops that countless hot-reload implementations can offer for the web. https://github.com/gaearon/babel-plugin-react-transform/ http://gaearon.github.io/react-hot-loader/ htt…

I've done similar with inotify (dnotify before that) and Python now for over a decade, and it is an interface than can automate anything. I use it with doc generators also. I believe I used something similar called fam in the 90's but that may have only been on SGI.

Filesystem watching is only part of the equation though. Live reload has been available for the web and various other platforms for a long time, but the traditional approach to live reloading does not preserve application state.

These new hot reload implementation allows your app to be reloaded with your new changes without affecting the state of the application, and is not practical unless your application has been developed with a focus on functional techniques and careful management of application state.

This probably doesn't sound like a significant difference, but in practice, it is a huge boost to productivity, especially in a non-trivial app where reloading the entire app and then reproducing the app state manually with every file change can become quite tedious.

Re: React Native for Android

#153

Post by rhodysurf »

oblio wrote: post #73

A sort of strange question. Has anyone tried Qt as a cross platform toolkit for mobile? What was your experience with it? I ask this because I'm thinking about creating a cross platform app, desktop + mobile and I'm wondering which would be the best way forward. Qt? ReactJS + web browser + React Native? Something else?

Qt is less than optimal on mobile. It uses QML mostly and the widgets do not look native to iOS or Android out of the box.

I write mobile apps natively in my spare time, but use Qt at work I wish that Qt was more solid for this.

Re: React Native for Android

#154

Post by Callmenorm »

amelius wrote: post #151
z3ugma wrote: post #148

Earlier quoted context omitted.

Can you explain the assertion that DOM rendering is O(1)?

Of course. For example, suppose that there is a button in your UI that changes color whenever you click on it. Changing the color of that button in response to a click can be done in a simple Javascript function that takes O(1) time. However, doing it the React way, all buttons on the screen have to be traversed, O(N), and diff/patched into a new DOM, which is heuristically O(1). However O(N+1) = O(N), so React takes…

I think its because there are tradeoffs for managing the complexity yourself. Using this same argument most abstractions which have performance overhead should be unacceptable. There are tradeoffs everywhere and I guess this is one that a lot of people have accepted.

Re: React Native for Android

#155

Post by Kwastie »

amelius wrote: post #109

I can't believe people (especially computer scientists) are buying into the React craze. They took an O(1) algorithm, and turned it into an O(N) heuristic, and popularized it by portraying it first as an O(N^3) problem [1] [1] https://facebook.github.io/react/docs/reconciliation.html

To be fair, nobody will choose React because of the virtual dom. The virutal dom is just a tool to make React perform faster.

You should choose React because it makes building reusable (web)components for applications much easier.

Re: React Native for Android

#156

Post by muzmath »

aikah wrote: post #129
elietoubi wrote: post #3

That could really be a game changer in mobile development.

Abstractions like these always target the least common denominator. But React has the "component" advantage so i'm not dismissing its usefulness. it's good for a category of projects.

Do you consider a facebook production app a least common denominator?

Re: React Native for Android

#157

Post by mkonicek »

vijayr wrote: post #94

Noob question - is it possible to learn React and build mobile apps for someone who is a web developer and has no knowledge/experience in mobile development?

It is possible to build an app purely in JS. The Facebook Ads Manager was built by a team where some people had mobile development experience and several people only had JS experience.

Re: React Native for Android

#158

Post by lewisl9029 »

mirkoadari wrote: post #143
lewisl9029 wrote: post #117

Earlier quoted context omitted.

I was mostly referring to development paradigms and methodology in my original post, but in terms of tooling, I personally haven't see any tooling on the native side even approach the increased productivity provided by the instantaneous feedback loops that countless hot-reload implementations can offer for the web. https://github.com/gaearon/babel-plugin-react-transform/ http://gaearon.github.io/react-hot-loader/ htt…

Android has JRebel for Android for hot reloads... https://zeroturnaround.com/software/jrebel-for-android/

I was not aware of this, so thanks for bringing it up.

It's a pretty amazing technical feat that this works at all, but I have a hard time imagining this would work well in practice for changes to anything other than maybe method bodies and templates though. Java's style of object orientation generally means there's plenty of tight-coupling between application state and operations on the application state, which would probably make life very difficult for any hot-reload implementation.

But regardless, it does exist and apparently works well for a lot of people. It looks like I was just ignorant when it comes to native tooling.

Re: React Native for Android

#159

Post by GrinningFool »

o_____________o wrote: post #58
nabaraz wrote: post #51

Earlier quoted context omitted.

I would love to see some discussion around this as well. I have been playing with Apache Corodova and Windows 10 SDK lately and they look very promising. Being a web developer, I found them to be easy to get started. Are there complex apps built using phonegap/swift/cordova? What are the limitations? I know Facebook tried with a 'web app' approach and reverted back to native solution. But that was years ago.

Using Cordova, you will always be behind any and all Mobile Safari WebKit et al bugs. This not a big deal when pushing layout around a webpage, but it can be crippling for app development as the app grows in complexity and you crave native-quality interactions. Mobile Safari's Webkit implementation has a staggering list of severe bugs. Developing under it can become a nightmare of hacks and backpedaling. Been working…

    > This not a big deal when pushing layout around a webpage, 
    > but it can be crippling for app development as the app 
    > grows in complexity and you crave native-quality 
    > interactions
Even on the fastest phones, web-based (including wrapped web components) simply don't offer the native experience. They come close, but there's always a slight but perceptible performance difference; and often a visual difference depending on what you're using.

I realize people really like the theoretical write-once behavior that you get for simple apps when using a javascript platform, but I've been waiting for years for web-based interactions to provide native quality - and I begin to suspect we'll never get there.

If you want native-quality interactions, the only solution is a native application and not common tooling via a javascript layer that runs atop the already not-as-performant-for-UI browser level. This makes your life harder as a developer, but gives your users the best possible experience for their platform.

Alternatively, if you're willing to give your users a good-but-less-than-native-quality experience, that's the niche filled by those tools.

Re: React Native for Android

#160

Post by mkonicek »

s73v3r wrote: post #69

The article also seems to indicate that their repository strategy is not properly set up for something like this. Most people, I think, would initially set up a separate repository for iOS and for Android, given that they are different codebases, and you wouldn't want commit history pollution. But if you're planning on reusing a lot, like in this project, it might make sense to have them both in one repo. Or have a t…

We've had two separate repos for iOS and Android and we're merging to a common one. It's much easier to manage, especially when sharing C++ and now React Native JS code between iOS and Android apps (e.g. the Ads Manager).
Post reply on HN