Then again, one cannot expect all of any website's client devices to have a correctly calibrated displays. Unless you have control over entire stack (from your service hardware all the way to client displays), you have to start your design (graphical or otherwise) with the assumption that there will be differences in how your product is perceived by your clients.
I'm not sure if I like introducing computer science with a physical "computer". A physical "computer" is an application of computer science. I rather start with an abstract idea of computation, but my view point is very skewed towards academia. I'd love to hear what others have to say about this approach.
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.
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 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.