<hober> ScribeNick: dino

<scribe> scribenick: dino

drousso: I'm here to talk about JS Built-in modules, speaking for some Apple members of the TC39 group
... Goals: provide common functionality that appears as if it is built-in. We don't want to keep polluting the window namespace.
... also allows browsers to reduce memory by only creating the interfaces as the page needs them
... better organization of identifiers across various hosts

`import { ... } from "js:Temporal";`

the trick here is that there is a namespace:modulename import string. TC39 reserves the "js" namespace.

(at the moment the import string takes a URL)

namespace: module implies it is a built-in module and doesn't need to go to the network

Namespaces are managed by standards - there will be some form of governance, decided by the stakeholders

diagram of example modules for "web", "node" and "embedded" also being inside the "js" namespace.

you can imagine an example where "web" wants to put something in that isn't relevant to all of JS (e.g. dialog element - requires a browser)

the process would be that whomever manages the "web" module would tell TC39 the feature is being added. loose governance.

we want things to be easy to find and obvious to determine origin

trying to avoid the issue where "web" and "node" (for example) to both make features with the same name but are not identical

instead they should work together and create a new shared namespace

there is also the concept of aliasing, where a namespace can expose a feature from another namespace, with the same name. they'd still do it in a new shared module.

dino: doesn't this create the risk of exponential namespace explosion, with every combination of joint namespaces

devin: there are not many namespaces

jaffathecake: ??? (missed sorry)

JakeArchibald: It won't be the case that all browsers implement everything under the namespace though.

rickbyers: isn't this very similar to vendor prefixing?

drousso: there is the concept of vendor namespaces. considered private for experimentation.
... this is one reason why we have aliases. it could eventually move into standardisation.

rickbyers: I am skeptical that it will work. all it takes is for one big site to say "i like vendor:foo and will use it" and it effectively becomes a standard

domenic: we have removed support for built-in modules from the import maps spec because of the controversy around built-in modules

YukataHirano: I think that namespaces are there just to avoid conflicts.

<tomayac> s/Till/Yutaka Hirano/

drousso: we're trying to provide some meaning to names. if there are two implementations of "url" you have to decide which to use

YukataHirano: but we could solve that with a global namespace

drousso: but then it's not clear where you can use the module. e.g. is url available when using node.js?

RickByers: It sounds like your goal is to be able to reason about the ownership of the API.

drousso: it's more about the origin of the API, rather than the ownership.

RickByers: It makes more sense in TC39, but less sense for the Web because there is no real owner.

till: (mozilla) you talk about aliasing. how do you see it evolving? if now other namespaces want to alias to an already shared namespace.

<till> indeed

drousso: that is an expected effect. at some point you might want to talk to TC39

Michael Saboff (via phone): for the web, idea is that we could come up with some cross-group governance formed from parties who are interested

Till's comment is that aliasing is new. It is unchanged from the original proposal. We hope they are exceptional and provide a way for modules to move between namespaces.

Till: What is new is the introduction of a shared namespace for the location of the aliasing.
... before that it would be aliases into the copied namespace

drousso: takeaways - consider built-in modules instead of window interface
... even proposals that are in development
... open communication between stakeholders and other namespaces. Does your new feature make sense in other namespaces (beyond the web)?
... use good names

Current proposal is at https://github.com/tc39/proposal-javascript-standard-library

heycam: You mentioned freezing. When modules are imported into global, what does that mean?

drousso: the idea is that once it is frozen, you can't add to it. If we allowed that the import process can be broken.
... there can be exceptions, but in general it is not changed.

Michael: Obviously the implementation can change. But the exports are not. You can polyfill and change behaviour.
... We could have non-breaking additions as a module evolves.

heycam: slightly concerned we will end up with "url", "url2"...

rickbyers: e.g. we often add new methods. how would that work?

Michael: as long as they are non-breaking, it might be ok. We're still discussing it. It should be possible to use a new version as long as it is backwards compatible you'd feature detect the new version.

RickByers: How do you handle organic evolution? W3C might define something. WICG or WHATWG do it slightly different. Does this require a gatekeeper to own the module?

drousso: from TC39's perspective the only gatekeeper is the global namespace.

RickByers: So no-one can extend a module they don't own.

