• Fork me on GitHub

A path off JXcore?

Some choices have appeared that might, someday, get Thali onto Node.js v5+ on Android and iOS.

TL;DR – There is an effort from Mozilla to get Node running on Spidermonkey and the Node.js community is mumbling about making Android an officially supported platform. The first effort isn’t looking at Android and neither effort is looking at iOS and even if we get Node.js v5 on Android and iOS there is work on top of that which Thali needs. But still, paths are opening up.

Long Winded Version

While we still hope to get JXcore stabilized I don’t think anyone has a plan to take it forward. Which is going to become more and more of a problem. For example, PouchDB has decided to stop even testing on Node 0.10 (the version of Node.js that JXcore is mostly based on). They’ll take bug fixes for it and aren’t looking to break compatibility but they have had enough weird transient issues with Travis and Node 0.10 that they decided to stop looking. This is just the start of the inevitable march away from Node 0.10. So we really need alternatives.

And alternatives are starting to show up in a very (VERY) nascent form. One particularly interesting alternative is https://github.com/mozilla/spidernode. This is run by the Mozilla folks and is explicitly using the work Microsoft did on Node.ch but instead of putting Chakra under node, they are putting Spider Monkey. This is really compelling for us because Spider Monkey works on both Android and iOS. The good news is that the Node.js community seems to be welcoming it, https://github.com/nodejs/vm/issues/2. The bad news is that there appears to literally be one person working on it and they have a lot of work ahead of them. The worst news is that this isn’t focused on running on Android or iOS as far as I can tell. It is just focused on getting SpiderMonkey running on Node on the existing Node.js platforms.

The node.js community has also been mumbling about making Android an officially supported platform for Node - https://github.com/nodejs/build/issues/359. That is useful in that it would cover Android but it wouldn’t help us with iOS, especially since that effort would use V8 which apparently won’t run on iOS. Google has clearly stated (https://bugs.chromium.org/p/v8/issues/detail?id=1312) that it is not interested in v8 on iOS. Although https://github.com/frida/v8 claim that they run on iOS but I haven’t tested it at all. Note however that Frida seems to be running on v8 4.5.103.30 where as Node.js v5 is on 4.6.85.25. So it’s not like we could just drop Frida in even if it works and since I’m guessing they aren’t using JIT who knows what their perf is like? So even if Android becomes an official platform we would still need to figure out if the Frida effort is for real and then deal with the issues to get Node.js using Frida on iOS.

So there are at least two potential paths to get Node.js v5+ on both Android and iOS. But both are early, incomplete and not intended to get us all the way there.

But wait, there’s more! Even if we manage to get Node.js v5+ running on Android and iOS there is more work that Thali needs. Specifically:

  • Native API – We have native code that needs to be able to speak directly to Node.js. Node obviously has standard interfaces for this but they are targeted at C. We need to support Java on Android and Objective-C on iOS. The later should be straight forward and the former is well understood. So this is just work but some shimming will be necessary.
  • Virtual File System – On Android, JXcore keeps node_modules in the APK (think: zip file) but node thinks they are on the file system. This required creating a virtual file system to fool node into seeing the APK as a proper file system. We would need to replicate that. Otherwise when the app loads for the first time it would have to unzip all the node_modules (megs of them) and copy them to local storage. This would, however, only be necessary once. But it’s still bad. So we really need the virtual file system.
  • Mobile APIs – JXcore has a light set of APIs that provide important functionality on mobile platforms like telling us where we can store files and handling things like turning on/off radios. This should be fairly easy to replicate though.
  • Cordova Support – Being a Cordova plugin makes life much easier for everybody so we really want to keep this feature. We actually don’t need anything particularly fancy here. We could use some kind of bridge between Cordova and Node but it can be slow and stupid. The only thing we ever need to move is the port that the node process is listening on along with some security config data. Beyond that we do everything over localhost.
  • LevelDown – We depend on LevelDown as the back end for PouchDB. It’s not clear if the APIs being implemented by these various efforts support everything we need for LevelDown. I honestly haven’t had time to do any investigation here but we would need to make sure it works. The good news is that we know the core LevelDown engine runs on both Android and iOS since we use it today via leveldown-mobile.
  • PSK – The most important feature that we had added to JXcore (at least that I can remember, did I miss something?) was PSK support. This stands for ‘pre-shared keys’ and is a TLS mode our discovery infrastructure depends upon. For a variety of reasons this can only work if it is directly integrated into Node.js. This isn’t much work. It was actually tried previously (https://github.com/nodejs/node/issues/3553) and nobody objected to adding it to Node.js, it just seems that the person working on it sort of wandered away. But we have experience adding it to Node.js 0.10, including tests, so it shouldn’t be too hard to update that code to Node.js v5+.

What is exciting (seriously) about the above work items is that they could all be done as commits directly to (and around) Node.js and would ‘just work’ with either the official Android port (if it happens) or the SpiderMonkey work. So we do not have to pick a winner. We can just bet on node.

So the road is long but it’s not impossible. In the meantime, we still need to find a way to keep JXcore up and running in its current state on new releases of Android and iOS and fixing bugs we find.

Subscribe to Atom Feed