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

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.

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.

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.

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

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

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

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

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)

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.