Should Node.js be VM neutral in the future?

[mikeal]

First and foremost, a bit of a reality check: The "Node.js Platform" is already available on a variety of VMs other than the V8 runtime we ship with:

• Compile-to systems like the early Tessel project and now Samsung's JerryScript/IoT.js.
• Microsoft ships a Node.js on top of Chakra for XBOX, Windows Phone and Windows 10 IoT.
• Nodyn is a Node.js API on top of the JVM.
• JXCore is an "extended Node.js API" that can bind to Spidermonkey, V8 and Chakra.

Because of Node.js' massive ecosystem of packages, educational materials, and mind-share we should expect that in the future this will continue. Part of Node.js going everywhere is that it may need to be on other VMs in environments V8 can't go. There's not much that we can do to prevent this.

So the question becomes: Should Node.js Core move towards being VM neutral and supporting more VMs in the main project?

Some of the advantages would be:

• Normalization of the Native API (which currently breaks every major release)
• De-facto standard for any JS VM to add Node.js support.
• Centralization of test infrastructure would increase stability of non-V8 platforms.
• Standardization of API could allow us to adopt new V8 versions outside of breaking major releases.

There's a long discussion about how to do this. Without guarantees from all the target VM vendors that they will support this neutral API it could fall on us to make that work. Historically V8 has made drastic API changes that were not supportable through the API nan had implemented.

There's also an open question about how to structure the tree and build and if we should continue sticking V8 and every supported VM in a vendor directory or pulling it in during build time.

Anyway, let's have the discussion :)

@nodejs/ctc

[Fishrock123]

Also, some increased competition in this area will likely push for performance improvements in VMs I think, which would be really good for us.

[misterdjules]

JXcore is an "extended Node.js API" on top of the JVM.

I didn't know JXcore had anything to do with the JVM. Where can I find more details about this?

[MadaraUchiha]

How do we handle the compatibility issues? Speaking from a package maintainer's perspective. Worst case scenario: This will be the cross-browser hell all over again (albeit on a smaller scale because no DOM)

[brycebaril]

I'm very much in favor of this. My hope is that the WebAssembly story is a big part of this. It would be fantastic to have this on a roadmap in a way that allows Node.js to become part of the WebAssembly discussions, as this is already an area with some potential roadmap to the shared-VM discussion where the major VM vendors are already working on common APIs.

[RReverser]

JXcore is an "extended Node.js API" on top of the JVM.

Correct me if I'm wrong, but JXCore is not based on JVM AFAIK. It just provides extended Node.js API on top of one of any chosen JavaScript engine among supported (all of V8, SpiderMonkey and Chakra are supported).

[mikeal]

@misterdjules @RReverser you're right, my bad, I was confusing Nodyn with JXCore. Updated the description.

[RReverser]

@mikeal Nice. Although I see that you removed JXCore completely, while I believe it does belong to the list and discussion, as it also adds couple of supported non-V8 engines.

[mikeal]

@MadaraUchiha So, the native module ecosystem currently binds directly to V8 (often through nan which abstracts the V8 API). We suffer a break in compatibility every time we take a new version of V8 because of that, so moving towards a neutral (stable) API might actually improve compatibility beyond what we currently have.

[indutny]

I don't think that it will create more competition than there is for browsers, but it is surely a good thing in my opinion.

There are lots of obstacles on this way though: addon compatibility, ES6 features, etc

[mikeal]

@RReverser it's back now :)

[rdodev]

Sounds like a good idea to make node VM agnostic. My question would be: is there a difference in terms of effort, speed to fix 0-day vulns, maintenance if node is V8-centric or not?

[ELLIOTTCABLE]

Not on any of the teams, or really important in any way, but I wanted to kind of re-phrase simplistically what I think the majority view of this is going to be:

1. This is almost incontrovertibly Good for The Community. Good for users. A good thing.
2. This is a lot of work. Work that could, theoretically, be invested elsewhere.

Unless I'm super-off-base there, then, I'd assume that this conversation needs to directly assault “whether that amount of work being spent on this effort is proportional to the benefits to users.”

(Sorry if this seems obvious! I just didn't see it laid out in so many words above.)

[MadaraUchiha]

@mikeal Wouldn't this mean that this abstracted API would have to always be the lowest common denominator in terms of newest ES features etc? Otherwise, you're risking syntax and APIs working in one build, but breaking on another.

Another option is to put newest features behind a flag, but that's kind of meh, and we've been trying to (at least I think) avoid that going forward.