Of course we all know that Microsoft’s IE9 and the forthcoming IE10 are native – VP Dean Hachamovitch said so many times during his keynote at the Mix 2011 conference earlier this week. That has sparked a debate about what native means – so here is another interesting case.
Appcelerator’s Titanium cross-platform tool for mobile development is native, or at least that is what it claims:
Now, I am not sure that native has a precise definition, but to me it suggests a compiled application, rather than one interpreted at runtime. So this description of how Titanium executes JavaScript – its main language – is surprising:
In a Titanium Mobile application, your source code is packaged into a binary file and then interpreted at runtime by a JavaScript engine bundled in by the Titanium build process. In this guide, you will learn more about the JavaScript runtime environment that your code runs in. Titanium runs your application’s JavaScript using one of two JavaScript interpreters – JavaScriptCore on iOS (the interpreter used by Webkit) and Mozilla Rhino on Android and BlackBerry.
So a Titanium application is actually interpreted.
Native is a vague enough term that Appcelerator can no doubt justify its use here. “Native UI” is fair enough, so is “Native capabilities.” Native performance? That seems to me a stretch, though JavaScript performance is good and constantly improving. Appcelerator even has a web page devoted to what it means by native.
Titanium is also open source. Anyone doubtful about how it works need only consult the code.
In the light of Microsoft’s statements, it is interesting that what Appcelerator really means by native is “not a web page”:
Build Native Apps … Everything else is basically a web page.
So can an application be both native and interpreted? What about Silverlight apps on Windows Phone 7, are they native? Adobe AIR apps, surely they are not native? Google Android has a Native Development Kit which is introduced thus:
The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code.
The implication is that byte code executed by the Dalvik virtual machine, which is the normal route for an Android app, is in some sense not native code. Which also implies that Appcelerator’s claims for Titanium are at least open to misunderstanding.
I live in a country not of my birth and the language of my adopted homeland is not my native tongue. I do however speak enough of the local language to perform everyday trivial operations, such as grocery shopping. But for transactions of consequence, such as property purchase, I require an interpreter – in fact the local law insists on it. So, if you require an interpreter you are not a native.
Technically, that may be too strict. I would consider a .NET app running on Windows to be native even though its compiled bytecode is interpreted.
In my mind, the term “native” is situational and should refer to an app whose code is written using the API of the OS it is running on. For example a Silverlight app running on Windows Phone would be native, but the same app running as an out-of-browser app on a Mac would not be native.
Bob F, .NET is not generally interpreted, the runtime JIT compiler converts byte code to native machine code when required.
Also .NET/Mono etc all thunk down to native API calls eventually, so are all .NET applications not `native`?
I’ve always took native to mean it compiles and executes as the same code level as the operating system expects, such as x86 machine code executables on most PC platforms.
However you could argue there’s several layers to this argument such as native execution, native look & feel etc, the term has become ambiguous.
Hey Tim –
Thanks for the post. You are right… on both native/interpreter accounts. Titanium compiles down to native code and when we say ‘native’, we’re saying that you’re executing native code for every method and property you use. At Appcelerator, we think that’s really important, especially for features like UI where you don’t want to sacrifice performance for ease of development (eg: running UI in a web view is generally not a good idea).
So in practice, what this means is that you’re doing all the heavy lifting on the native side of the bridge. That’s why we have about 3,600 methods and properties in our current API: http://developer.appcelerator.com/apidoc/mobile/latest. It’s a massive API. All of that is required to get ‘native’ performance and look & feel in your app.
At the same time, JavaScript is a dynamic language, which requires an interpreter. So, we’ve essentially stripped down webkit for just the JS engine and handed that to the developer.
The result is a cake and eat it too approach. Write your app in an efficient scripting language and compile it into 99.99% native code. Don’t do any of the heavy lifting on the JS side, but instead execute all native ObjC/Java code at runtime.
Hope this helps. Happy to discuss further. sschwarzhoff at appcelerator dot com
Scott Schwarzhoff
VP, Developer Relations
JavaScript benefits from JIT compilers as well, but that doesn’t make JavaScript apps native in my book. I tend to think of “interpreted” as being anything that doesn’t get translated to machine code until runtime. Although, even by that definition, .NET is both compiled and interpreted. Of course, debating semantics can lead down a rat hole pretty quickly. 🙂
As I stated, IMHO opinion, .NET apps ARE native despite the fact the bytecode has to be translated to machine code. That was my point; an app not delivered as machine code could still be considered a native app.
True, and Tim alluded to that as well. Bottom line: I think Tim’s doubts about Titanium apps being native are well founded.
This reminds me a little of the old arguments about if a browser could really be part of an operating system. I’m old school about this. If there’s a browser/interpreter/JIT/CLR/whatever running your code then its not really a native app. Maybe that means native apps are less important now – except maybe on mobile.
This reminds me of someone on amiga.org who would argue that all APIs suck because their are inefficient, basically arguing that assembler is the only way to go.
Surely if you take it literally, if its not banging the hardware directly is not native, which would mean the OS itself isn’t either as almost everything will be coded on top of APIs and libraries which effectively are translation layers.
All this really highlights is that terminology is a PITA, because nobody should care how “native” something is. Its no longer about coding as close to the hardware as possible, its not cost effective to do that any more, its all about how efficient one translation layer runs vs another – nothing is really native. So as long as you are getting performance comparable to other methods of writing the same application, that is what is important.
Basically, the word you are looking for is “efficient” not “native”. Its the same kind of abuse as people using “quality” all over the place, without actually expanding on if that is good or poor quality they are referring to.