5 ms·

React Native doesn't deliver a poor user experience though. It's not the right choice for every project, but in most cases users won't be able to discern betwee

by kcole16 11y ago

React Native doesn't deliver a poor user experience though. It's not the right choice for every project, but in most cases users won't be able to discern between RN and native.

Ambroos 11y ago
On iOS maybe, but not on Android. You have to reimplement a lot of the things you get for free when developing native apps yourself. Most animations etc, you all have to add it yourself. Problem with that is that the React Native team has some decent iOS stuff, but for Android it's all sorely lacking. Besides Facebook's Ad Manager (which barely cuts it) I haven't seen any React Native app on Android that didn't feel horrible (and not like an Android app).
briandear 11y ago
Does the Facebook app use React "Native'? Because that app is a horrible power hog and vastly glitchy and buggy. That is a poor user experience compared to what a well written native iOS app could deliver. Users might not know its a poor experience because that can't compare to how fast and responsive the app would be if it were actually written in Swift. There are people in this world that think Olive Garden is great Italian food. There are people in this world that think React "Native' is a good user experience. Why does Facebook absolutely insist on avoiding writing actual native apps? As in Swift for example. It seems like they are almost allergic to actual native and instead focus on this inferior cross platform stuff. In 'most cases' users won't know the difference? sure they will; they'll notice that the app they're using sucks more than other apps on their phone. They'll tolerate the glichiness, the occasional blank data screen during a load because they care about the content more than the terrible experience. All because a developer or the CTO somehow thinks "it works well enough" is the same as "let's really give our users the best possible experience." I am amazed that Facebook has thousands of employees but can't be bothered to write a single line of code in Swift. They've been insisting on this stubborn course of action since the beginning of their mobile experience. Does Zuckerberg just hate Obj C or Swift? Why are they making the mobile experience into the lowest common denominator? Why does their Facebook app feel like some cheap PhoneGap experiment? My Facebook app on iOS performs exactly the same as it does on a years-old Android phone.. And that's ridiculous. I have superior hardware and yet I get to run an inferior app because JavaScript? It's like socialism for apps: make everyone equally miserable. The simple fact is this: I hate cross platform systems because they end up averaging the quantity of the mobile experience with capabilities being reduced to support the lowest common denominator. If I want my apps to run as terrible as many do on Android, I will use an Android. It's lazy development. It's a means for the JavaScript crowd to avoid leaning Swift (or Java) so they can provide middling to bad mobile apps rather than actually building the absolute highest quality product they could build. Even Facebook does it! I feel like the React Native ecosystem is doing more to reduce the quality of the mobile app experience than anything else. Apps are being turned into these average pieces of crap with only the UI being slightly different. Does anyone have any performance benchmarks on a React "Native" compared to Swift? Any data at all? Or are we just so excited to write apps in React that we fail to care? If we care about 'cross platform' development -- we can already do that; it's called 'the web.' Let stop foisting inferior mobile apps on people just because we can.
- pcwalton 11y ago
  JavaScript is faster in most cases than Objective-C. (I'm not going to dispute that cross-platform toolkits can have less native fidelity than compared to coding to the native toolkit can. I just don't like the Objective-C vs. JavaScript performance myth.)
  - robenkleene 11y ago
    Huh? What's the Objective-C vs. JavaScript performance myth? Here's a link showing Objective-C beating JavaScript handily: https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976#.nkhch22xj https://medium.com/@harrycheung/mobile-app-performance-redux... But is this even a debate? Wouldn't you expect a compiled, manual memory managed, language to be faster than an interpreted language with garbage collection?
    - randommodnar 11y ago
      Actually JavaScript is compiled JIT by most engines these days. While it's not the fastest, it certainly can be quite fast.
      - robenkleene 11y ago
        I see, good point, but then I'd expect the cost of JIT compilation would still have a performance cost? As opposed to Objective-C being compiled before distribution to the client?
        pcwalton 11y ago
        JIT compilation cost is minimal in practice due to tiered JITs.
    - pcwalton 11y ago
      That's an interesting benchmark, and I'd need to dive into the details to see what is going on. Perhaps there is some sort of JIT slow path. I would not expect method-heavy Objective-C to beat JavaScript. In general: > But is this even a debate? Wouldn't you expect a compiled, manual memory managed, language to be faster than an interpreted language with garbage collection? Objective-C is not compiled in terms of method dispatch, nor it is manually memory managed. Instead, all method dispatch happens through essentially interned string lookup at runtime, backed by a cache. Objective-C also has a slow garbage collector--atomic reference counting for all objects. (Hans Boehm has some well-known numbers showing how slow this is compared to any tracing GC, much less a good generational tracing GC like all non-Safari browsers have.) The method lookup issue has massive consequences for optimization. Because JavaScript has a JIT, polymorphic inline caching is feasible, whereas in Objective-C it is not. It's been well known in Smalltalk research since the '80s that inline caching is essentially the only way to make dynamic method lookup acceptably fast. Moreover, JavaScript has the advantage of speculative optimization: when a particular method target has been observed, the JIT can perform speculative inlining and recompile the function. Inlining is key to all sorts of optimizations, because it converts intraprocedural optimizations to interprocedural optimizations. It can easily make 2x-10x of a difference or more in performance. This route is completely closed off to Objective-C (unless the programmer manually does imp caching or whatnot), because the compiler cannot see through method lookups. Apple engineers know this, which is why Swift backed off to a more C++-like model for vtable dispatch and has aggressive devirtualization optimizations built on top of this model implemented in swiftc. This effort effectively makes iOS's native language catch up to what JavaScript JITs can already do through speculation.

