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.

[rdodev]

My thoughts exactly @ELLIOTTCABLE . I think before node jumps on "let's do it because it's good" let's ask if they're accidentally overcommitting and a using time that could be better used improving aspects of node.

[inikulin]

If the aim is to bring node to new platforms (like Windows Phone) and benefit in speed (e.g. on Windows using Chakra) and keep everything under the hood without changing end-user API then it's the way to go. (e.g. node for Windows will use Chakra as default engine, for MacOs - V8, and so on). But if developers will start using language features available only in the particular engine it may cause significant fragmentation which is not a good thing.

[ELLIOTTCABLE]

(@rdodev To be clear, I'm not against it. I happen to personally think that the benefit at least slightly outweighs the effort required, despite the huge amount of effort. I'm just … trying to preclude arguments about whether or not it is beneficial in certain ways; or at least, I want to see such arguments prefixed by a big “No. I disagree. I definitely think this is not beneficial, in way” … to differentiate them from what are I expect are the far-more-salient “Yeah, but ” arguments. Making a meta-argument, if you will. :P)

[RReverser]

@rdodev Personally I see two ways of doing this: one is to provide API for external engines to use, and have separate core team + teams who maintain each separate engine's bindings. This is basically what we have now, but with proper API instead of V8's always-changing one + V8 bindings will live in separate repo just like any other implementations.

Second way is to have Node team to continue take care of V8 bindings officially as it does now in addition to neutral APIs for external consumers, and also of a list of approved engines (which will happen if nodejs/node#4675 is merged directly into Node). That case increases responsibilities and testing matrix of Node team a lot, so it will be harder to react to all possible 0-days in each possible engine in reasonable time IMO.

Personally I was very glad to use JXCore and see nodejs/node#4675 coming, but option 1 feels more preferable to me, as gives clear split of responsibilities between maintainers, and allows Node team to focus on what it always was good at - developing stable, safe and scalable core for server-side applications. In the meanwhile, people who worked on V8 part in Node will be able to continue that work in the new repo, and Microsoft will be able to work on their Chakra bindings, but without all the mess associated with merging core changes and fixing conflicts over and over as it was before.

[fivdi]

Samsung JerryScript is a JavaScript engine so perhaps Samsung IoT.js should have been mentioned together with JerryScript in the original post. Given that the IoT.js API is a subset of the Node.js API, the question as to what "The Node.js Platform" actually is needs to be answered as not everything that runs on Node.js will run on IoT.js.

[LPGhatguy]

I think that making Node.js VM-neutral would be beneficial purely on the front of dealing with V8 -- nan is helpful but not the end-all solution. Gaining compatibility with other VMs might be a secondary gain over improved API stability.

[RReverser]

@inikulin

But if developers will start using language features available only in the particular engine it may cause significant fragmentation which is not a good thing.

Note that it's exactly what already happens, even if we don't take into account all the engines in the description in first message. Even with just V8, we already have ES6 evolving, and there is growing number of modules that are being published untranspiled, targeting only latest versions of Node with native ES6 support, so you can't be sure that installed module will work on your Node, unless you keep it up-to-date or transpile everything incl. node_modules folder in your own app.

So this change won't bring anything new to that problem, but rather will push harder to finding a better, more generic solutions.

[rdodev]

@RReverser if it is a forgone conclusion that node is going VM-agnostic, then Option 1, sounds like the way to go, for sure.

[ELLIOTTCABLE]

“the question as to what "The Node.js Platform" actually is needs to be answered as not everything that runs on Node.js will run on IoT.js” is a really good point, but … I think one that's already answered?

Nothing above said we necessarily need to absorb every project that implements a subset of the current Node API. There can still be ‘pseudo-Nodes’ that aren't blessed, isn't that the case?

[RReverser]

@rdodev In that case I believe the answer to your question is easy as each team will be interested in fixing 0-days that are specific to their engine - whether it's a browser or server-side, doesn't matter that much.

[whitfin]

As an outsider I really can't think of a downside to doing this aside from workload and a bit of complexity in specifying the Node.js interface.

Different VMs will likely function better on different platforms, so it allows for developers (specifically hardware vendors as an example) to select an appropriate VM for the system they're on - obvious example being Chakra for the Windows-related systems.

I suppose you could argue that because the Node.js API would have to be common across all implementations, you might either have a) VM implementations with missing features, or b) a very slow adoption of things like new ES versions. That would need to be well thought out, but I don't expect it would be that difficult to figure out.

