Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

Definition of "Native"? HTML/CSS apps?

I'm struggling with misinterpretation, differing opinions, and ambiguous language with regards to Titanium Mobile, and exactly what it does.

I've come here for definitive answers.

The word "native" is uttered frequently on this website and introductory videos. I know what's implied by this, but I'm not clear on the truth - and everyone has a different opinion. Most people are telling me that it is "compiled to native code". Is this true? Really?

I believe that the UI APIs and other APIs are executed natively. Platform-specific library. I found a presentation that was given at OSCON. In these slides, it is stated that: "A Titanium application is a JavaScript program that is interpreted at runtime on the device". Now that sounds plausible to me. But that's not "compiled to native code".

Apparently, I can develop my apps in HTML/CSS. I can see that within the app.js, I can attach a web view webkit browser component. But then the javaScript within my HTML is treated differently from the javaScript in my main program. It would just run within webkit. No "native" advantage here. Or have I got it wrong?

— asked October 4th 2010 by Daniel Freeman
  • marketing
  • misinformation

3 Answers

  • @daniel Have you seen the latest marketing ? Go look at the front page, it's shameless.

    — answered March 11th 2011 by Space Invader
  • Its pretty simple daniel…

    1.when you code your app in Titanium(in java script) , during compiliation (on the development machine)..the Titanium SDK coverts all the javscript codes to native codes..While deployment the native codes specific to the Devices are alone deployed or packaged for the devices…

    2.create a sample application in Titanium and compile it for android.After a success full run on the emulator.. go to the code base of the sample project and inspect the files and folder architecture under build directory… you can see them similar to those encountered if you develop natively for android using Eclipse…

    — answered October 4th 2010 by Satta Ravi
    • That is not correct. The code is interpreted at run time and calls to the APIs result in calls to native functions via a JS<->native bridge. The "native advantage" is that you're not limited to a browser, and have full access to the native APIs exposed by Titanium, with the ability to add your own APIs fairly easily.

      Re the OP's questions, you can access native APIs from a webview via a web>app>native bridge (by generating and responding to events). If you want to make your app feel native though, you should be writing most of your UI using Ti's UI API.

      — commented October 4th 2010 by Damien Elmes
    • Thank you Damien! Your answer makes perfect sense, as it tallies with my own hypothesis.

      I don't blame Sattanaathan or other developers who talk about "native code" being generated. Appcelerator's marketing is at worst VERY MISLEADING, and at best open to misinterpretation. Allegedly.

      Using Titanium's UI API is not an option for our proposed app. We are about to embark on a project with a lot of custom UI stuff and fast interactive graphics, and I don't think Titanium will give us native speed, power, and flexibility we need to accomplish this. (I'm the senior developer).

      We are being coerced down the Titanium path because my client believes the marketing hype, and thinks it's as good as native SDK development.

      So thank you Damien. In confirming my hypothesis, you have equipped me with strong enough argument to steer the project to real native SDK development. After all, I'm proficient in both Android and iOS development, and the team have some experience in Android or Java. It made more sense to me to push the team up the iOS learning curve, than to get them to learn Titanium.

      — commented October 4th 2010 by Daniel Freeman
    • I would say for applications that are not very graphic intensive you will get as near the speed of something coded directly for the API as makes no difference. But for your requirements you're probably right that something more low-level might be a better fit. I think it's unfair to dismiss Appcelerator as hype though - a lot of people are building a lot of impressive things with it and it gets you a lot closer to the metal than most of the alternatives.

      — commented October 4th 2010 by Alan Bourke
    • I can see where Appcelerator will be advantageous. My reaction is to the hype, not the technology. At least the phoneGap community seem like honest developers in jeans and T-shirts. Not marketing sharks in suits. My problem is with the following (implied) claims:-

      1. JavaScript is compiled to native code.
      2. HTML/CSS projects gain a native advantage too.
      3. More people write apps using Titanium than with Objective-C
        (3 is a new one. I haven't had time to investigate. I'd be happy to concede if someone can point me at proof).

      While the marketing doesn't explicitly state these claims, this is the impression I think people are getting.

      — commented October 5th 2010 by Daniel Freeman
    • Thanks Damien for giving me a clear picture of what is going on inside Titanium…

      — commented October 5th 2010 by Satta Ravi
    • At least on Android, there is a compilation from JavaScript to Java through Rhino's JSC.

      — commented October 5th 2010 by Sami B.
  • Daniel -

    Titanium creates both native code and runs via an interpreter at run-time. The 'heavy-lifting' is done native code side.

    So, on animations, you are really accessing the core animation libraries on the device. That's native code. But you are setting up the transforms, etc, using JavaScript.

    There is no 'hype' here - native code is generated. Look at the source that's created.

    You get code efficiency and cross-platform for 80% of the APIs in question. Developers build high-profile, high-performing apps all the time (look at the home page for examples) and collectively, we're the largest publisher of iOS apps on the market today.

    — answered October 4th 2010 by Scott Schwarzhoff
    • btw: the "HTML/CSS" piece is what "the other guys offer". Ours is a pure 1:1 javascript==>low-level binding approach. That's also why the API is, in technical terms "huge" with 3500 methods and processes at your disposal.

      — commented October 4th 2010 by Scott Schwarzhoff
    • @Scott

      You say that "There is no 'hype' here", yet Sattanaathan came back immediately with an answer that I've been hearing repeated again and again. And the fact is that answer is wrong. It's not Sattanaathan's fault. For all I know, he is as experienced and accomplished as I am. I'm sure these developers don't mean to be misleading. But they themselves have been mislead by Appcelerator's marketing claims.

      To say that "Titanium creates both native code and runs via an interpreter at run-time" is meaningless. What use is this simplified statement anyway? phoneGap also has a native wrapper that is compiled. (Although I don't care about phoneGap, I'm more concerned that Titanium is touted as being on-par with Objective-C and Android SDK Java - or at least that's the implication of the hype).

      We are experienced developers. We understand compiler techniques. I have patents in advanced compiler optimisation. (Admittedly, a long time ago when I was an expert in such matters). You don't have to dumb it down for us. Your simplifications are misleading.

      And you mention animations. Did you mention this because I talked about "fast interactive graphics" below. Do you think I don't know the differences between animated transitions, and custom graphics? Or were you hoping that you could obscure the difference, to give the impression of an Appcelerator advantage, where there is none. Because this is exactly the problem I'm having with your hype.

      OK, Appcelerator Titanium does have an advantage over phoneGap. I can see that. But you concentrate on your real strengths, and not pretend that you're the all singing - all dancing panacea to absolutely every kind of application.

      My point with HTML/CSS is that a developer with an existing HTML5 project is lead to believe that they can just port it into Appcelerator Titanium, and gain an advantage of "native" execution. I can't see this working. The javaScript within their existing web project will still run within webkit. It's important to understand that there are TWO javaScript interpreters. Yours, and the one within webkit. I can't see how an existing web standard project will gain any advantage without a lot of re-working.

      And now you've introduced a NEW CLAIM! You say that "we're the largest publisher of iOS apps on the market today". The implication is that more people write apps using Titanium than with Objective-C. If this is true, where is your proof? ( But even if it's true, I still prefer Xcode, but I'm an Apple fan-boy and my background is C++ and OOP).

      — commented October 5th 2010 by Daniel Freeman
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.