5 ms·

Apps running inside a JS vm on iOS or Android are not "truly native". Misappropriating an existing term (native app) to include such a design is uninviting; not

by jeswin 9y ago

Apps running inside a JS vm on iOS or Android are not "truly native". Misappropriating an existing term (native app) to include such a design is uninviting; not even necessary. There are so many ways in which this is inferior to native code. And I say this as someone who works primarily with JavaScript.

Mayzie 9y ago
To be fair, "native" in this sense is exposing platform native UI components and libraries, which gives apps a native look and feel because, well, they _are_ native. For most apps that's all you'll ever need, and the performance overheard of running JS is negligible. For any performance critical code, you can write them in the platforms native code and interface with them via JavaScript. Unfortunately though, so many developers do not know how to write in the platforms preferred native language and you end up with components, like most of those listed on awesome-react-native[1], where they're entirely written in JS which: * sometimes emulate the native look and feel (often poorly), not _are_ the look and feel, and, * as a result, often perform super poorly compared to their native counterparts, and, * if emulating the native look and feel, and not implementing their own design/UI (which most do), that look and feel can break between OS upgrades and feel out of place, and, * often don't distinguish between platforms (i.e. the developer won't bother implementing the look and feel for Android, where the component is entirely compatible). [1] - https://github.com/jondot/awesome-react-native https://github.com/jondot/awesome-react-native
- benjaminl 9y ago
  To be truly fair the claim is "truly native", not just "native". If the claim was, native GUI, that would work, but "truly native" is a huge stretch. These apps are about as native as the Java based Eclipse IDE whose SWT based UI uses native GUI elements for display.
- wlesieutre 9y ago
  My experience with React Native was that it doesn't consistently use native UI components, it uses UIViews that people have cobbled together into their own replications of varying quality. So if you want a big grid of items, you're not using a UICollectionView, you're reimplementing it yourself or finding someone else's attempt at that. Maybe this is because a UICollectionView doesn't have an identical counterpart on Android so it's easier to just redo it from scratch? But I'd be surprised if the performance of these things is as good as the real native ones, even if they make it out of UIViews. My other big complaint is that it doesn't help you with UI size classes. iOS apps change their layout depending on (generally) whether you're on an iPad (fullscreen / large split), or iPhone (and iPad small split, which is iPhone sized but much taller). The two weird exceptions being the iPad Pro having two full sized splits, and the Plus sized phones acting sort of iPad-like in landscape view. Anyone have an example of a React Native app that follows those conventions correctly? Last I checked the Facebook app (which I assume is something of a canonical example) doesn't even support split screen, and iOS 9 came out in 2015. This was a year or so ago that I was poking around at it, things may have improved since then?
  - andrewingram 9y ago
    The main Facebook app isn't React Native (though parts of it might be)
    - wlesieutre 9y ago
      Ah, interesting. I just assumed that's what they made it for.
rtpg 9y ago
eh, is that really the line? Does it matter what language it's coded in? In the end if you're ending up calling the same UI APIs.... The issue with web apps is more about the UI and performance, but I really doubt that the JS VM will kill performance.
- bobwaycott 9y ago
  In my humble opinion, native means exactly that—identical and indistinguishable from a platform’s native code and full capabilities using its expected native language(s) because the byte code is identical. Native UI—the combined term—means using, not emulating, platform-native UI elements and APIs—it actually uses the platform-native byte code. Things that are indistinguishable in appearance do not qualify as native, unless one clearly distinguishes s/he means native look and feel. When one says truly native, that is an even stronger claim that, in my opinion, directly communicates we are talking about byte code. On iOS, for example, native means Obj-C and Swift. When I read someone has created a framework/library that provides truly native apps using X and Y, my immediate expectation is we are talking about X and Y compiling down to platform-native byte code, with no VM, unless the platform itself is a VM. An example here is Elixir compiling down to truly native BEAM apps. For the web, JS is truly native. There are a host of other non-JS technologies that compile down to truly native code for the web. I’ve yet to see any JS technologies that compile to truly native platform code for desktop and mobile (except mobile platforms which use web technologies as platform-native code)[0]. [0]: A quick perusal of NativeScript claims it does not use web views. If it actually lets you directly create and use a UITableView, UIButton, UIListView, and the rest, then perhaps it can qualify as native UI. But there’s still a bridge to cross from there to truly native app, and I’m unsure if it actually becomes 100% platform-native code without a JS VM involved the way, for iOS, Obj-C and Swift are.
  - pka 9y ago
    Yeah, your native vs truly native distinction is just splitting hairs. Unless you're making a game or an otherwise CPU intensive app why does it matter whether you create your UIViews from ObjC or a JS VM?
Turing_Machine 9y ago
Running in a Dalvik/ART JVM isn't "truly native" either, from that point of view.
- orbitur 9y ago
  That's not the point. Running in the JVM is the most performant way to access Android's APIs. That's "native".
  - Turing_Machine 9y ago
    What if the JavaScript is compiled to JVM opcodes? I guess I don't see your point here. A Java compiler takes Java code and compiles it to JVM opcodes. Presumably this package (I haven't looked at the details, so could be wrong here) takes JavaScript code and compiles it to JVM opcodes. I see no prima facie reason to assume that one would be more "performant" than the other. That's the whole idea behind things like LLVM and CLR, right?
    - iOSGuy 9y ago
      It doesn’t compile it to JVM, it runs a JS engine, and then passes some calls into the native side over an asynchronous bridge, and the native code then builds native views at runtime. It’s a middle ground, and it’s super useful in some cases, and super dumb in others. It’s not a silver bullet, it doesn’t solve all the problems, but it has some good use cases.
