Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JavaScript Standard Library Proposal (Builtin Modules) #147

Open
annevk opened this issue Mar 14, 2019 · 4 comments

Comments

Projects
None yet
4 participants
@annevk
Copy link
Collaborator

commented Mar 14, 2019

Request for Mozilla Position on an Emerging Web Specification

Other information

This is what #145 and #146 build on, somewhat. A concern I've seen is that they don't block on this though as all the infrastructure could be moved outside "TC39 control".

@annevk annevk added the ecma label Mar 14, 2019

@domenic

This comment has been minimized.

Copy link

commented Mar 14, 2019

Note that tc39/proposal-javascript-standard-library#43 may be clarifying. In terms of actual normative work this is proposing, there is none yet from the proposal champions, but I've put together tc39/proposal-javascript-standard-library#44 which represents one direction the champions maybe-possibly might be interested in.

@littledan

This comment has been minimized.

Copy link

commented Mar 15, 2019

To summarize some of the issues under discussion:

TC39's most recent discussion was at the November 2018 meeting in a breakout session, see notes. The notes are pretty high-level, but we discussed each of those issues listed above.

The current import-maps/kv-storage origin trial takes some opinions on these questions:

  • Polyfilling is provided via import-maps.
  • Module contents are not deeply frozen.
  • As the module prefix, std: is used.

Current specifications and drafts layer the module map, module resolution and polyfilling in HTML (or WebIDL to potentially populate the module map); I haven't seen a concrete technical proposal for putting any of these in the JavaScript specification.

I'm not a big fan of focusing on "TC39 control"; let's just work together towards a common path for built-in modules coming from TC39 and Web APIs, integrating input from web developers and people working in various standards bodies.

@dbaron

This comment has been minimized.

Copy link
Member

commented Mar 29, 2019

also cc @bholley

@annevk annevk changed the title JavaScript Standard Library Proposal JavaScript Standard Library Proposal (Builtin Modules) Jun 25, 2019

@annevk

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 19, 2019

Thanks Daniel for that summary. We’ve discussed this internally and of the unresolved issues in TC39 we feel most strongly about having a single namespace for standardized APIs.

There’s precedent of APIs moving between standards bodies (ArrayBuffer) and precedent of APIs being shared across ecosystems (URL, TextDecoder, etc. can be found on the web and in Node.js).

The alternative would involve aliasing or worse, ending up with slightly different flavors of the same thing.

Ideally the governance is such that a name is not permanently allocated unless there’s commitment from multiple implementers, a standardized API, and a sufficiently large test suite.

(This should not preclude other ecosystems from having their own namespace.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.