The Titanium Mobile API written in JS

[mattapperson]

Issue #1 outlines the desire to expose all native APIs to JS. If we were to use that ability to write the entire Ti API set, then the community of JS developers could more easily contribute. Right now if there is an issue on the "native" side of things, there is no way for a JS dev to fix it.

[yuchi]

I feel the urge to explicit that it’s not related solely to the UI side of Titanium.

[cb1kenobi]

We originally talked about building all APIs on top of a low-level native-to-JS API, but I felt that was a bad idea. All you're doing is taking what we have today in Obj-C/Java/C#/etc and rewriting it in Hyperloop's not-quite-pure JavaScript syntax. Now we need to be experts in both JavaScript and Obj-C/Java/C#/etc.

I was also concerned about the burden on the JavaScript engine running so much JS code. Large amounts of JS code takes time to load, parse, and execute and eats up lots of memory. Crafting extremely efficient JS is not easy and probably not very readable.

I felt it was far better to build a highly portable library in pure C++. At the heart of this library is HAL/JavaScriptCore and a plugin system. Then create native C++ plugins for filesystem, networking, database, xml parsing, buffers, streams, debugging, crypto, zlib, and module support.

Each platform (Android, iOS, WIndows) could have specific plugin interfaces for Obj-C/Java/C#/etc modules. Module authors have their choice of writing modules in C++, JavaScript, or whatever the native platform's language is.

With this in place, we could build all other APIs in a platform specific plugins (UI, calendar, gestures, accelerometer, contacts, etc) or in cross platform JS plugins (analytics, facebook, arrow).

[TheBrousse]

Maybe I'm reading this wrong, but having to code each API plugins using C++ would have the same problems that we have with Kroll right now. By that I mean that in order to access every property and member, they would have to be implemented in HAL.

Thoughts?

On 10 Apr 2015, at 08:48, Chris Barber notifications@github.com wrote:

We originally talked about building all APIs on top of a low-level native-to-JS API, but I felt that was a bad idea. All you're doing is taking what we have today in Obj-C/Java/C#/etc and rewriting it in Hyperloop's not-quite-pure JavaScript syntax. Now we need to be experts in both JavaScript and Obj-C/Java/C#/etc.

I was also concerned about the burden on the JavaScript engine running so much JS code. Large amounts of JS code takes time to load, parse, and execute and eats up lots of memory. Crafting extremely efficient JS is not easy and probably not very readable.

I felt it was far better to build a highly portable library in pure C++. At the heart of this library is HAL/JavaScriptCore and a plugin system. Then create native C++ plugins for filesystem, networking, database, xml parsing, buffers, streams, debugging, crypto, zlib, and module support.

Each platform (Android, iOS, WIndows) could have specific plugin interfaces for Obj-C/Java/C#/etc modules. Module authors have their choice of writing modules in C++, JavaScript, or whatever the native platform's language is.

With this in place, we could build all other APIs in a platform specific plugins (UI, calendar, gestures, accelerometer, contacts, etc) or in cross platform JS plugins (analytics, facebook, arrow).

—
Reply to this email directly or view it on GitHub.

[cb1kenobi]

@TheBrousse So what are the problems we're having with Kroll right now? What's the bottleneck? The JS-to-native bridge? Don't think so. HAL proves the JS-to-native bridge to be pretty snappy. I believe the major issue with Kroll is the thread synchronization between the UI thread and the JS thread. Because you have object state in both native land proxies and in the JavaScript engine, you have to do all sorts of crazy synchronization locks and this KILLS performance.

HAL reduces this complexity. With HAL/JavaScriptCore running on a background thread, then we can create a lock-free queue and pass messages between the threads. This drastically speeds things up while keeping the architecture flexible, modular, and loosely coupled.

[TheBrousse]

The main problem with Kroll right now is not so much that it is a bottleneck. The real issue here is that there is no true 1 to 1 mapping between methods and properties of the native objects. Which means that every time a new property is made available from the native API. It must be implemented in "the layer".

You see this from a pure engineering pout of view (performance, threads, etc.). But what I am talking here is to bring everything that is currently in native to the JS front.

On 10 Apr 2015, at 09:18, Chris Barber notifications@github.com wrote:

@TheBrousse So what are the problems we're having with Kroll right now? What's the bottleneck? The JS-to-native bridge? Don't think so. HAL proves the JS-to-native bridge to be pretty snappy. I believe the major issue with Kroll is the thread synchronization between the UI thread and the JS thread. Because you have object state in both native land proxies and in the JavaScript engine, you have to do all sorts of crazy synchronization locks and this KILLS performance.

HAL reduces this complexity. With HAL/JavaScriptCore running on a background thread, then we can create a lock-free queue and pass messages between the threads. This drastically speeds things up while keeping the architecture flexible, modular, and loosely coupled.

—
Reply to this email directly or view it on GitHub.

[mattapperson]

I think nativescript has proven that this (direct exposure of all native APIs to JS) can in fact be done without overloading the js vm and without creating ugly/un-maintainable js code

[mattapperson]

https://github.com/NativeScript/cross-platform-modules?files=1

[mattapperson]

For the record I am not an advocate of typescript. Flow could be used for a similar effect with no need to learn a new language

[mattapperson]

@cb1kenobi Thank you SO MUCH for this information, hearing what has been going on with HAL and Hyperloop delays behind the scenes all this time is extremely helpful!
I am curious on your thoughts with regards to how/why NativeScript was able to do this (even if overall nativescript is not "there" yet).

@TheBrousse I would argue that it is both. As is on iOS parallax scrolling without a native module is next to impossible due to bridge delays

I would also argue that one of the biggest reasons for the almost non-existant community support of the Ti.Current SDK thus far is that you have a community of JS devs, and a native core. So the only recourse for a JS dev when there is an issue is to file a ticket and make a bunch of noise to hope Appc fixes it quickly.
With a JS SDK JS devs can help fix and improve the core more easily.
And to your point @cb1kenobi that Hyperloop's not-quite-pure JavaScript syntax. Now we need to be experts in both JavaScript and Obj-C/Java/C#/etc. I think this could be improved, again ala NativeScript's module syntax to where this would be far less of an issue.

[cb1kenobi]

The 1:1 native mappings is nothing more than a compile-time optimization and a runtime reflection. I'm skeptical about the runtime performance of reflection in Java and C# as well as exposing all that to the JS engine. Exposing a million classes, functions, and constants to the JS engine makes for a crazy amount of scope resolution.

I'm a JavaScript purist, so I'd prefer ES6 over Typescript. You're still going to need to know native paradigms and how to use them in Hyperloop. I built the Windows Hybrid platform which is basically Titanium Mobile Web in a native web view and it uses reflection. The API isn't as good as Hyperloop, but it does show how challenging it is to work with from JavaScript. Check out some examples here: https://wiki.appcelerator.org/display/guides2/Windows+Phone+8+Module+Development+Guide.

[mattapperson]

Have you looked at how nativescript does this? It's rather simplistically brilliant

[mattapperson]

Also. I 100% agree on js purest.

[mattapperson]

@cb1kenobi can you explain your thoughts about "Exposing a million classes, functions, and constants to the JS engine makes for a crazy amount of scope resolution." a little more. This to me only seems like it would be an issue if you require every API into global scope