[ELLIOTTCABLE]

Another shot-from-a-distance, re @zackehh's point about slow adoption of new features: maybe this is okay / a good thing? Node.js is getting a little older; and I think a slower progression of new features is acceptable, perhaps even could be viewed as a positive thing (stability) at this point. (=

[inikulin]

Node.js is getting a little older; and I think a slower progression of new features is acceptable, perhaps even could be viewed as a positive thing (stability) at this point.

Wait a sec. AFAIK io.js fork was made to fight such state of things.

[mikeal]

@MadaraUchiha

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.

In reality almost everyone binds to nan today, which is abstract API support V8 versions back to v0.10. So most of the ecosystem is already on a "lowest common denominator" API.

Also, one of the current proposals is to use the current v8 as a starting point and do the work of making newer V8's shim to the old API.

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.

I think we'll end up doing this any way during the early phase of supporting any new VM. It's the best way we can get support into people's hands and see how stable it is.

[mikeal]

Wait a sec. AFAIK io.js fork was made to fight such state of things.

io.js was about project governance and release cadence. we now have great governance, a growing contributor base, and a good release cadence. having a stable native API would allow us to move even faster because we'd be able to take a new V8 as quickly as every 6 weeks rather than every 6 months (which we do in order to avoid breaking the native ecosystem so often).

[trevnorris]

@mikeal Might want to take part of this up with the @nodejs/api WG. There's already been some investigation done, and there are pitfalls, some of which are being ignored. e.g. ability to resurrect an object during GC, getting various process info (e.g. heapspace, etc. that is specific to the vm), cross VM debugging/profiling, the fact that each VM supports a different level of JS compatibility (which will turn into people either needing to write modules at the lowest common denominator or only supporting one VM). This doesn't even touch the complexity of creating an abstracted API we can place between v8 and the JS.

I'm not saying this shouldn't be done, but I am saying we get a realistic grip on what's required and how long and effort like this would take. And that if we want complete cross VM support then node is going to loose some features.

[mikeal]

@trevnorris yup, should have pinged them earlier. This thread is mostly a response to the discussion we had on the latest CTC call where we recognized that we hadn't yet had a public discussion on moving in a VM neutral direction.

In terms of how we do it, there's also the proposal @bnoordhuis dropped in an LTS discussion of starting with the current V8 API rather than trying to write a new abstract API which I'd be curious to get your feedback on.

[ELLIOTTCABLE]

“And that if we want complete cross VM support then node is going to loose some features.” is this necessarily true? This brings to mind http://dowebsitesneedtolookexactlythesameineverybrowser.com, but: Why can't there be a ‘Node-the-Least-Common-Denominator,’ and an officially-blessed ‘Node-on-V8’ superset, aka. the current Node.js? (unless I'm missing the causes of things being lost: I'm assuming you mean specifically for VM-independance.)

I understand how this may be more work on some level; but again: it seems to have obvious upsides. (Another way of looking at it is: There's no way the teams implementing Node-the-LCD on, say, Chakra, aren't going to include some juicy platform-specific non-standard features; why can't Node-the-Current on V8 also have, essentially, platform-specific features?)

(Now, I can see how some features might have to change substantially: if a feature currently depends on V8-specific tooling, but is also important enough that a non-dependant version of that feature must be included in the Node-the-LCD … then obviously we'll have to change the API to allow for both a non-dependant version, and then either extract the further functionality to a separate API, make it optional somehow, or yes, discard that functionality entirely if it can't be conceived separately.)

[mikeal]

@ELLIOTTCABLE I think you can look to nan for some guidance into how this plays out. nan started with very few features and grew to be the size and scope needed by the majority of the native module ecosystem. If you look at what Chakra is doing with the V8 shim it's essentially the same target, whatever subset is relied on by the native ecosystem. What makes this very hard for Chakra, and for any future VM, is that the API they are shimming is a moving target.

[trevnorris]

@mikeal Using the current v8 API would fail over time due to changes in the v8 API itself. Also not all VMs have the same features/native types that v8 has. Which would require VM authors to add new features (this may also be conversely true). There are also implementation details that then would leak, e.g. maximum string length is (2 << 27) - 16.

Possibly it would be more sustainable for the node project to have other projects to maintain a shim. Only offer this as a short term possibility, but not suggesting we stick with this.

Short of it is I'm fine if we all say, yes! let's do this. but should have a feasibility report done first. The API WG came to the conclusion that it would be easier to first create an abstracted user API. If we can't do at least that then there's no way we could write an entire abstracted internal API.

@ELLIOTTCABLE

Why can't there be a ‘Node-the-Least-Common-Denominator,’ and an officially-blessed ‘Node-on-V8’ superset

TBH I don't see this model working well in the module ecosystem. Would I npm install mod and npm install mod-lcd? This is probable to become a headache for some module authors as well (I'd suspect the native modules are most likely). The issue tracker will now need to include the VM version and type. They'll need to test across many more variants (good luck travis-ci).

