WHATWG Participation Policy

[MylesBorins]

Moving from tsc#532

Original Message from @benjamingr:

Hey, raised in whatwg/url#377 (comment) :

I'd love clarifications about what's the current relationship between Node.js and standards bodies - as well as understand what's the correct way to pursue changes we'd like in WHATWG specs :)

So... what's our WHATWG policy?

[mcollina]

I think the most important question is: how do we reach consensus on the changes that we'd like to see in WHATWG specs? My point of view is that what is there was mainly designed for the Browser, and Node.js is not a Browser. We could aim to be somewhat compatible at best. Turning Node.js into a Browser (one VM per user) should not be on the table, as one of our main use cases involves multiple end users at the same time.

[benjamingr]

We could aim to be somewhat compatible at best.

I don't think we should and I completely agree with you that quite simply we're not a browser and shouldn't be a browser.

On the other hand there is a ton of value in being compatible with as many APIs as we can to make writing universal JavaScript as easy as possible. For example - this is going to get brought up again and again with fetch web crypto.subtle and other APIs with people asking us to implement it in core.

Another alternative that we haven't considered is making official packages for those things under the @nodejs/ namespace. So Node doesn't ship with fetch or crypto.subtle but you can import { fetch } from '@nodejs/fetch' which is installed from the NPM registry.

I haven't thought this through (versioning for example) but it's definitely worth exploring IMO.

[apapirovski]

I have mixed feelings on the general idea of broadly adopting browser-focused standards. On the one hand, as someone that's been primarily a front-end engineer throughout their career, I appreciate that direction (for my own ease of use). On the other hand, I recognize that often it forces us to do things in less than satisfactory ways and to compromise on what's best for Node.js. I suppose in that regard, better participation in the actual design process could lead to some of these specs not being so far conceptually removed from Node.js.

---

Mostly though, the idea above from @benjamingr of shipping some of these packages in the @nodejs namespace, is an appealing one to me. 👍

[mhdawson]

I do like the suggestion of having official packages outside of Node.js core. Do you have thoughts on what would make a package "official" ?

[jasnell]

... quite simply we're not a browser and shouldn't be a browser.

I don't think it's quite that simple. It's not one or the other and there are browsers being built on top of Node.js right now, making the picture even less clear. It's a classic venn diagram and we really need to figure out the right areas of overlap. Not every API will be suitable for both browsers and Node.js, but there is a reasonable subset that will be. Further, moving forward, non-browser environments like Node.js need to be taken into consideration when designing new APIs.

[joyeecheung]

I do like the suggestion of having official packages outside of Node.js core. Do you have thoughts on what would make a package "official" ?

I think having the foundation account as a collaborator and moving it under this organization would be enough? We can also document them in our API docs, maybe in-place or as links.

It's also worth considering release lines with these packages built-in so people who prefer these APIs can go with those releases instead of the stripped-down version. Or maybe we can do it the other way around, maintain the code in nodejs/node and release packages/bigger binaries out of that while keeping the slimmer release lines at the same time. That would introduce a bit more work for the release team but should be automatable.

[benjamingr]

I do like the suggestion of having official packages outside of Node.js core. Do you have thoughts on what would make a package "official" ?

Just throwing what I had in mind out there:

• Ownership by the Node.js Foundation with the TSC overseeing such projects.
• Under the official project npm namespace name.
• Adopting Node.js Governance and Code of Conduct.
• Making maintainers of said packages foundation members if they are not otherwise members.
• Commitment of said projects to run on latest Node.js LTS
• Commitment of said projects to pass the WPT so users can actually share said code.

[mcollina]

We already have examples of such modules, and you can find them at https://www.npmjs.com/~nodejs-foundation. I would consider those packages "official": we are not really marketing them as such, but that's different from the substance: the TSC has oversight over them. Most of those began in the ecosystem.

Under the official project npm namespace name.

I think we cannot and should not use @nodejs as it is currently proposed for scoping internal modules. We should not use it for both internal and external thing, as it would be highly confusing.
Moreover packages within scopes are harder to find, as you can see in your node_modules folders (how many of those are there?).

I think we should just publishing them as normal packages. We might do a bit more publicity via the Node.js social accounts, and maybe clarify things in the README. In the end, it should not change anything for our users. Those modules should really be foundational pieces.

[mhdawson]

@benjamingr what is WPT ?

Otherwise the list looks pretty good to me. The main concern will be to avoid "picking winners" but in many cases it matter of making sure there is one (as opposed to picking one as a winner) and in those cases that should not be a problem.

[devsnek]

@mhdawson the web platform tests -> https://github.com/web-platform-tests/wpt

We currently integrate some of them (like URL tests) into our test suite

[devsnek]

I'd like to see us working with WHATWG to produce future APIs that make sense in and out of browsers. I don't think there is really a need to have two stream APIs, two crypto APIs, and two ways to enqueue microtasks, but multiples exist because none of them fulfill all the use cases that exist for them. I think moving forward we can change this and reduce the annoying overhead of writing cross-platform JS. We might even be able to act retroactively but I don't want to ask for too much all at once :)