4 ms·

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

by 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?
  - bobwaycott 9y ago
    Because one is native, while the other is not. I don’t think I’m splitting hairs, except in allowing a distinction between native vs native UI. Words have meaning. If a JS VM is being used on a platform for which JS is not a platform-native language and runs in a VM, it’s pretty much clear that’s not native. Calling it native—much less truly native—is making a false claim at worst, or muddying clarity of language and terminology at best. Perhaps creators of JS app technologies should stop claiming to be native, and none of us would ever have to go investigating the latest framework/library to find out if they mean what the rest of us mean when we say native.
    - t1amat 9y ago
      This is similar to the long-running argument distinguishing “transpile” and “compile”. It’s a pointless disctintion in most contexts rife with technicalities and ad-hoc definitions. Irrespective of what you believe, I think you can see a substantial difference between say React Native and a Cordova app, right?
      - bobwaycott 9y ago
        > ... I think you can see a substantial difference between say React Native and a Cordova app, right? Absolutely. I see a difference between this and discussion about transpiling vs compiling. One of the things I appreciate about transpiling is that it is a different word that does not attempt to take a word with established meaning. I obviously don’t think it’s a pointless distinction—but then I don’t find myself bothered by technicalities when it comes to technical things that need clear meanings. I think the JS community has brought this problem upon itself by trying to lay claim to the word native when talking about web apps or apps built with web technologies for platforms that don’t rely on web stack as core/native tech. If they’d just choose/create a word that doesn’t already have established meaning on the target platform or technical space, I don’t think there’d be disagreement or confusion. It’s the same thing when people claim Electron apps are native apps. We all know they aren’t really—they’re web apps wrapped up in a native window, relying on a full browser stack and JS VM to do what they do. I think it’s awesome people are working on things like Electron, because it’d be amazing to have an easy toolchain to create cross-platform native apps that is accessible to everyone. But they aren’t going to be native, and definitely can’t claim to be truly native until someone turns it into platform-native code that doesn’t need a VM. Ultimately, we wouldn’t need to have this discussion if particular words loaded with extant meaning weren’t being misappropriated by the JS community. At least where mobile/desktop platforms are concerned, native means building with and using UI, threading, performance, libraries, APIs, and a whole host of things directly. I don’t look forward to the day where the JS community co-opts the term to the extent the platform-native tech has to start calling itself by some word other than native. EDIT: Full disclosure—I like native technologies on various platforms, and don’t particularly find myself interested in building mobile/desktop apps in JS, HTML, and CSS.
kodablah 9y ago
> eh, is that really the line? Does it matter what language it's coded in? Yes, it matters. Levels of indirection matter. Doubting performance or not doesn't change the definition of the term which is admittedly ambiguous. There are two forms of "native" IMO now. There is "system native" which I define as AOT to processor instructions. VMs, even with JITs, don't count (yup, this includes Android's JVM). Then there is "platform native", which I define as AOT-compiled to platform-suggested instructions. This does include Android JVM bytecodes. This falls under neither. It may not matter what language something is coded in depending upon your requirements, but we shouldn't keep ascribing even more meaning to the term native.

by rtpg 9y ago

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?
- bobwaycott 9y ago
  Because one is native, while the other is not. I don’t think I’m splitting hairs, except in allowing a distinction between native vs native UI. Words have meaning. If a JS VM is being used on a platform for which JS is not a platform-native language and runs in a VM, it’s pretty much clear that’s not native. Calling it native—much less truly native—is making a false claim at worst, or muddying clarity of language and terminology at best. Perhaps creators of JS app technologies should stop claiming to be native, and none of us would ever have to go investigating the latest framework/library to find out if they mean what the rest of us mean when we say native.
  - t1amat 9y ago
    This is similar to the long-running argument distinguishing “transpile” and “compile”. It’s a pointless disctintion in most contexts rife with technicalities and ad-hoc definitions. Irrespective of what you believe, I think you can see a substantial difference between say React Native and a Cordova app, right?
    - bobwaycott 9y ago
      > ... I think you can see a substantial difference between say React Native and a Cordova app, right? Absolutely. I see a difference between this and discussion about transpiling vs compiling. One of the things I appreciate about transpiling is that it is a different word that does not attempt to take a word with established meaning. I obviously don’t think it’s a pointless distinction—but then I don’t find myself bothered by technicalities when it comes to technical things that need clear meanings. I think the JS community has brought this problem upon itself by trying to lay claim to the word native when talking about web apps or apps built with web technologies for platforms that don’t rely on web stack as core/native tech. If they’d just choose/create a word that doesn’t already have established meaning on the target platform or technical space, I don’t think there’d be disagreement or confusion. It’s the same thing when people claim Electron apps are native apps. We all know they aren’t really—they’re web apps wrapped up in a native window, relying on a full browser stack and JS VM to do what they do. I think it’s awesome people are working on things like Electron, because it’d be amazing to have an easy toolchain to create cross-platform native apps that is accessible to everyone. But they aren’t going to be native, and definitely can’t claim to be truly native until someone turns it into platform-native code that doesn’t need a VM. Ultimately, we wouldn’t need to have this discussion if particular words loaded with extant meaning weren’t being misappropriated by the JS community. At least where mobile/desktop platforms are concerned, native means building with and using UI, threading, performance, libraries, APIs, and a whole host of things directly. I don’t look forward to the day where the JS community co-opts the term to the extent the platform-native tech has to start calling itself by some word other than native. EDIT: Full disclosure—I like native technologies on various platforms, and don’t particularly find myself interested in building mobile/desktop apps in JS, HTML, and CSS.

kodablah 9y ago

> eh, is that really the line? Does it matter what language it's coded in? Yes, it matters. Levels of indirection matter. Doubting performance or not doesn't change the definition of the term which is admittedly ambiguous. There are two forms of "native" IMO now. There is "system native" which I define as AOT to processor instructions. VMs, even with JITs, don't count (yup, this includes Android's JVM). Then there is "platform native", which I define as AOT-compiled to platform-suggested instructions. This does include Android JVM bytecodes. This falls under neither. It may not matter what language something is coded in depending upon your requirements, but we shouldn't keep ascribing even more meaning to the term native.