Likewise I see this getting kickback from the existing community if their features are even trivially minimized because of the need to support multiple VMs. Including the possibility of needing to not land the latest-and-greatest VM of choice b/c it has features that cannot be ported to other VMs. e.g. ES6 modules will require native API hooks for implementation details. How can we only support that on a subset of VMs that we build and distribute.

As I said above, I'm not trying to say we shouldn't pursue this. Only that simply saying we should isn't enough to move ahead.

[tomByrer]

provide API for external engines to use, and have separate core team + teams who maintain each separate engine's bindings.

Sounds most reasonable. Different engines may be best for certain use cases, so could help web engineers stay in Node ecosystem than to look elsewhere.

Even with just V8, we already have ES6 evolving, and there is growing number of modules that are being published untranspiled, targeting only latest versions of Node

I've done this myself for a little dev utility. I'm not going to worry about crusty versions, though enterprise devs may feel differently. Rollup can help with backwards JS compatibility, so that is 1 less thing to worry about.

[Qard]

A big part of what has made node successful is the radical simplicity of the core. We've tried to keep the absolute minimum required in core to enable the community to iterate and explore many different things. This has been a major benefit of node and has mostly resulted in a very robust ecosystem. Emphasis on mostly.

Native bindings have been the single greatest failing of the "keep core simple" ethos. Due to the tight coupling with V8, the changes required to keep node core in line with the latest versions of V8 haven't been too painful without core itself. The problem being that 99% of node is the ecosystem, and every time we bump that V8 version we break all external native code.

We've attempted to patch away that pain with nan, and that has sort of worked, to some extent. But when we break nan, we break the users of nan, which breaks the modules using nan, and all the modules using those, and so on. What we need to be doing is not breaking those native modules at that first level, then that whole tree of modules depending on them will continue to work fine.

Currently, we are trading the time of the core contributors for the time of the community, and at a terrible exchange rate. In doing so, we actually make the work of the core contributors more difficult by necessitating all this complicated coordination of shipping V8 updates, backporting fixes, maintaining floating patches, etc.

If we took the time to write a proper native API, the various native modules in the ecosystem would stop breaking all the time. We'd stop throwing metaphorical rocks at the bee hive that is the node community, no longer angering them with broken things in every new version. I bet we'd even start to see increased usage of the native module API. I personally have abandoned a few native module projects due to not feeling they were worth the effort required to keep up with changes in node, and I'm a core contributor. I volunteer at the local nodeschool and every single time, about 10% of the students have issues installing something because a native module blew up.

