Process for shipping open standards

[littledan]

@joyeecheung and I were discussing when Node.js should ship web standards. It's a bit difficult to determine when something is "really a standard", since different standards venues have different definitions of that. Sometimes, standards are "fiction" or wishful thinking: publications which don't actually have any real implementations. We can look to other implementations if our goal is to align Node with web browsers and other open standards implementations.

The idea here would be to document a suggested process for what would be considered "standard enough", based on their support and uptake elsewhere in the ecosystem. All standards should still be thought through carefully about how/whether they make sense in Node's context before including them in Core, and decisions about what to include made by Node collaborators, not this group.

A proposal for how we could go about this:

• It's never too early to start an implementation of a standard in a branch or a module in the ecosystem.
• If multiple implementers (or one??) have expressed support for a standard, it may be shipped in core in a module (e.g., "@nodejs/name") as an experimental API.
• If multiple implementers ship (or one, sometimes?) a standard, and there is good reason to believe that it will not have negative compatibility impact, then it may be shipped as a global.

(Exception: TC39 Stage 3 proposals which are implemented by V8 could be exposed as globals even if there isn't a second shipping implementation, unless this is expected to cause a problem.)

(It's really hard to define "implementer" or "support". WHATWG's definition could be a good default, while remaining open to other definitions on a case-by-case basis.)

(The above was later edited to suggest a process, not a policy.)

[cynthia]

I believe W3C products which have at least proceeded to CR (which is a fairly heavy process) could be considered safe to implement, but I might be wrong.

[benjamingr]

I think it only makes sense to implement experimental features as experimental APIs in Node.js and to graduate them from experimental status only after they've graduated.

[devsnek]

^ we've already done something similar with queueMicrotask

[littledan]

@cynthia Should we ship MathML 3 Content Markup in Node.js then? :)

@benjamingr Sounds good to me; edited the above about shipping in a module to mention experimental-ness (not sure how I forgot about it; I blame the cream hangover from all the time in France at TPAC).

[ljharb]

I’d hope that any such policy wouldn’t obligate node to ship something just because another standard had; in particular, many browser APIs wouldn’t make any sense in node, and shouldn’t be shipped “just because”.

In other words, node needs to ship language features, and will hopefully ship useful interoperable features, but need not (and arguably very much should not) become a browser.

[kenchris]

@ljharb of course you should only consider shipping what makes sense for the node ecosystem

@littledan of course not :-)

[joyeecheung]

For reference, this is our current stability index

To graduate an API out of experimental we need user feedback, but at the moment, the definition of the experimental status seems to be a bit too relaxed - from the users' perspective, it's a bit difficult to tell whether it's time to start taking an API seriously and experimenting with it in serious code, or if the API is still very immature and subject to future removal.

In the case of standards development, it may be helpful to have an additional index that provides a stronger guarantee, for example:

• If the module is later removed, the implementation would be published as an npm package and maintained under the Node.js organization
• The module is implemented according to an existing spec, which is already implemented by at least another implementer, so there is a stronger compatibility guarantee than our home-grown APIs

This could help us decide whether to ship something eventually while getting more user feedback during the devlopement.

[kenchris]

I think it is fine considering specs that are implemented at least by one browser. There are certain APIs that might make sense in the Node ecosystem, but don't have the same priority by all browser vendors. An example could be the Generic Sensor API.

But, btw, please feel free to ask the @w3ctag about the status. For instance, like Generic Sensors replaces the old DeviceMotion/DeviceOrientation APIs, there is also new work on going to replace the current geolocation standard with a GeolocationSensor

[littledan]

@kenchris I can see the argument for one browser sometimes; it might make sense to take this on a case-by-case basis. What's the recommended channel for asking the TAG these questions--should we make a design-reviews issue? Or just @ w3ctag?

[kenchris]

I am not sure - I assume only one person will get notified when you add @w3ctag. We can discuss it at our TAG meeting @torgo @cynthia @slightlyoff

[cynthia]

@slighlyoff is slightly off, might want @slightlyoff instead.

[mcollina]

@littledan I think this team does not have any responsibilities related to Node Core that have been delegated to it. Deciding to land or not a new module in core is a decision that is in the hands of the collaborators. I would not call the output of this discussion a policy, but maybe "guidelines to propose new standards implementation to core".

A good example of this is the addition to AsyncIterators or BigNum to the APIs that should support them. Another is queueMicrotask.

It's never too early to start an implementation of a standard in a branch or a module in the ecosystem.

I would encourage such a process, +1 to ecosystem modules whenever possible. This enables developers to use these standards independently on the version of Node.js they are using.

We can look to other implementations if our goal is to align Node with web browsers and other open standards implementations.

Node.js is not a web browser. In some of the Node.js use cases (server-side), a Node.js process serves multiple users (ideally thousands) vs the single user that a web browser has. This difference makes a a lot of browser standards not implementable as Node.js cannot really match the semantics of a web browser.

[cynthia]

This difference makes a a lot of browser standards not implementable as Node.js cannot really match the semantics of a web browser.

I think what you ship is entirely up to you to decide (as with browsers, not all browsers are mandated to ship everything), and that would depend on what the developers want and need. If there are web standards that developers want to see in a node context which are not reasonable there do bring it up with the working group behind this. (or us, in the event you have trouble finding the WG.)

[littledan]

I think this team does not have any responsibilities related to Node Core that have been delegated to it. Deciding to land or not a new module in core is a decision that is in the hands of the collaborators. I would not call the output of this discussion a policy, but maybe "guidelines to propose new standards implementation to core".

Sounds good to me!

We can look to other implementations if our goal is to align Node with web browsers and other open standards implementations.

Node.js is not a web browser.

This is why I said "if" :) My impression is that some Node collaborators want to align Node with the web where it makes sense, that it's being taken on a case-by-case basis at the moment, and there has been no project-wide goal articulated. Is that correct?

[mcollina]

This is why I said "if" :) My impression is that some Node collaborators want to align Node with the web where it makes sense, that it's being taken on a case-by-case basis at the moment, and there has been no project-wide goal articulated. Is that correct?

Yes! Aligning when it make sense is a good thing. IMHO we should also focus on the broad ecosystem and not just core. Certain APIs might be contentious to add to core, but providing an official module/guide to achieve full interoperability should be a goal of this group.

[joyeecheung]

I think this team does not have any responsibilities related to Node Core that have been delegated to it. Deciding to land or not a new module in core is a decision that is in the hands of the collaborators. I would not call the output of this discussion a policy, but maybe "guidelines to propose new standards implementation to core".

IIUC, this discussion is not meant to settle down on a policy/process/suggestion - I think a possible outcome of this discussion would be a PR in one of the docs in https://github.com/nodejs/node that gets tagged tsc-agenda or tsc-review (or a PR in the TSC repo), but it's good to have an informed discussion here to prototype the content of that PR while getting ideas from people in other standards groups or vendors.

EDIT: I guess if we also want to settle down on a process regarding "official" modules, a PR in the TSC repo would be more reasonable.

[littledan]

Policy was probably too strong a word. I've changed the OP wording to "process", per a suggestion from @joyeecheung .