The issue with web apps is more about the UI and performance, but I really doubt that the JS VM will kill performance.
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.
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.
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.