Introducing Hyperloop


NOTE: The information in this post is outdated. For the very latest on Hyperloop, see here.
Time has finally come to introduce something that we’ve been working on for a few months. We call it Hyperloop.
Hyperloop is a next-generation compiler that turns a special flavor of JavaScript, something we call HJS, into native code. This code currently works in tandem with a JavaScript runtime to execute compiled native instructions.
HJS adds a small number of special keywords to JavaScript that tell the compiler how to treat the code when it compiles. Think about HJS similar to CoffeeScript or TypeScript, albeit with a more familiar JS syntax and only a few special keywords.
For example, let’s take a real simple example for Objective-C and iOS.

var view = new UIView();
view.frame = CGRectMake(0,0,100,100);

The above code will tell the compiler to import the UIKit framework and use it to resolve any variables not specifically declared in JS scope using the native APIs. In this case, UIView is an interface defined in the Objective-C UIKit framework. Also, CGRectMake is a normal C function defined in the framework CoreGraphics. Notice for both, you are using a very familiar JS syntax to declare and use them. However, unlike JS, this code is compiled into native code (in this case, Objective-C) by the Hyperloop compiler.

Hyperloop Architecture

Like most compiler designs, Hyperloop is split into a front-end and a back-end. The front-end is responsible for turning parsed HJS into an Abstract Syntax Tree (AST) representation and doing certain source-to-source optimizations. The back-end is responsible for turning this AST into native code, depending on the target language and platform.
With the current developer preview, we’re supporting Objective-C and iOS. However, we are concurrently working on supporting Android and Windows and will support many other back-ends in due time. Of course, as any initial preview, this code is very experimental and very raw and shouldn’t yet be used in production.
Check out this OpenGL simulation video and source code written in HJS and compiled with Hyperloop.

So what does Hyperloop have to do with Titanium?

We are re-building Titanium, something we are calling Ti.Next, using the new Hyperloop compiler architecture. The new Titanium API will be built entirely in HJS and compiled down into pure native code using the Hyperloop compiler. This will give us tremendous execution performance as well as a more flexible architecture for exposing new APIs and integrating Titanium with existing native applications. This will also allow us to re-think how you extend Titanium. Currently, you build native modules to extend the Titanium API. With Hyperloop, we will introduce a more flexible way to build native modules or integrate third-party code directly into your Titanium applications.

Can I use Hyperloop for other types of platforms like desktop APIs or Node.js?

In fact, yes, that’s the goal. But to really expand your thinking, how about with something like V8 and Node.js? One of the target opportunities I believe is to go beyond Titanium with Hyperloop. Think about taking the power of the HJS syntax to writing native Node modules. Instead of having to write in lower-level C against a system API, use Hyperloop to write your native node module. To make this happen, we would simply target a different compiler backend for Node. While this isn’t supported today, that’s where we’re headed.

Can I use Hyperloop without Titanium?

Yes, while Titanium will depend on Hyperloop, Hyperloop has no dependencies on Titanium and you can build native apps using Hyperloop without having to do anything related to Titanium.

What about Ti.Current and Modules?

We are experimenting with a compiler command that will allow you to target Ti.Current modules. The idea is that you can build your Ti.Current modules using HJS and Hyperloop compile and package them as modules that would work with your applications today. Again, this isn’t supported right now, but something we hope to deliver soon. This would give you a great way to start using the benefits of Hyperloop with modules today, without having to wait for Ti.Next. In fact, we’re experimenting to see if this is viable in the short-term to use for new APIs we’re adding to Titanium 3.2.0.

Are you going to make it easier to do an abstraction around the different APIs?

Not at present. Since Hyperloop isn’t meant to be a cross-platform toolkit, that’s what Titanium is for, we won’t likely be adding this to Hyperloop anytime soon (if ever). However, since Hyperloop supports the Node.JS require module system API, it should be easy to do this yourself. There’s no reason you can’t create your own abstractions and load them using require.

Does that mean I have to learn the native system APIs?

Yes, Hyperloop is specifically meant to be a way to program native APIs and get native, compiled performance. However, like Titanium Module SDK development is today, you need to understand the system APIs. If you can’t learn enough of how to call the system APIs, then Hyperloop won’t be able to help you much either.

When will this be stable? When is Ti.Next available?

