New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Consolidate on Chakacore #8

Open
NathanaelA opened this Issue Oct 5, 2017 · 6 comments

Comments

Projects
None yet
5 participants
@NathanaelA

NathanaelA commented Oct 5, 2017

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 comment has been minimized.

Show comment
Hide comment
@mohlsen

mohlsen Oct 5, 2017

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.

mohlsen commented Oct 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@orangemocha

orangemocha Oct 5, 2017

Member

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.

Member

orangemocha commented Oct 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@NathanaelA

NathanaelA Oct 5, 2017

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...

NathanaelA commented Oct 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@obastemur

obastemur Oct 18, 2017

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

obastemur commented Oct 18, 2017

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

@orangemocha

This comment has been minimized.

Show comment
Hide comment
@orangemocha

orangemocha Oct 18, 2017

Member

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

Member

orangemocha commented Oct 18, 2017

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

@rhuanjl

This comment has been minimized.

Show comment
Hide comment
@rhuanjl

rhuanjl Jan 25, 2018

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

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

rhuanjl commented Jan 25, 2018

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment