Governance

[codehag]

Based on the readme, we identified that some of our concerns are still outstanding: mozilla/standards-positions#147 (comment)

The constraint that we would introduce here is that it is not only TC39 which can introduce JS builtin modules on the JS namespace. The wording is as follows:

The js: prefix will be reserved as the namespace for the JavaScript language only and will be governed by TC39, making the standard library a true JavaScript standard library.

The danger here is that it doesn't provide a pathway for collaboration across standards/organizations. As a result, we may end up with multiple implementations or have to introduce aliases. The examples given by @annevk, URL, TextDecoder and ArrayBuffer, don't have a clear way of being included in the proposal as it is now, given the restriction to TC39 only. Our standards position on this is still open as a result.

This was a constraint also echoed by Chrome last year, so I am cc'ing @syg here to get some feedback on their current position.

One way in which this concern could be addressed is if this proposal introducing a pathway, or shared governance for introducing cross standards standard library functions into the js: namespace.

Edit: it appears that the readme is out of date? This issue is specifically referencing the contents of the readme -- this comment might be misplaced if this has already been resolved.

[littledan]

This proposal doesn't require that the web platform would make a namespace, as far as I can tell. I would prefer that we go step by step, gradually introducing this feature, and not get hung up on agreeing all at once where to put all future modules.

[codehag]

I understand the desire to get past this, but at present, the readme makes it clear that js: is only TC39. This is a critical issue from our perspective, as it may result is significant ramifications on the web. It may be that the readme is out of date, based on what I gathered from the slides. I would like to clarify this before the meeting.

[erights]

The governance is tc39. The process is that any other organization that wishes something to be in the js: namespace bring it to tc39 as a tc39 proposal. This was settled. Often old material is out of date and needs updating.

[erights]

The danger here is that it doesn't provide a pathway for collaboration across standards/organizations.

Sure it does. Bring it to tc39. Advance it through the tc39 process.

[erights]

The quoted sentence

The js: prefix will be reserved as the namespace for the JavaScript language only and will be governed by TC39, making the standard library a true JavaScript standard library.

is correct. It is not out of date.

[syg]

Here's my understanding of the compromise that we reached for governance at the October 2019 meeting:

• Reserve js: as a prefix for TC39 use
• Say nothing about governance of builtin module namespaces as a whole
• Say nothing of how hosts should expose built-in modules, and if at all. To wit, a host reserves the right to ship their own namespace, no namespace, or not use built-in modules at all. HTML looks like it'll opt for not using built-in modules at all, should they become a thing.

The intent of the compromise was to refocus the proposal to be more about solving the technical problems of providing built-in modules as a technology for hosts that do want to use it (e.g. Node, or the web way in the future). My hope at the time was that to solve the "available in synchronous scripts" problem would mean that standard js: modules would be magically available as globals as well or something. As the current proposal stands, I don't see the BuiltinModules global object as sufficient to work around the ecosystem bifurcation problem folks have raised, like in #59.

So my position differs on two subpoints:

1. I am still for built-in modules as a technology for hosts to use as they see fit.
2. I am against TC39's own use of built-in modules to ship features without a better solution to the ecosystem bifurcation issues.

[msaboff]

It was made very clear at the June 2019 TC-39 meeting by @annevk and others, as well as from a Builtin Module presentation at TPAC in September 2019 that the various standards bodies already had sufficient coordination to collaborate on adding builtins modules. Although many of those voices want a singular, unified namespace, say js: or std:, we can't have a standard library unless a standards body is responsible for the contents. That is why we are claiming js: for TC-39.

It was made very clear at both those meetings as well as in other communication that no additional governance was needed as we once advocated. Please review earlier Builtin Module / JavaScript Standard Library presentations to TC-39 for details.

I think it is premature to now declare that suddenly standards bodies are not able to collaborate on adding components to a standard library without additional governance. Such components can be added either with a js: prefix through working with TC-39 as @erights describes or via another prefix more suitable for the components in question.

[msaboff]

Here's my understanding of the compromise that we reached for governance at the October 2019 meeting:

• Reserve js: as a prefix for TC39 use
• Say nothing about governance of builtin module namespaces as a whole
• Say nothing of how hosts should expose built-in modules, and if at all. To wit, a host reserves the right to ship their own namespace, no namespace, or not use built-in modules at all. HTML looks like it'll opt for not using built-in modules at all, should they become a thing.

This is my understanding of what was generally agreed upon after discussions at the Oct 2019, Dec 2019 and Feb 2020 TC-39 meetings.

The intent of the compromise was to refocus the proposal to be more about solving the technical problems of providing built-in modules as a technology for hosts that do want to use it (e.g. Node, or the web way in the future). My hope at the time was that to solve the "available in synchronous scripts" problem would mean that standard js: modules would be magically available as globals as well or something. As the current proposal stands, I don't see the BuiltinModules global object as sufficient to work around the ecosystem bifurcation problem folks have raised, like in #59.

The Synchronous Script problem has a closely related issue to be able to shim a module before other scripts / module start loading. That was some of the impetus of introducing the BuiltinModules object. It may make more sense to take this up in a separate issue as it doesn't have much to do with Governance. I don't thins that #59 is the right place either.

[syg]

The Synchronous Script problem has a closely related issue to be able to shim a module before other scripts / module start loading. That was some of the impetus of introducing the BuiltinModules object. It may make more sense to take this up in a separate issue as it doesn't have much to do with Governance. I don't thins that #59 is the right place either.

Yep, that's fair, sorry to derail.

Edit: Let's continue the ecosystem issue in #58, which is directly about that, not #59.

[littledan]

The slides say

Originally specified a coordinated namespace Eliminated.

BuiltIn Module Names

• Modules added by TC-39 will begin with the prefix js:, e.g. js:Complex.
  • Other uses of the js: prefix are non-standard.
  • Organizations such as other standards bodies can use other prefixes.e.g. TC-53, OpenJS Foundation, implementors...
  • Formal coordination of prefixes was rejected by TC-39 (July 2019) as well as by the W3C (Sept 2019).
  • Should TC-39 register “js:” with IANA?

I think this proposal is a good compromise and hope that it meets the concerns of @erights and @codehag . It'd be great if the README were updated to summarize everything that the slides say. (For example, the README doesn't even mention the BuiltinModule API.)

[annevk]

@syg so what would be the net impact on the web platform? The ability to create synthetic modules through globalThis.BuiltinModule? Or is that also host-configurable?

(I'm not sure to what extent it's worth debating the other points raised, but standards bodies being able to collaborate does not mean that one standard body should have full control.)