by kcole16 11y ago

React Native doesn't deliver a poor user experience though. It's not the right choice for every project, but in most cases users won't be able to discern between RN and native.

Ambroos 11y ago

On iOS maybe, but not on Android. You have to reimplement a lot of the things you get for free when developing native apps yourself. Most animations etc, you all have to add it yourself. Problem with that is that the React Native team has some decent iOS stuff, but for Android it's all sorely lacking. Besides Facebook's Ad Manager (which barely cuts it) I haven't seen any React Native app on Android that didn't feel horrible (and not like an Android app).

briandear 11y ago

Does the Facebook app use React "Native'? Because that app is a horrible power hog and vastly glitchy and buggy. That is a poor user experience compared to what a well written native iOS app could deliver. Users might not know its a poor experience because that can't compare to how fast and responsive the app would be if it were actually written in Swift. There are people in this world that think Olive Garden is great Italian food. There are people in this world that think React "Native' is a good user experience. Why does Facebook absolutely insist on avoiding writing actual native apps? As in Swift for example. It seems like they are almost allergic to actual native and instead focus on this inferior cross platform stuff. In 'most cases' users won't know the difference? sure they will; they'll notice that the app they're using sucks more than other apps on their phone. They'll tolerate the glichiness, the occasional blank data screen during a load because they care about the content more than the terrible experience. All because a developer or the CTO somehow thinks "it works well enough" is the same as "let's really give our users the best possible experience." I am amazed that Facebook has thousands of employees but can't be bothered to write a single line of code in Swift. They've been insisting on this stubborn course of action since the beginning of their mobile experience. Does Zuckerberg just hate Obj C or Swift? Why are they making the mobile experience into the lowest common denominator? Why does their Facebook app feel like some cheap PhoneGap experiment? My Facebook app on iOS performs exactly the same as it does on a years-old Android phone.. And that's ridiculous. I have superior hardware and yet I get to run an inferior app because JavaScript? It's like socialism for apps: make everyone equally miserable. The simple fact is this: I hate cross platform systems because they end up averaging the quantity of the mobile experience with capabilities being reduced to support the lowest common denominator. If I want my apps to run as terrible as many do on Android, I will use an Android. It's lazy development. It's a means for the JavaScript crowd to avoid leaning Swift (or Java) so they can provide middling to bad mobile apps rather than actually building the absolute highest quality product they could build. Even Facebook does it! I feel like the React Native ecosystem is doing more to reduce the quality of the mobile app experience than anything else. Apps are being turned into these average pieces of crap with only the UI being slightly different. Does anyone have any performance benchmarks on a React "Native" compared to Swift? Any data at all? Or are we just so excited to write apps in React that we fail to care? If we care about 'cross platform' development -- we can already do that; it's called 'the web.' Let stop foisting inferior mobile apps on people just because we can.

pcwalton 11y ago
JavaScript is faster in most cases than Objective-C. (I'm not going to dispute that cross-platform toolkits can have less native fidelity than compared to coding to the native toolkit can. I just don't like the Objective-C vs. JavaScript performance myth.)
- robenkleene 11y ago
  Huh? What's the Objective-C vs. JavaScript performance myth? Here's a link showing Objective-C beating JavaScript handily: https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976#.nkhch22xj https://medium.com/@harrycheung/mobile-app-performance-redux... But is this even a debate? Wouldn't you expect a compiled, manual memory managed, language to be faster than an interpreted language with garbage collection?
  - randommodnar 11y ago
    Actually JavaScript is compiled JIT by most engines these days. While it's not the fastest, it certainly can be quite fast.
    - robenkleene 11y ago
      I see, good point, but then I'd expect the cost of JIT compilation would still have a performance cost? As opposed to Objective-C being compiled before distribution to the client?
      - pcwalton 11y ago
        JIT compilation cost is minimal in practice due to tiered JITs.
  - pcwalton 11y ago
    That's an interesting benchmark, and I'd need to dive into the details to see what is going on. Perhaps there is some sort of JIT slow path. I would not expect method-heavy Objective-C to beat JavaScript. In general: > But is this even a debate? Wouldn't you expect a compiled, manual memory managed, language to be faster than an interpreted language with garbage collection? Objective-C is not compiled in terms of method dispatch, nor it is manually memory managed. Instead, all method dispatch happens through essentially interned string lookup at runtime, backed by a cache. Objective-C also has a slow garbage collector--atomic reference counting for all objects. (Hans Boehm has some well-known numbers showing how slow this is compared to any tracing GC, much less a good generational tracing GC like all non-Safari browsers have.) The method lookup issue has massive consequences for optimization. Because JavaScript has a JIT, polymorphic inline caching is feasible, whereas in Objective-C it is not. It's been well known in Smalltalk research since the '80s that inline caching is essentially the only way to make dynamic method lookup acceptably fast. Moreover, JavaScript has the advantage of speculative optimization: when a particular method target has been observed, the JIT can perform speculative inlining and recompile the function. Inlining is key to all sorts of optimizations, because it converts intraprocedural optimizations to interprocedural optimizations. It can easily make 2x-10x of a difference or more in performance. This route is completely closed off to Objective-C (unless the programmer manually does imp caching or whatnot), because the compiler cannot see through method lookups. Apple engineers know this, which is why Swift backed off to a more C++-like model for vtable dispatch and has aggressive devirtualization optimizations built on top of this model implemented in swiftc. This effort effectively makes iOS's native language catch up to what JavaScript JITs can already do through speculation.