Purpose of the project?

[artemyarulin]

Hi there!

Guys, what is the purpose of this project? I came across your repository when I started implementation of XmlHTTPRequest for JavaScriptFramework and I found that you have a set of interesting modules for that already. I'm trying to gather most of the browser object model staff in my library JSCoreBom so I guess I'll "steal" the way how you organized things :)

In any case - thanks for sharing knowledge, JSCore doesn't have a lot of attention in GitHub.

[sergeyzenchenko]

Hey Artem. In this project we've tried to implement application logic using JavaScriptCore framework. We were going to use it for business logic, networking, simple storage. So we can share it between ios, android and web. But we had no time to finish it :(

[sergeyzenchenko]

We would like to keep working in this direction. So feel free to steal anything :) If you have some interesting ideas about these tools usage we can discuss it.

[artemyarulin]

Hi @sergeyzenchenko, thanks for answer!

This concept looks exactly what I'm doing right now - I have a native application for iOS but recently I decided to make it cross platform and migrate all the business logic to JS.

But how do you like JavaScriptCore? Any stability, performance issues with this?

I'm just at the beginning of the way, but so far everything looks nice. Using gulp,mocha,rx.js for implementing logic for iOS application - just blows my mind :)

[sergeyzenchenko]

The main problem here is how to build right abstraction for interaction between native code and JS. We've tried MVVM approach. ViewModel+Model is implemented in JS and Views are native. But had no time to finish it :(

[artemyarulin]

Yeah, how to organize things is for sure quite challenging.

In my case I decided to make all the communication between UI layer and JS code though HTTP request (here some ideas about that Kaare project).

It will hit performance quite hard in some cases, so I'm not sure how it will be at the end. But the thing with HTTP server that this abstraction layer would allow me migrate my native code to JS gradually and UI layer would know nothing about how business logic is implemented - is it native, JS or even remote service.

Let's see how it goes

[sergeyzenchenko]

I am not sure that HTTP is right solution here. I think simple event bus will work better. Or for example you can try to bypass ReactiveCocoa#Signals or Promises between JS and native code. Both of them are good abstraction above some abstract calculations/event.

[sergeyzenchenko]

I thought about code generation phase. During this phase special script should generate native bridge for each view model based on ViewModel specification from JS.

[artemyarulin]

Hi again. I've been thinking about HTTP server and other solutions of communication between native and JS code for couple of nights days. At the end I came to conclusion that you was right - HTTP server is overkill.

Nowadays when everything goes reactive the communication layer should be able to handle data workflow from native code to JS and vise versa in a reactive way.

On a lower level API would look like: signal = [Kaare executeCommand:cmd params:paramArray], where:

• signal - Platform Observer (RACSignal for iOS, Rx.Observalbe for JS, etc.)
• cmd - Function to call on other platform which returns signal as well

So at the end this function will handle conversion of reactive signals from one platform to another. For example:

JavaScriptCore: Objective-C to JavaScript: RACSignal* op = [Kaare executeCommand:@"getTweetsStream" params:@[@"username"]];

JavaScriptCore: JavaScript to Objective-C: var rxObservableOp = Kaare.executeCommand('getTweetsStream',['username'])

Android.webkit.WebView : JavaScript to Java Observable<Tweet> RxJavaObservableOp = Kaare.executeCommand('getTweetStream',['username'])

I've already implemented some prototype to check performance, and so far everything looks OK (1ms for native to natvie vs 2ms native to JS). For communication between UIWebView and native code Cordova way would be used (webView.shouldStartLoadWithRequest/ DOM events).

ExecuteCommand is a low level API and on a second stage it could be useful to use code generation tools to create native wrappers like -(RacSignal)getTweetStream:(NSString*)username

So, how do you like this concept? It would appreciate if you share your opinion about the concept, thanks.

[sergeyzenchenko]

This is exactly that we were working on :) Same architecture with code generation and signals. it was like:

JSViewModel <-(JS Signals)> CodeGeneratedNativeBridgeToThisViewModel <-(Native Signals)> NativeUI

But why do you need webView.shouldStartLoadWithRequest ? You can call native code directly from JS.

[sergeyzenchenko]

Why do you think about working on this tool together?. I don't have a lot of time right now, but I will be able to help you with advice and review and join coding later.

[sergeyzenchenko]

Actually I think we haven't committed all code into this github repo and we had bindings between RAC signals and RxJx. I will check it.

[artemyarulin]

Regarding shouldStartLoadWithRequest - Is it so that you can call native code from WebView on every platform? I mean on iOS we have JavaScriptCore which allows us to call native code from JS easily, but what about Android, WinPhone? Cordova decided to use webView.shouldStartLoadWithRequest because this way is supported on every platforms.

Regarding working together - sure thing! First I am going to create a document that describes the concept in more details (so that I structure the whole thing in my head as well) and then yeah - let's implement it.

[artemyarulin]

Yeah, it would be cool if you checkin all your prototypes - it could help me at the beginning.

[sergeyzenchenko]

On Android we can use RhinoJS or some other JVM JS engines. Not sure about WinPhone. Who cares about winphone?) Nobody is using it :D

[sergeyzenchenko]

And starting from Android JELLY_BEAN webview can call native methods

[sergeyzenchenko]

Cordova is really bad example. They have shitty code. PhoneGap is real crap :D

[artemyarulin]

Well, I've seen one guy with WinPhone, so they exists at least :) About Android - that is awesome, cool.

But I want also support the case when UI is actually implemented in HTML (for some static pages the performance is not that important and ability to write it once and use on every platform is nice). In this case it would be cool to use the same communication channel to call business logic to get the data to the page.

[sergeyzenchenko]

Have you seen http://calatrava.github.io ?

[sergeyzenchenko]

The code is crap, but they have same idea. Part of UI is native and part is HTML based.

[sergeyzenchenko]

Right now I am using ViewModel approach with React and it works really well. I think we can use React for html part in this project. It fits well and it's super fast which is especially important for mobile apps.

[artemyarulin]

/me checking source code of calatrava...

Yeah, I'm also thinking about React for UI.

But let's make it simple at first - let's build communication layer between native code and JS which will handle all signal conversion. It would be cool to have it stable and working and then we can decide how we can proceed, think about ViewModel and so on.

[sergeyzenchenko]

yeah sure. It's was just a thought about possible solutions.

[sergeyzenchenko]

@artemyarulin https://github.com/svaarala/duktape

[artemyarulin]

@sergeyzenchenko Looks awesome, looks like we are moving in the right direction.

Can you have a look on an example of Kaare usage? How do you like API?

Most of the things works already, I created new transport abstraction which will allow us to support different JS contexts and engines (like duktape in a feature) while maintaining the same API.

At the same time I described in readme that Kaare can be easily extended with new functions. Think of it like Cordova/PhoneGap plugin system.

And one last thing which I really like - I added description of a remote transport which will allow writing integrations tests using mocha.