We don’t have a specific timeline just yet. While we’ve made considerable progress in stabilizing the current target, it’s far from being something that’s ready to ship. We need to make progress on Windows and Android backends before we can start the work of re-building the Ti.Next platform. However, we’ve done enough early work on Ti.Next APIs in our R&D phase, that we’re confident we’ll be able to go fast once we get Hyperloop to that stage. I can’t commit to any dates just yet, but our hope is to have all three first class platforms (iOS, Android and Windows) stable enough by the end of the year we can start working in earnest on Ti.Next APIs. As you can imagine, we have a lot of other considerations for Ti.Next beyond just APIs such as CLI, Studio, testing, QA, etc. that will greatly impact the Ti.Next release date. All of those considerations haven’t yet been fully flushed out and won’t until we can get Hyperloop to a point that we have a definitive idea how long it will take to complete the Ti.Next API work.

So, what can you do with it? Any examples?

Yes, glad you asked. We have built a number of examples that are currently available in the Github repo and we’re always adding them every few days. Some are more tests than full examples, but looking through the source code, you should be able to get an idea of how powerful Hyperloop will be.

How can I help?

Hyperloop is open source and we’re grateful that we’ve already had a number of pull requests come in before it’s full even public. Like Titanium, Hyperloop is licensed under the Apache Public License. So, feel welcome to fork and send us your pull requests. If you haven’t already signed a CLA, please do so before sending a pull request.

Is there a discussion list to talk about Hyperloop?

Yes, we have created a Google Groups specifically to talk about Hyperloop development while we’re in hyper dev mode. We’d love your feedback. If you find a specific issue, please open a Github Issue.

