[elisee]

"This temporary fork enables Node.js to optionally use the Chakra JavaScript engine on Windows 10, allowing Node.js to run on Windows on ARM." (the submission title has been updated after I posted this, was initially "MS releases a fork of Node that uses the Chakra JavaScript engine instead of V8")

Looks like they intend to merge back with node mainline... ?

EDIT: Found this: http://blogs.windows.com/buildingapps/2015/05/12/bringing-no...

They're doing this to be able to run Node.js apps on Windows 10 ARM (on which V8 supposedly doesn't run?)

"We will be submitting a pull request to Node.js after stabilizing this code, fixing key gaps and responding to early community feedback."

"Going forward, we plan to work closely with the Node Foundation, the Node.js Technical Committee(s), IO.js contributors and the community to discuss and participate in conversations around creating JavaScript engine agnostic hosting APIs for Node.js, which provide developers a choice of JavaScript engine that they would want to use in their Node.js workflow"

Looks like the pull request will consist mostly of exposing new hooks to integrate with Chakra / other JS engines and won't involve pulling any Chakra code into Node.js (which would be unlikely to be merged). Might lead to a SpiderMonkey version of Node.js at some point, too. Nice to see IO.js mentioned. Looks like a very positive initiative (assuming it doesn't complicate Node core too much)

[zpao]

> Might lead to a SpiderMonkey version of Node.js at some point, too.

I worked on that 4 years ago :) <http://zpao.com/posts/about-that-hybrid-v8monkey-engine/>. The Node community at the time wasn't a huge fan, though it's effectively the same thing that MS just did (build a minimal V8 API shim on top of another JS engine). I guess everybody is ok with a little fragmentation now. Our intention was also to try to get this upstreamed, however with low interest and other things to do, we didn't follow through.

I'm excited to see this, and especially to have the MS folks involved with the TC. I'd love to see an engine-agnostic API but realistically I don't think it'll happen, at least not anytime soon. Right now Node itself definitely relies pretty heavily on the V8 APIs. Those APIs can be abstracted for the most part (even if each engine is just shimming those parts of the V8 API) but the other problem is the longer tail of binary npm modules. Right now they have the full V8 API to work with. If they do a shim layer then it will come at cost for every vendor except V8. And then maintaining that layer as V8 changes APIs. If you go the engine-agnostic API route, then you will need coordination between engine vendors. That opens the doors to a multitude of problems.

[Twirrim]

Also that's going to potentially add a ton of work for people developing libraries. With a single engine behind it, the coding efforts can be focussed on writing and profiling something to be fast on v8. If you get replaceable engines, now developers have to either: 1) Ignore all but V8 (or spidermonkey, or chakra etc.) 2) Create different versions of their libraries for different engines. ( 3ish) write multiple paths in their code depending on the target engine)

I'm not sure exactly where I sit on this one. In many regards I think I like it, allowing developers to use the right engine for the right job, for example. Each engine has its own strengths and it may be that v8 isn't the engine for you / your workload. It's just this could hurt as much as it helps.

[bsimpson]

Using @zpao's example, most Python developers use CPython and either don't know about PyPy or have never used it. As such, I'd expect most of the long-tail of Python libraries to have been written and tested against CPython.

That hasn't prevented PyPy, IronPython, JPython, etc. from existing/thriving.

[angersock]

Having a decent shim to code against instead of having to deal with the internal gooiness of different JS engines is actually very much preferred. By throwing a shim over the JS execution layer, they actually make the life of extension developers much easier.

[magicalist]

> They're doing this to be able to run Node.js apps on Windows 10 ARM (on which V8 supposedly doesn't run?)

V8 definitely has an ARM runtime, so maybe this is a result of the restrictions on what's allowed to run on the platform? (e.g. iOS and Windows Phone don't allow JIT compilers except the ones provided by the platform itself)

[gsnedders]

I'd guess, at the very least, that it doesn't support the Win/ARM ABI.

[magicalist]

The issue is really what has been eliminated from the API. This is one of the ways they prevent you from generating your own executable code. See, e.g. this (closed) V8 bug for adding Windows Phone support: https://code.google.com/p/v8/issues/detail?id=2427

[gsnedders]

Right, this is true for WP and WinRT; it's not clear that the same is true for the IoT Win10/ARM builds?

[themgt]

I wonder how difficult it will be to manage pull requests for merging against node.js & io.js simultaneously - also, creates an interesting political situation if one project accepts the PR but the other doesn't (I would guess io.js will be more eager to do a release against the new code)

[silverwind]

The question is why should node/io.js take such a pull request. It adds support for an irrelevant platform and would add the burden of maintaining the 'wrapper' which will probably break on every v8 update.

[rlidwka]

If it adds an engine abstraction layer which would allow users to choose an engine (and somebody implements SpiderMonkey support there), sure why not.

Though this is a job that is already done by JXCore.