Suggestion: Consolidate on Chakacore

[NathanaelA]

One thing that might slow down development is by using two different JS engines -- since you already have all the work done on mobilizing Chakacore; can you potentially move it over to Android.

I think that even if it is not using JIT, the ability for you to standardise on one JS platform and fix issues in one platform will help accelerate the development and adoption of this solution.

[mohlsen]

This is one of the reasons the JXCore project used SpiderMonkey on both iOS and Android platforms. They could have used SpiderMonkey on iOS and V8 on Android, but opted for the same JS engine.

That being said, the shortest putt was almost certainly to get Node/V8 running on Android. I am guessing thats why Janea opted for this path. If node-chakracore ever gets merged into mainline node, than I think this argument makes even more sense.

[orangemocha]

Hi @NathanaelA . You make a valid point. Standardizing on ChakraCore would mean less maintenance cost in the long run and also provide a more consistent user experience (even though ChakraCore compatibility with v8 is only getting better).

For those reasons, we certainly would like to have ChakraCore on Android in the future. But I imagine that even when we do, some people might still prefer to use v8 on Android. So unless the burden proves too much, ideally we will give developers that choice and support both.

The reason why we started with v8 is because it was low-hanging fruit, and it allowed us to unblock the delivery of the project much sooner. My guess is that porting ChakraCore to Android ARM64 will be comparable to the amount of work that was needed to port it to iOS ARM64, which was not trivial. And that's just for the interpreter mode, the JIT might be an order of magnitude more difficult.

[NathanaelA]

Oh, I understand the reasons you did it. I can't fault you at all for that. ;-)

I'm a huge user of NativeScript; but one of the issues that slows down development on NativeScript is they also choose to use two engines (same reason, JIT vs no JIT). The problem is you get different bugs on different platforms, which really kills you when you get your app working perfectly on one platform move it to the other and it starts crashing or doing weird things. Then they have to two separate teams, one for iOS and one for Android; and each team has to deal with different engine upgrade issues. In addition they have to maintain two separate debugging solutions, which has different feature sets. So not only does this effect the end user (i.e. me as a consumer); but then anyone who wants to help with the project (i.e. me as a committer) has TWO separate large code based to work on or they will just decide to do one of the two and so then you get people wanting to add features, and your feature parity goes out the window. ;-)

I do love what you did here; I've been digging into the source to make a NativeScript plugin for it; but I can see the same thing occur where now it takes a lot more effort to do any extra features to the product.

Having both v8 and Chaka on paper seems really really nice, but the long term hit for productivity is going to be a killer, imho. Sometimes less is more, in this case reducing the engines supported, I think is something that would be worth the time to do...

[obastemur]

@orangemocha didn't check in details but how someone may use nodejs with ChakraCore on Android?

[orangemocha]

@obastemur at the moment it's not possible. We haven't ported ChakraCore to Android yet.

[rhuanjl]

Saw this issue and thought it was worth linking this (currently open PR to add android support to CC): chakra-core/ChakraCore#4452

(note I'm not involved in this just thought this topic may benefit from a link to that PR)