Node.js forked, Ayo.JS, is trying to find its way

By: ( +David Herron; Date: Sat Sep 23 2017 17:00:00 GMT-0700 (Pacific Daylight Time)

Tags: Node.JS »»»» Open Source Governance »»»» Ayo.JS

A month ago we suddenly had news of a hostile fork of Node.js, called Ayo.js, by Node.js team members upset over what they called Code of Conduct violations. Supposedly another Node.js team member was routinely harrassing people (a claim he has denied) and spoke against having a Code of Conduct. I don't know whether any of that is true. What's necessary is to check in with Ayo.js, see what they're doing, and if there is any compelling technical reason for their existence.

Going by the Ayo.js issue queue, that team is considering the same problem. Several issues are suggesting breaking changes with Node.js, that might produce a superior implementation. In one issue the folks are explicitly debating whether they should maintain one-for-one compatibility, or to strike out on their own.

Project home page: (

Also see Node.js has been forked over Terms of Conduct violations forming Ayo.JS project

The first thins I see is a warning that Ayo.JS is a fork from Node.JS, and that they haven't fixed up all the documentation, and therefore lots of links will point back to the Node.JS project. In other words, growing pains. There's lots of documentation, and perhaps not enough people to take care of these little details. And those details are very important to square away if they are to make anything of themselves.

I don't have any insider knowledge. I'm looking in from the outside, and asking questions. If I've come to a wrong conclusion, please point out what's off, and where we might learn the truth.

As they say - by their fruits ye shall know them. Hence, what are they doing in the ( Issue Queue is a great indicator of where Ayo.js is heading.

( Asks about strategy for merging changes from "upstream project" (Node.js). In other words, lots of work is going into Node.js, and the Ayo.js project would like to make use of that work. The discussion is about the difficulty of pulling in upstream changes when there are also local changes. The resulting merge conflicts will be difficult to process, and doing rebase operations is also extremely difficult.

( Asks about bringing Fibers into Ayo.js core. As one of the responses pointed out, "Fibers are largely superseded by async/await and solve a problem ayo doesn't really have."

Comments in the thread claim that Fibers are much faster than Promise/async/await, and perhaps are easier to understand. I don't know about that. However, that they're considering this indicates a desire to commit large incompatibilities with Node.js.

( I don't understand the issue title, "Consider additive systems for importing ES Modules", but going by the discussion it's about dropping the decision to use .mjs for ES6 Modules, and .js for the traditional CommonJS modules. Instead it would use .js for both.

Upstream has decided to go woth .mjs and .js and have deeply studied the issue and decided on this direction. Some suggest that result is ugly - and for example the MacOS Finder will treat a .js file correctly, but give a blank icon for .mjs files. In other words the .mjs/.js decision is incompatible with other systems, even if its an excellent decision for Node.js. Except that the @std/esm supports ES6 modules with the .js suffix, showing proof that it's possible.

Again, I don't understand all the technical ins-and-outs, but it's a clear indication of willingness to implement breakage with Node.js.

( Here we go, navel gazing: "Define clear goals/motivations of the Ayo.js project"

  • "corporate domination of governance and organizational ossification that made a fork necessary"
  • "run a node-like project that prioritizes inclusivity/diversity while maintaining interoperability with Node.js"
  • "Ayo.js was created to break out of the organizational quagmire Node.js is in and to make aggressive changes to push the project forward technically. This will almost definitely eventually mean making non-interoperable changes; without allowing for this, Ayo is effectively chained to Node.js."
  • "Ayo.js was created to be a shadow-project of Node.js which is differentiated by having explicitly stated political aims (i.e. 'people over software' or similar). This project should keep interop with Node.js as a requirement to all development."

That discussion isn't finished, but it was pointed out the Ayo.js Values document clearly says the project's purpose is to create a new governance model.

In other words, it's not about technical issues, but governance.

Except the crew is also talking about breaking compatibility over technical issues. Their actual behavior is more than just establishing a new governance model.

( More navel gazing .. "Is ongoing interoperability with Node.js a requirement for Ayo?"

This points out that if all they do is establish new governance, there won't be any compelling reason to use Ayo.JS and it will all be a waste of time.

The issue points out the io.js fork did not have major breaking changes with Node.js. That's an important point since Node.js became hugely improved when the io.js and Node.js teams reintegrated.


It's too early to say where Ayo.js is going. There is a pull-and-tug between two factions, some that want to make large technical changes in order to adopt a favorite feature, and others whose goal is a better governance model.

Which way will they go?