Michael: There can be multiple stakeholders. And different processes. e.g. npm is just a PR and commit. W3C is a more strict process.
... W3C and WHATWG would need to come up with rules.
... if you do it in your private namespace, then you can import and extend, and then propose back to the originator.

???: (Igalia) I worked on node modules. There was a requirement that it be in a specification first, and tests available. I think it would be a good idea to have governance and rules in place before adding anything

s/\?\?\?/Joye/

drousso: we don't want TC39 to be the gatekeeper, other than to avoid pollution.
... once it is in the registry, it's up to you

reillyg: In the previous discussion, static maps was mentioned. It seems dynamic import is not supported by built-in modules.

is that correct?

MichaelSaboff: it is supported, just wasn't in the example.

reillyg: I was worried that you could not detect. Thanks.

drousso: anywhere you can use a module you can use a built-in module

Jeremy: (Google) you said all the built-in modules are frozen. Does that mean you can't polyfill new features?

drousso: it doesn't create a frozen JS object, just that the API is locked

Michael: You can definitely import something, polyfill onto it, and use it. The built-in module is untouched.

Jeremy: But how does that work? Is the prototype module untouched?
... e.g. you have a constructer that has the same prototype in all instances, or it doesn't. How does that work?

Michael: This is an issue. You have built-in "foo". You want to make "foo-prime". You import "foo" and wrap it, then expose it as a different name. Any import of "foo-prime" gets that instance. A third party module that itself imports foo will not get your enhanced version

Jeremy: sounds inconvenient. e.g. I make a better url, but I can't pass that on to other things that expect a url.

drousso: the idea is that you absolutely know what you're getting.

Jeremy: the tradeoff is not the same way the web has worked

Domenic: the issue here is that it is changing the way we've been doing things for years, and the global namespace has worked pretty well. We should continue to do it IMO.

<jbroman> (for the log: Jeremy == me == Jeremy Roman)

RickByers: Agree. I think this is Google's position. We don't want things to be as locked down - we can solve some disagreements via polyfills for example. It risks a lot of the properties of openness on the web.

Michael: This wouldn't be one body controlling. Different stakeholders have different processes. We're trying to avoid bloat on the window object, and it makes things that TC39 want to do harder.

Domenic: The global `this` is the only example of this so far. I don't think this proposal solves it.

RickByers: I like that it makes it easier to use longer names. e.g. import a long name as a short name. You might want to get rigour without the guarantees. e.g. aliasing
... i.e. you can get the benefits without the idea of governance

Domenic: yes. it comes back to what we're trying to solve. if it is pollution, there are other solutions e.g. namespaces

DominicFarolino: (Google) I don't really see how the strict version work. you could have a shared url between implementations, but node decided to implement the new features. You'd end up having to version check everything.

drousso: the idea is that all the stakeholders would agree

RickByers: this is scary to us. it means that things can only evolve if everyone agrees at the pace of the slowest person.

Michael: this is the current situation on the Web anyway
... we
... we're working on how to do version checking
... even if everyone agrees it will appear in the platform at different times

DomenicFarolino: It's just that it isn't really a guarantee on the primordial version.

Michael: the claim on primordial is just that if you import "foo" you'll always get the actual version, not one that has been polyfilled.

it can be from any version

reillyg: You mentioned earlier that there is the opportunity to reduce memory use... is there any potential plan for moving existing APIs into modules so they could be left off the window object.

s/\./?/

Michael: hard to do without breaking

Domenic: we've been experimenting. it isn't clear how or if there are benefits.

drousso: please give feedback to TC39

------- end -------

<denis> RRSAgent: make minutes

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/???/YukataHirano/
FAILED: s/\?\?\?/Yutaka Hirano/
Succeeded: s/jaffathecake/JakeArchibald/
Succeeded: s/???/till/
Succeeded: s/\?\?\?/Till/
Succeeded: s/s g/s-g/
FAILED: s/\?\?\?/Joye/
Succeeded: s/RileyGrant/reillyg/
Succeeded: s/Riley/reillyg/
Succeeded: s/Domenic2/DominicFarolino/
FAILED: s/\./?/
Succeeded: s/Riley/reillyg/
Present: hober drousso Reilly_Grant Google_LLC prushforth
Found ScribeNick: dino
Found ScribeNick: dino
Inferring Scribes: dino

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)