Previous articleUsing Android’s ActionBar
Next articleWhat “mobile first” really means
Co-Founder and CEO at Pinpoint


  1. Congrats on this milestone!
    “However, we’ve done enough early work on Ti.Next APIs in our R&D phase, that we’re confident we’ll be able to go fast once we get Hyperloop to that stage.”
    Are there any first drafts we could have a peak at? This is where you get me interested 😛

      • And, will Hyperloop supersede CommonJS and eventually Alloy? Or will we have a Titanium IDE that lets you choose between Classic, Alloy and Hyperloop? Is Hyperloop totally replacing Titanium?

          • @Fokke Zandbergan: Fokke, imho the interview is not so clear (neither the end of your post) and the code at GitHub (and some code at the beginning of this post) can easily convince you that something big could happen. Nobody here is telling “Titanium is dead” but nobody is telling it’s alive too.

  2. Hmm. If I read this right, it means that is less abstracted from the underlying API’s. So :-
    1) Easier to make more use of native API. Faster code
    2) Less re-usable code. i,e. my code of IOS will be closely tied to the IOS SDK and same for android
    “Since Hyperloop isn’t meant to be a cross-platform toolkit, that’s what Titanium is for,”
    Main question – is Hyperloop a replacement for titanium (your long term direction), or is it an alternative to titanium.
    i.e. I want cross platform code base – titanium. I want full API access and faster code – hyperloop ?

    • @Mik Oakley
      Ti.Next is a name used to denote the “next evolution or phase in the Titanium life”, rather than a single thing.
      Current State of things (simplified for general audience);
      – Alloy sits above Titanium (for those who choose to use it)
      – Titanium is where you code (or the results of the Alloy code goes)
      – The SDK takes your Titanium code and converts it map-able code using the target platform SDK
      – Target Platform SDK compiles the code ready to live map the code on the device to native objects and more specifically “hyperloop” is the replacement for the last two entries above.
      Currently there is a limitation of time, each target native platform SDK requires its own version of a compiler, so one for iOS another for Android, Blackberry and so on. This means each platform takes time to essentially end up with the same thing.
      Hyperloop is how this will change. Hyperloop manages to bypass xcode, java and so on by managing to map the native commands through an intelligent wrapper level (too complicated to explain in here). But this means that hyperloop uses JavaScript to bridge Titanium code with Native code – without having to go through another SDK.
      This has numerous advantages – this is a couple; only having to support one hyperloop engine rather than once for each native platform. Not being limited to the things currently exposed through Titanium wrappers, for example Android has more than one switch, Titanium supports one; now you can choose to use the others.
      Now this is the VERY important part; Titanium stays the same, same APIs, same methods, same everything (allowing for obvious evolutions). The next important part – IF you CHOOSE to delve into some native things that are platform specific – you CAN.
      If you choose not to – no problem, your experience of coding for Titanium will be the same – the only big difference you will see will be the performance enhancements to your app as the new way – should be faster – often MUCH MUCH faster.
      So in short, if you choose to ignore the benefits of the lowest level of the new hyperloop compiler (something you have never been able to access before) then you can – be happy in the knowledge that you can code the same today as you did yesterday and as you can tomorrow. But know that you will be able to “play” or delve deep if you choose too.
      I hope this clears things up a bit.

  3. Very nice!
    A few things:
    – It wont make a cross platform app faster? i dont really see how. The base SDK of Titanium Mobile is already fully native. Plus when your use Titanium mobile SDK you would still need to use jni, wrappers… to access native code? Consequently if i take my current TiMobile app, i dont really see how hyperloop makes it faster.
    – Are you really gonna port the whole SDK to hyperloop? That really scares me! If you do so the Ti Mobile SDK wont be a native sdk anymore. It will be generated on compilation. This might not have any importance for people using the SDK. But for people developing the SDK itself, this is a major drawback :s Or maybe ( i hope) i did not understand it right.
    Great job!

    • Martin, why not faster?
      Even though the SDK is written in native code, the bridging is still a huge bottleneck for stuff like realtime animation, rendering etc.
      Im also a bit scared of all my modules, but I “hope” appcelerator will address some sort of mapping between hyperloop and Ti.Now modules as we know them today.
      I see hyperloop as a great feature. Think of all the C libraries you can tap directly into, and create one cross platform module using the sinlge C library. Thats something we have never been able to do before.
      Finally, I hope Appcelerator will eventually be able to focus on innovation, rather than bugfixes. Its clear to anyone, that this cross platform proxy to native, is super hard to maintain bugfree. Lets hope Hyperloop is much easier, and hence new functionality will arise faster.
      // Mads

  4. this seems like interesting progress, especially from the point of view of game developers.
    one thing though- the name… Elon Musk might get a little annoyed that Appcelerator copied the name of his badass ultra high speed tube transport system thingy.

  5. This is great news, first for the speed improvement which is something that has been an issue with Titanium especially on Android. But I think the main thing is the access to the native layer directly from JavaScript thru Hyperloop, this is the only thing that has kept me interested in Xamarin (competing cross-platform solution in C#). I hope you all understand that you will get instant access to a new API as soon as you have upgraded your phone OS, no need to wait for Appcelerator to update the SDK. This is a big win. Look at the github repo and you will see an example of iBeacon functionality. This is not possible in Titanium today, if you don’t write a native module. Now you can write all your code in one common environment and package it as modules to abstract API between different platforms. This is how Appcelerator will build the current Titanium API on top of Hyperloop.

  6. What I didn’t like about Xamarin, if I’m not mistaken is that the GUI and part of the code has to be duplicated for each platform. I like how Titanium shares the same UI and code across platforms. With the advent of hyperloop will Titanium then require separate code for separate platforms, or will we still be able to choose to not use Hyperloop, and continue with the existing API?

    • @Anthony When HyperLoop arrives, there will be (almost *) NO difference to you or your code at all. You may continue to use all the APIs as you have before and everything will remain as a single core as it does now. You will not have to separate things out for different languages.
      HyperLoop will work behind the scenes doing things you do not need to worry about.
      If you choose to take additional advantages of the of HyperLoop then you can – this will allow you to talk directly to the underlying target platform. By this I mean you can use truly native features of iOS by using the iOS native APIs but using the HyperLoop and JavaScript syntax. You would do this for each language if you need.
      This means that you would be able to add things not currently available or access extra properties not yet exposed – or get to brand new APIs that would have taken time to become available.
      But again – if you choose not to take the extra advantages then you do not have to – everything will remain as it is – but with behind the scenes improvements.
      * Some Ti APIs may need to be tweaked to allow the HyperLoop solution to work – these are not expected to be many and any tweaks from your side are expected to be minimal – and fully documented.

      • The very bad thing I feel about Xamarin is separate code base for different platform.
        Titanium gives the best cross platform solution with native user experience. is really very good which gives us everything at one place.
        I would like to try hyperloop now, but I don’t know how / where to start. I agree there are example apps on github but it would be good if I have a good documentation on how to use it properly. Is there anything like that?


Please enter your comment!
Please enter your name here