Is ongoing interoperability with Node.js a requirement for Ayo?
Sequoia opened this issue · 11 comments
Reading #56, it became clear that the answer to "how should Ayo handle es6 modules" depends heavily on the answer to the question "Is it a goal/requirement of Ayo.js to maintain full operability with Node.js, without a compatibility layer, converter, preloader, etc.?"
Ayo should remain interoperable
- 👍 People can swap them out with no effort
- 👍 Possible to send most/all patches back and forth between projects
- 👎 Ayo.js development is effectively chained to Node.js (which also means being chained to Node.js's governance, an aspect of the Node project Ayo was created explicitly to move away from)
- 👎 It's not clear why the average user would want to use Ayo. No "killer features" beyond extremely minor tweaks. For example, the
mjsquestion can only be answered with "depends on what Node.js does." (Any "extra" Ayo features effectively break interop if they prevent someone from moving their code back to Node, which means Ayo can neither add nor subtract from the node.js feature set.)
Ayo should address long-running node complaints even if it means breaking interop
- 👍 "Killer features:" Gives users a clear reason to give Ayo a try or contribute to the project. Frees Ayo to implement solutions to long-unsolvable problems with Node.js (make a clear & well-designed decision re: module system, Promises etc. even if it breaks BC). This experimentation & moving forward could greatly benefit both projects & drive node.js forward and doesn't preclude future remerge. ("Same code, better governance model". . . even for people who support Ayo's political mission, this is a nebulous selling point at best.)
- 👎 Break interoperability with Node.js: users might have to pick which JS server ecosystem they want at the outset of a project
- 👎 Will become harder to move patches back and forth between projects
- 👎 May require interop layer or "converter" ("run your modules thru this babel transform to convert Ayo/ES6 modules to Node compatible"). This actually strikes me as a fairly small price, at least initially, given the fact that Babel and JS compilation is now ubiquitous within the ecosystem.
Why does this need to be decided now?
- Because it will help users & contributors understand the purpose of the Ayo project
- Because "well, are we OK with breaking interop with Node.js?" is going to come up over and over in feature design discussions.
- Because without a clear answer (if one person thinks "yes" and one person thinks "no"), it will be hard to collaborate on feature design.
- Because "answering this question on a case by case basis" doesn't really make sense-- if you break interop in 1 place, you've broken interop. The answer to "can I move my project back and forth from Node to Ayo without changes" is fairly rigid "yes" or "no."
- Because if the answer is "we're OK with breaking interop", this should be stated as soon as possible so people can start planning/designing for it. To assume you need interop for a year then deciding maybe you don't means losing a years worth of possible solutions that were blocked by the need for interop, it also means squandering the buzz and attention Ayo has right now but probably not for long.
Summary of motivations for this ticket
There are people with solutions to long-running node issues ready-to-go (or at least ready-to-try), held back only by BC concerns. Allowing BC & interop break would open the flood gates for novel/exciting changes that could free up the governance log-jam, get the "innovation" flowing again, and demonstrate the value of the governance model Ayo is built upon-- a win-win that benefits Ayo's core goal of "creating a new foundation of project governance and management."
My hope is that Ayo chooses to address the long-running node.js issues head on and we'll see a big jump forward in the advancement of the JS-on-the-server project. 👍
Acceptance criteria
- Ayo documents a clear technical vision (perhaps created once technical WGs form & meet) of whether feature development will be bound to Node.js
- Ayo documents a clear yes/no answer to "is interoperability with Node.js a requirement for Ayo.js?"
Is there a reason this cannot be done on specific subsystems of the projects rather than the project as a whole?
@bmeck Not sure I understand the question. If ayo said "FS API is changed, Crypto API is the same", how would I determine if its safe for me to move my project N->A or A->N? How would I determine which of all my dependencies and transient dependencies rely on FS, or on Crypto? If I have a project with external dependencies as is common in the Node.js world (usually a huge web/tree of dependencies), it would seem I effectively have to assume all Node.js APIs are in use.
Furthermore, if I build on Ayo now, before any "expect BC/interop breaks" statement is made, all the breaking change concerns in Node.js will be carried over to Ayo.js (i.e. I'm going to wail if you make a change to Ayo that breaks my project in the future).
Maybe I'm misunderstanding you, but to me, either a) I can move my JS project from Node to Ayo without rewrites or b) I cannot. "You can move your project from Ayo to Node easily as long as you aren't using API x" is effectively the same to me as "You cannot move from Ayo to Node.js" Either they are interchangeable or they aren't.
Possibility: Declare a 🎊Jubilee Year🎊 for Ayo.js: everything's on the table, nothing's guaranteed for 12 months, after which BC will be avoided. This would allow rapid processing of the Major Node Issues backlog with an understanding that the project will stabilize in the near future.
Ayo.js is brand new and currently has 0 obligations to handle legacy anything (people can just stick with Node if they prefer)-- this will not be true forever. IMO Ayo should seize this opportunity to make some leaps forward.
@Sequoia for various efforts like ESM, web and Node made great strides to discuss what breaks / if it could be checked when porting between the 2. They have not made efforts to be 100% compatible outside of that. I think there is value in being able to say fs is the same if it can be determined easily that something uses fs (like via a tracking mechanism of NODE_DEBUG=module.
I think the module system question is one of the big ones, as major changes there would break interop with Node at a foundational level.
I think there is value in being able to say
fsis the same if it can be determined easily that something usesfs
So all those projects that never read any files from disk would be portable? 😉 I'm sure it's possible to do this scanning/API-by-API check but I think realistically if this is necessary users are just going to pick one thing for their project and stick with it, the alternative (granular checks) is a lot of work without a clear benefit.
@Sequoia being able to state that your module that you author works in both is a very clear benefit and lower maintainance
Maybe it helps to re-phrase the question differently: Instead of asking whether we want compatibility with Node, ask under what circumstances we would break compatibility?
ask under what circumstances we would break compatibility?
It would be great to see Ayo.js keep near 100% compatibility with certain Node releases (such as Node 8), with certain highly desired enhancements such as worker (#58) hopefully available soon. Any points of broken compatibility should be documented very clearly.
I am thinking it would also be ideal to see Ayo.js updated periodically based on the Node.js LTS releases. Existing test suite should be good enough to verify assuming the existing tests are not changed too much from the Node.js tests.
@bmeck ah OK . I misunderstood you-- I thought you meant internal module authors, i.e. authors of fs, module, net etc.. Your suggestion seems to be an answer to "assuming Ayo & Node diverge, how do userland module authors manage compatibility?" and that's a down-the-road concern given that it's not clear there will be any divergence of Node & Ayo. I agree with you that the ecosystem would handle this on its own in this case.
For internal Ayo API authors, I do not think it would make sense to make interop decisions API by API, as breaking one would effectively break interop on the entire platform.
how do userland module authors manage compatibility?
How did they do it when io.js broke away from node.js?
Were there no breaking changes to io.js?