dang 9y ago
Ok, we changed "truly native apps" to "native UIs" in the title above.

by jeswin 9y ago

Mayzie 9y ago

To be fair, "native" in this sense is exposing platform native UI components and libraries, which gives apps a native look and feel because, well, they _are_ native. For most apps that's all you'll ever need, and the performance overheard of running JS is negligible. For any performance critical code, you can write them in the platforms native code and interface with them via JavaScript. Unfortunately though, so many developers do not know how to write in the platforms preferred native language and you end up with components, like most of those listed on awesome-react-native[1], where they're entirely written in JS which: * sometimes emulate the native look and feel (often poorly), not _are_ the look and feel, and, * as a result, often perform super poorly compared to their native counterparts, and, * if emulating the native look and feel, and not implementing their own design/UI (which most do), that look and feel can break between OS upgrades and feel out of place, and, * often don't distinguish between platforms (i.e. the developer won't bother implementing the look and feel for Android, where the component is entirely compatible). [1] - https://github.com/jondot/awesome-react-native https://github.com/jondot/awesome-react-native

benjaminl 9y ago
To be truly fair the claim is "truly native", not just "native". If the claim was, native GUI, that would work, but "truly native" is a huge stretch. These apps are about as native as the Java based Eclipse IDE whose SWT based UI uses native GUI elements for display.
wlesieutre 9y ago
My experience with React Native was that it doesn't consistently use native UI components, it uses UIViews that people have cobbled together into their own replications of varying quality. So if you want a big grid of items, you're not using a UICollectionView, you're reimplementing it yourself or finding someone else's attempt at that. Maybe this is because a UICollectionView doesn't have an identical counterpart on Android so it's easier to just redo it from scratch? But I'd be surprised if the performance of these things is as good as the real native ones, even if they make it out of UIViews. My other big complaint is that it doesn't help you with UI size classes. iOS apps change their layout depending on (generally) whether you're on an iPad (fullscreen / large split), or iPhone (and iPad small split, which is iPhone sized but much taller). The two weird exceptions being the iPad Pro having two full sized splits, and the Plus sized phones acting sort of iPad-like in landscape view. Anyone have an example of a React Native app that follows those conventions correctly? Last I checked the Facebook app (which I assume is something of a canonical example) doesn't even support split screen, and iOS 9 came out in 2015. This was a year or so ago that I was poking around at it, things may have improved since then?
- andrewingram 9y ago
  The main Facebook app isn't React Native (though parts of it might be)
  - wlesieutre 9y ago
    Ah, interesting. I just assumed that's what they made it for.

rtpg 9y ago

eh, is that really the line? Does it matter what language it's coded in? In the end if you're ending up calling the same UI APIs.... The issue with web apps is more about the UI and performance, but I really doubt that the JS VM will kill performance.

bobwaycott 9y ago
In my humble opinion, native means exactly that—identical and indistinguishable from a platform’s native code and full capabilities using its expected native language(s) because the byte code is identical. Native UI—the combined term—means using, not emulating, platform-native UI elements and APIs—it actually uses the platform-native byte code. Things that are indistinguishable in appearance do not qualify as native, unless one clearly distinguishes s/he means native look and feel. When one says truly native, that is an even stronger claim that, in my opinion, directly communicates we are talking about byte code. On iOS, for example, native means Obj-C and Swift. When I read someone has created a framework/library that provides truly native apps using X and Y, my immediate expectation is we are talking about X and Y compiling down to platform-native byte code, with no VM, unless the platform itself is a VM. An example here is Elixir compiling down to truly native BEAM apps. For the web, JS is truly native. There are a host of other non-JS technologies that compile down to truly native code for the web. I’ve yet to see any JS technologies that compile to truly native platform code for desktop and mobile (except mobile platforms which use web technologies as platform-native code)[0]. [0]: A quick perusal of NativeScript claims it does not use web views. If it actually lets you directly create and use a UITableView, UIButton, UIListView, and the rest, then perhaps it can qualify as native UI. But there’s still a bridge to cross from there to truly native app, and I’m unsure if it actually becomes 100% platform-native code without a JS VM involved the way, for iOS, Obj-C and Swift are.
- pka 9y ago
  Yeah, your native vs truly native distinction is just splitting hairs. Unless you're making a game or an otherwise CPU intensive app why does it matter whether you create your UIViews from ObjC or a JS VM?

Turing_Machine 9y ago

Running in a Dalvik/ART JVM isn't "truly native" either, from that point of view.

orbitur 9y ago
That's not the point. Running in the JVM is the most performant way to access Android's APIs. That's "native".
- Turing_Machine 9y ago
  What if the JavaScript is compiled to JVM opcodes? I guess I don't see your point here. A Java compiler takes Java code and compiles it to JVM opcodes. Presumably this package (I haven't looked at the details, so could be wrong here) takes JavaScript code and compiles it to JVM opcodes. I see no prima facie reason to assume that one would be more "performant" than the other. That's the whole idea behind things like LLVM and CLR, right?
  - iOSGuy 9y ago
    It doesn’t compile it to JVM, it runs a JS engine, and then passes some calls into the native side over an asynchronous bridge, and the native code then builds native views at runtime. It’s a middle ground, and it’s super useful in some cases, and super dumb in others. It’s not a silver bullet, it doesn’t solve all the problems, but it has some good use cases.

dang 9y ago

Ok, we changed "truly native apps" to "native UIs" in the title above.