Define clear goals/motivations of the Ayo.js project about ayo HOT 11 CLOSED

Edit from @scotttrinh: Trolling.

from ayo.

@bane-alex You might want to check out #58.

Files changed (106)

+5,366 −858

from ayo.

It's a project aimed at creating a new foundation of project governance and management

- values.md

OK- The goal/aim stated here appears to make clear that Ayo is a project whose primary output is governance models rather than software. I think that's a noble goal and I may have just not understood it at first!

I think my (and perhaps others') question is: "Node.js has a bunch of technical/API problems built up over time and with progress stuck due to BC requirements- can I expect Ayo.js to attempt to tackle these problems?" and it sounds like the answer is "probably not." This is not meant as a value judgement, just an attempt to manage my own (and perhaps others') expectations of and understanding of Ayo.js.

Per your suggestion, I'll close this issue ('lack of clearly articulated goals and motivations') as WONTFIX. I will leave it open a day or two longer in case others have relevant input that our discussion hitherto hasn't captured.

Also, I want to reiterate that "We're taking action on those long running, intractable issues that have been annoying you about Node.js for ages" could be a really good selling point for this project and bring a lot more people on board, and I do not think ⎇ is incompatible with ☭, or that values described in values.md would have to be compromised to add this goal.

from ayo.

Hello sorry for the slight high-jack, I am going to leave a short comment here just as a friendly reminder more than anything else in case anyone might be very eager for Ayo to be something very far and almost not compatible at all with Node due to forgetting the consequences:

We all suffered as web devs (specifically front end) hours that could sum up to months or maybe even years of our lives due to the profound incompatibility that we call front-end, and as IE and older browsers are finally coming to an end, with all the four giants and their browsers being regularly updated and following the latest, and also frequently updated, EMCAScript; these days are hopefully soon coming to an end.
Please, for the love of JavaScript and the sanity of all people who use it combined, whatever decision you take: remember those conveniences that we all, me included, want will often not save as much time as the incompatibilities they might waste. And going back in them is but more incompatibility nightmare for everyone. Please, don't replace callback hell with incompatibility hell, please

from ayo.

The goal/aim stated here appears to make clear that Ayo is a project whose primary output is governance models rather than software.

I would vote for Ayo to be about both a (hopefully) improved governance model and a chance to deliver improved software. To me this should be the meaning of overcoming "red tape" as discussed in VALUES.md.

It would be really awesome to see a working workers feature ref: #58 delivered working soon, even at a pre-alpha level, as well as other "demand for" changes linked above: https://twitter.com/sebmck/status/908031616659927041 & https://twitter.com/BrendanEich/status/908068426999930880

I would also strongly agree with @Mathspy - avoid breaking things unless absolutely necessary as I said in #68 (comment).

from ayo.

Just found #7, sorry for not looking more closely at existing issues (this issue was originally going to be a comment on #56 but I realized it was a separate question).

I respectfully disagree w/ @varjmes here:

I think we've answered it well, in the form of our values document [VALUES.md].

"Is maintaining compatibility with Node.js a requirement of future changes to Ayo.js" is the main question not answered here, and which is crucial to understanding what Ayo.js is.

from ayo.

I think this is definitely a duplicate of #7 and it's something we've discussed a number of times now. I think the values document is the only concrete action you're going to get, and they don't include strict long-term compatibility with Node.js. They also don't preclude it.

I am not a member of the Core team, but my suspicion is that this question you have about compatibility will be answered on a case-by-case basis. Ayo.js, by virtue of being a newer/smaller project, has a unique opportunity to change course in a way that Node.js simply does not, and there are many people out there with a wide range of interesting needs.

I think it's safe to say that a reasonable level of compatibility is likely to be a long-term priority of the project, if only because losing access to an ecosystem of 550k+ (and counting) would be a terrible loss: but things evolve, and there's the possibility of being incompatible in some ways and compatible in others. I think mostly-compatible is the most likely scenario, and folks will probably factor in the likelihood of getting Node.js Core to merge those changes at some point in the future.

Now, keep in mind that one of our aims is to make it easier for project members beyond the core team to have significant influence over the project. I think getting a concrete promise like that right now about long-term decisions is... not really something that's feasible, realistically, but you can definitely advocate in favor of preserving compatibility as concrete technical questions come up. I assure you plenty of us genuinely care about preserving that. Myself included. As well as the likely members of the Core team. I'm sure these discussions will happen even if you're not the one bringing them up.

from ayo.

p.s. since it's a duplicate, I'd encourage you to close this issue. If the above answer is not satisfactory, I recommend opening a new one that focuses specifically on the issue of strategies for maintaining compatibility, rather than casting as wide a net as this issue did. Narrowing down conversation reduces noise and improves outcomes.

from ayo.

@Mathspy & @brodybits: We all agree that we should avoid breaking things "unless absolutely necessary," I am certainly not suggesting breaking things for the sake of breaking things. 😄 I'm saying that some long-running node issues may require "breaking things" to fix them–moving the platform forward while maintaining 100% BC is proving to be a nearly impossible task (see nodejs/node).

1. In #56 someone suggested opening a feature question that has possible interop-breaking solutions
2. Someone else said 'this has been discussed a lot already, let's not reopen the question'
3. OP said 'wait, isn't a fork precisely the place to reopen the question?'

This lead to my question "Is this fork a place to open such questions, is this fork willing to consider options that Node.js has rejected/quagmired?"

Leading/Following & Interop

Node.js is a party that is plotting a path, walking, travelling somewhere. Some people said "I don't like the way you're deciding the course this party takes. We're breaking off and forming a new party we'll call Ayo.js."

OK, so now Ayo is a different party from Node. Currently, the "Ayo party" is walking separately from the "Node party", but following directly behind them. So far, where Node chooses to go, Ayo follows.

In this analogy, "interop" is like the path you choose: if you want interop you must stay on the same path. Node is leading. Node is not going to change course to follow Ayo.* This means that if Ayo wants to stick close to Node (interop), Ayo must follow Node and this means following the technical decisions of the Node.js project. Ayo can neither add features that Node doesn't have, nor fail to implement features Node has. Effectively, this makes Ayo is a shadow-project of Node moreso than an independent project.

If Ayo is intended to be an independent project, it must be willing to part ways with Node. It must be willing to say "you're moving too slow, I'm going ahead" or "you're turning left, but we want to turn right." Otherwise all it can do is follow the decisions Node leadership makes, which seems to defeat the point of breaking away from Node in the first place.

* for the time being! If Ayo generates successful, popular improvements to the Node platform as io.js did, Node may wish to incorporate those back into Node and thereby "follow" Ayo. This can only happen, however, if Ayo is free to make changes and improvements that draw users and become popular.

Implications vis-a-vis feature development

If interop is a requirement, there's no point discussing feature questions in this repo: Ayo must follow Node, so all feature decisions will continue to be made in the node/nodejs repo by nodejs leadership. Example:

• Q: "How should we handle module loading?"
• A: "We have to do whatever Node.js does."

And that answer is the answer to basically every feature design question. Even the slightest variance/additions/omissions (e.g. "we'll make two ways to do it") will cause a divergence in userland code and therefor break interop of userland code.

So:

1. Can Ayo diverge from node?
2. If not, what's the point of discussing any feature development here, given that the answer is "we must follow whatever node does"?

from ayo.

from ayo.

Good luck & god speed!

from ayo.