>I keep trying though because I just love the idea that I can use my current web development skill set to create native apps for this so easily. My first attempts on the ZTE Open went really well.
I'd say those apps are hardly native, now, are they? There are several layers between the code you write, and the actual ARM(in most cases) machine code.
Native depends on the platform. Firefox OS is all in HTML, CSS and JavaScript so an application containing those languages would in fact be native for Firefox OS.
"Native apps" are ones that have been compiled down to machine code that's directly executable on whatever CPU or CPUs might be provided by the device in question. Ahead-of-time compilation is thus required.
As such, "native apps" cannot be represented solely in a higher-level code that is interpreted, regardless of how its interpreter may be implemented (this includes direct interpretation, JIT compilation, and so on).
Apps built using interpreted JavaScript clearly are not "native" apps, unless we're dealing with hardware that directly executes JavaScript code. The ARM CPUs typically found in smartphones today don't do that.
What you're describing is independent from the concept of "native apps". It's more about platform restrictions than it is about their capabilities. If an operating system like Firefox OS goes out of its way to not support real native apps, that doesn't mean that what it does support are "native" in any way.
I don't know if there's a good term to use instead, but it surely does not involve the word "native" in any way, given that that term already has very specific and existing meaning.
In the case of mobile, the term is used differently, at least as far as I have seen.
Native apps are often used to describe apps using the platforms own UI toolkit, widgets and API libraries (that is, they look and feel like platform apps and they integrate into the platforms services/notifications/...)
So for FirefoxOS, HTML apps could be considered "native" by this definition.
Speed definitely still matters for everyday apps on mobile devices, because their processors are so much slower than actively-cooled desktops and laptops, and because touchscreens demand a more responsive UI. JIT runtimes have gotten faster, but statically compiling to machine code (especially when link-time optimization is used) cannot be beat for things like application launch performance. And the machine code that Objective-C compiles down to is definitely more native than bytecode for a JIT VM.
Could we start to come to an agreement that maybe "Native" might be a bit of a marketing term? For example a browser rendering HTML and CSS is probably native under the current term. It is not until you get to JavaScript that things need the JIT VM.
There's still objective meaning to the term, even if opinions may differ on what threshold to use for "native". HTML and CSS aren't used to do computation, bytecode and machine code are. So it doesn't make sense to talk about whether HTML and CSS are native or not, only whether the rendering engine is. JITs produce native code, but a lower quality in almost all cases when compared with ahead-of-time optimization, so there's still good reason to make a distinction.
"Native" is not a marketing term, and we shouldn't pretend that it is.
It has a very specific definition in this context, and this definition requires that the application be represented in a form that's directly executable on whatever CPU is being used by the computer executing the application.
Anything that doesn't match that very simple criteria is obviously not a "native" app.
Maybe a new term is needed for describing this type of situation involving Firefox OS. I don't know what that would be, but I do know that we shouldn't go ruining an existing technical term.
Right. If there's bytecode of any sort that needs to be converted to machine code on the fly, then we aren't dealing with a native app.
We wouldn't consider a Java app running on HotSpot on a desktop or server Linux system to be considered a "native app". Thus we shouldn't consider a Java app running on Dalvik on a mobile Linux system to be considered a "native app" either.
Maybe that will change in the Android case if ART and its AOT compilation approach is more widely adopted. But that'll still be some time in the future, if ever at all.
You can actual write in assembler on iOS and use that (sparingly) in your programs, which means there are optionally no layers between you and the CPU.
For almost all apps, that's unnecessary, but it's there as an option if you really need it.
You see a bit of this in game development. At my old job, our engine was written in C++, however we had two copies of our matrix library: one written in C for desktop etc. and one written in ARM NEON asm, for building on iOS or with the Android NDK.
That argument would have more weight if you iPhone apps were distributed as Objective C source code.
They're distributed as ARM binaries. I think the standard definition of "native" is "binary". I would argue that Firefox OS apps are not native, and neither are Android's Java based apps.
That said, I don't think the distinction necessarily matters in practice. I'm excited by Firefox OS--Mozilla tends to do cool stuff.
I'd say those apps are hardly native, now, are they? There are several layers between the code you write, and the actual ARM(in most cases) machine code.