JS runtime access to 100% of all native APIs, including any 3rd party SDKs added

[mattapperson]

In my mind, this is the best power feature we could get as a JS community.

I am still digging into HAL and Hyperloop, but it looks like this could be done fairly easily with the existing codebase.

[yuchi]

Slightly related iojs discussion: nodejs/NG#3

[joshthecoder]

Yeah this would be great. It's one of the features that got me excited about NativeScript. Being able to access the native platform runtime w/o writing proxies or glue code would be powerful. Hyperloop looks to be a good start to getting this done.

[mattapperson]

@joshthecoder 2 levels to this, JS runtime and JS compiled (aka hyperloop). Both and and in my opinion should be done.
The issue with the way NativeScript does this is that it only allows this in compiled code and also it does not work with pre-compiled code. So if you have an SDK of compiled code... NativeScript cant use it (at least not yet).

[TheBrousse]

NS can do this already.
http://nuvious.com/Blog/2015/4/5/using-native-libraries-in-your-nativescript-apps?utm_content=bufferfd8da&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
Date: Tue, 7 Apr 2015 09:05:32 -0700
From: [email protected]
To: [email protected]
Subject: Re: [discuss] JS runtime access to 100% of all native APIs, including any 3rd party SDKs added (#1)

@joshthecoder 2 levels to this, JS runtime and JS compiled (aka hyperloop). Both and and in my opinion should be done.

The issue with the way NativeScript does this is that it only allows this in compiled code and also it does not work with pre-compiled code. So if you have an SDK of compiled code... NativeScript cant use it (at least not yet).

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

[iotashan]

NS can do this already

As long as you don't need to use a static library... which is not very useful.

[mattapperson]

@TheBrousse "If you don’t have the source code and the library is of a static type, then at this time you won’t be able to use it. But perhaps the NativeScript team will work on a way to get these types of libraries working in the future."

A LOT of native SDKs are static libs. So they work with OSS native libraries but thats it.

[mattapperson]

I also thing that when the metabase generator maps a native library/code it should generate some kind of docs. otherwise I could see this as being very frustrating for JS devs who dont know how to read Obj-C / Java / whatever. They wont know what the syntax of th JS api would be.
Poking it with a stick is not a good development UX. :)

[TheBrousse]

Well, if the code from the lib IS static, then I don't see why it couldn't be done. It could even generate other meta-data that can be leveraged by tools depending on the need. (auto-completion, etc.)

Date: Tue, 7 Apr 2015 09:23:21 -0700
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: [discuss] JS runtime access to 100% of all native APIs, including any 3rd party SDKs added (#1)

I also thing that when the metabase generator maps a native library/code it should generate some kind of docs. otherwise I could see this as being very frustrating for JS devs who dont know how to read Obj-C / Java / whatever. They wont know what the syntax of th JS api would be.

Poking it with a stick is not a good development UX. :)

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

[mattapperson]

@TheBrousse agreed

[jhaynie]

One approach I just prototyped that we're trying to flush out in a lot more detail here in the next few days uses ES6 generated JS files which have an internal "pointer" (not technically, just as a pattern) to the HAL native bound object. This can then be transpiled into ES5.

The goal for this would be to generate this "stub" in pure JS and also generate JSDoc, etc. You would the "require" / "import" this as normal in Titanium.

The approach has some nice advantages around readability of the API as a JS Dev, makes it easier to integrate into existing JS Editors and IDEs (which can already create stuff from JS AST), etc.

More to come on this as we flush this out a bit.

[mattapperson]

@jhaynie any updates on this? Would you consider developing that in the open to get community feedback? (100% understand if you can not / will not on that, i'm just curious)