Comment by bobwaycott | Hacker News Reader

Comment by bobwaycott | Hacker News Reader

Parent Full thread

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.

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?

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.

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?

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

Reply on news.ycombinator.com