I think we should be pulling V8 out to an entirely separate project and only pull it in at build time, at which point the dev could select which VM they want to build with. V8 could be the default reference implementation, but have the core team go to such lengths to keep V8 as the "official" VM of node makes no sense to me if the V8 devs are not putting comparable effort into supporting node. (Don't get me wrong, they do help out a lot, but node is still a second-class citizen to them.)

I would very much like to see a pure C API that covers the minimum surface area required to support most uses, and allow VM-specific things like debug tools to just use the appropriate VM headers directly, where necessary. Going with a C API would also help to allow other languages with C-compatible bindings to be used to develop native modules. I've been tracking neon for writing native node modules in Rust, but if there was a C API it'd be trivial to interface with these other languages. In the case of Rust, it would allow us to write native modules in a much safer language than C++. When writing code in C++, especially when dealing with the obtuse behaviour of VMs, it's very easy to run into memory or threading safety issues and then really bad stuff can happen.

[ELLIOTTCABLE]

@trevnorris Sonds like I'm totally on your page here re: cost analysis and ‘we should do this != we are now ready to do this.’

As for LCD: if everything can be shimmed, then my thoughts don't apply. I only mention that in the case where V8-specific features, that are impossible or improbable to shim, are requirements for existing Node features: it might be preferable to users that depend on those, that they keep depending on those features (and thus exclude themselves from the wider, VM-universal npm ecosystem), than to be told “these features are going away forever, and you have no option. Sorry.”

(Also, I'm only suggesting that as an option: that's also more work, and also needs to be considered in a cost/benefit analysis! It obviously might be the case that: 1. there's nothing that can't be practically shimmed, 2. there are too few users depending on the <things we don't want to shim>, 3. it may simply be too expensive to maintain a fork.)

(Okay, I'm gonna stop talking out of my belly-hole now and let the adults do the talking. =)

[mikeal]

If we took the time to write a proper native API, the various native modules in the ecosystem would stop breaking all the time.

The problem here is that we can't guarantee that we can bind this API to every version of V8 going forward unless the V8 team says they will continue to support it. nan tried to be this glue and had to suffer its own major breaking API change due to changes in V8 it couldn't support with an old API.

This is what I think @trevnorris is getting at as well, whatever we do can't be guaranteed to work with a future version of V8 unless V8 buys in to a neutral API or we have some other point of leverage that forces them to support and older API.

[vkurchatkin]

we can't guarantee that we can bind this API to every version of V8 going forward unless the V8 team says they will continue to support it

we can if we design API properly. V8 changes API => we change implementation. Nan is not designed for that

[mikeal]

we can if we design API properly. V8 changes API => we change implementation. Nan is not designed for that

nan was designed specifically to sit between different versions of the v8 API. in these discussions we tend to underestimate just how dramatic some of the change to the V8 API have been and how much Node.js and nan had to alter themselves in order to comply.

[vkurchatkin]

in these discussions we tend to underestimate just how dramatic some of the change to the V8 API have been

that's the core problem. Nan API is designed around implementation, i. e. v8. We need to design implementation-agnostic API. JSC API seems to be a good reference. It's C-based, simple, minimal and also is basically a wrapper around internal C++ API.

[Qard]

It didn't work for nan because nan is not sufficiently abstract. It does very little to conceal the machinery of V8 itself, so when V8 changes substantially, so too must nan.

A more abstract API absolutely could be made more stable than nan has been. It'd be difficult to achieve a comparable degree of flexibility, but I think that is fine as long as we don't prevent people from going the lower-level way when needed. As I said, some things like debugging/tracing will probably always require some VM-specific code.

[trevnorris]

@vkurchatkin

that's the core problem. Nan API is designed around implementation, i. e. v8. We need to design implementation-agnostic API.

Don't underestimate writing an API abstraction of this nature. For example creating an abstraction that forward looks to cover possible scenarios like v8's change to using Isolate, then later switching to using Context. In this case we'd need to add a generic pointer that we can pass around to every call that can hold whatever field is necessary. Then realize that while you'd probably maintain API compatibility, maintaining ABI compatibility will be much more difficult.

Further you have cases like the switch to Maybe/MaybeLocal. While this can be easily enough shimmed, it was placed there as a safe guard for the user. If we blindly forward the empty handle to the user then we've removed a safe guard that v8 intentionally put into place.

What I'm getting at is we need to realize how different VMs are, and how quickly they're moving with all the new JS features. Additionally the coordination efforts needed to make sure features are released at the same time (if that's desired) or allowing each to simply implement all the features it can, when it can.

@Qard

It'd be difficult to achieve a comparable degree of flexibility, but I think that is fine as long as we don't prevent people from going the lower-level way when needed.

By "going the lower-level way" I assume you mean by using the VM's API directly? It's hard to imagine that if third-party devs need lower-level features that the core team will never need them. While you may say this only addresses parts of the API like Debugging, I'd contend that there are singular methods that differ from between VM implementations that would be necessary for core development. e.g. externalized strings, resurrect on GC, Promise microtask executor, v8::External, multiple context handling, handling/hooks of uncaught exceptions.

You mention that things like debugging/tracing would require VM specific APIs, what would we do with existing node APIs that currently rely on those? e.g. --track-heap-objects. Also usage of the performance APIs that are also included? e.g. --prof-process

@ELLIOTTCABLE Cool. I'm sure there are several plausible avenues. The focus on my investigations have been to find the limiting factors of doing this.

[vkurchatkin]

In this case we'd need to add a generic pointer that we can pass around to every call that can hold whatever field is necessary

Sure, we will need some opaque context structure.

Further you have cases like the switch to Maybe/MaybeLocal. While this can be easily enough shimmed, it was placed there as a safe guard for the user. If we blindly forward the empty handle to the user then we've removed a safe guard that v8 intentionally put into place.

It seems easy enough to preserve this behaviour.

[Qard]

@trevnorris I don't believe there are actually that many things in core that would really be impossible to do through a generic API. Difficult, certainly, but not impossible. The few things that are, like the command-line flags you just mentioned, should not be considered as supported features across all variants.

I think it's totally fine to have certain features that are only supported in particular variants. They just need to be clearly marked. The very core components of the system should try to be as platform agnostic as possible.

I certainly don't believe there could be some magical API that'll make 100% of all the features of all the VMs just work flawlessly, but I absolutely believe we can make enough of the core parts generic to make supporting different VMs far less painful. In a lot of the more basic cases, which is most native modules, it'd probably be good enough.

[inikulin]

@trevnorris

While you may say this only addresses parts of the API like Debugging, I'd contend that there are singular methods that differ from between VM implementations that would be necessary for core development. e.g. externalized strings, resurrect on GC, Promise microtask executor, v8::External, multiple context handling, handling/hooks of uncaught exceptions.

+ V8 StackTrace API. Quite widely used in user land.

[trevnorris]

@vkurchatkin / @Qard Cool. Then the first task would be researching which VMs we want initial support for, and somehow doing comparisons across APIs so we can get an idea of how much can be initially supported by the abstracted API.

[Adron]

I'd say yes, unless it causes damage to core development efforts. If I could contribute some of the work (time limits and all) I'd say absolutely yes. ;)

So maybe in the future that'll happen. So I say yes now, with the idea maybe I could actually help out in the future.

[EdMaurer]

The ChakraCore team is committed to supporting an official API for plugging JS engines into Node.js and native modules. In addition, the team is prepared to dedicate hands on keyboards to help design and develop such an API.

[formula1]

Something more politically related Microsoft is currently showing effort to be the engine that allows us to paint in node's javascript.

Like many of you have said, v8 makes breaking changes and is forced (at times) to leave in deprecated functions for node to use or Nan adapts.

Really what this concept does is it turns node's javascript into a platform that javascript devs must support while they also must support W3c standards. Effectively pushing compatability issues upstream as a responsibilty to engine writers. With microsoft being as diligent as they are, this poses them to become the standard while v8 focuses internally more often (though they are generally diligent about bringing up those issues).

Its quite possible that this is ideal for node in the long term, but also poses a different question in my mind. Should node focus more on W3c standards? If we have learned anything, W3c standards are generally subpar usually coming late to the party. I personally enjoy writing js in node far more than the browser. So this proposal effectively requests that engine developers come to the table with both nodejs and browser compatability in mind. Is node at the table to make such requests? Microsoft is personally making the effort but most other implementations will likely be made in userland.

I think this is good long term since "node" will be considered a target environment rather than an after thought to the browser. And since I love node but am meh about the browser, this seems exciting. But the moment this happens, you've now become a competitor to the W3c. Perhaps node already is and Microsoft sees it before anyone else. Perhaps node should be more influencial in discussions in the W3c (web assembly especially). Will node have to make the effort to be v8 compatible still or will the two seperate slowly? Should we care?

I am all for this, but I believe this means far more than just "great idea"! It will make nodes life easier but also likely lead to other responsibilities such as maintaining standards. But if node doesnt want to be apart of the W3c, theyve effectively claimed superiority to existing standards and expect others to follow their lead. Which node should

[Twipped]

Something I dont think I've seen anyone ask yet is what this will mean for end users installing node. I've heard complaints that getting node up and running is already confusing to newbies. Would this change mean that you not inly have to figure out which platform binary you need, what version you want, and work out the best way to install it in that platform, but now you need to pick an engine as well?