IRC log of jsbuiltin on 2019-09-18
Timestamps are in UTC.
- 01:40:52 [RRSAgent]
- RRSAgent has joined #jsbuiltin
- 01:40:52 [RRSAgent]
- logging to https://www.w3.org/2019/09/18-jsbuiltin-irc
- 01:41:15 [dom]
- RRSAgent, make log public
- 01:48:01 [dom]
- Meeting: JS Built-In Modules
- 01:52:17 [drousso]
- drousso has joined #jsbuiltin
- 01:54:17 [masonfreed]
- masonfreed has joined #jsbuiltin
- 01:56:13 [tomayac]
- tomayac has joined #jsbuiltin
- 01:57:22 [dom]
- dom has joined #jsbuiltin
- 01:57:50 [denis]
- denis has joined #jsbuiltin
- 01:58:53 [jbroman]
- jbroman has joined #jsbuiltin
- 02:01:12 [hober]
- hober has joined #jsbuiltin
- 02:02:07 [hober]
- ScribeNick: dino
- 02:02:11 [hober]
- present+
- 02:02:16 [hober]
- present+ drousso
- 02:02:43 [yos]
- yos has joined #jsbuiltin
- 02:02:43 [hyojin]
- hyojin has joined #jsbuiltin
- 02:02:45 [reillyg]
- reillyg has joined #jsbuiltin
- 02:02:49 [dino]
- dino has joined #jsbuiltin
- 02:02:56 [dino]
- scribenick: dino
- 02:03:29 [dino]
- drousso: I'm here to talk about JS Built-in modules, speaking for some Apple members of the TC39 group
- 02:04:06 [dino]
- drousso: Goals: provide common functionality that appears as if it is built-in. We don't want to keep polluting the window namespace.
- 02:04:37 [dino]
- drousso: also allows browsers to reduce memory by only creating the interfaces as the page needs them
- 02:04:44 [shaoboyan]
- shaoboyan has joined #jsbuiltin
- 02:05:02 [dino]
- drousso: better organization of identifiers across various hosts
- 02:05:04 [pmdartus_]
- pmdartus_ has joined #jsbuiltin
- 02:05:28 [dino]
- `import { ... } from "js:Temporal";`
- 02:05:59 [dino]
- the trick here is that there is a namespace:modulename import string. TC39 reserves the "js" namespace.
- 02:06:15 [dino]
- (at the moment the import string takes a URL)
- 02:06:38 [dino]
- namespace:module implies it is a built-in module and doesn't need to go to the network
- 02:07:15 [dino]
- Namespaces are managed by standards - there will be some form of governance, decided by the stakeholders
- 02:08:38 [dino]
- diagram of example modules for "web", "node" and "embedded" also being inside the "js" namespace.
- 02:09:09 [Zakim]
- Zakim has joined #jsbuiltin
- 02:09:10 [dino]
- 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)
- 02:09:17 [hober]
- q?
- 02:09:55 [dino]
- the process would be that whomever manages the "web" module would tell TC39 the feature is being added. loose governance.
- 02:10:07 [hiroshige]
- hiroshige has joined #jsbuiltin
- 02:10:11 [nhiroki]
- nhiroki has joined #jsbuiltin
- 02:10:22 [dino]
- we want things to be easy to find and obvious to determine origin
- 02:11:00 [dino]
- trying to avoid the issue where "web" and "node" (for example) to both make features with the same name but are not identical
- 02:11:15 [dino]
- instead they should work together and create a new shared namespace
- 02:12:25 [dino]
- 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.
- 02:12:31 [heycam]
- heycam has joined #jsbuiltin
- 02:13:26 [dino]
- dino: doesn't this create the risk of exponential namespace explosion, with every combination of joint namespaces
- 02:13:27 [shimazu]
- shimazu has joined #jsbuiltin
- 02:13:35 [dino]
- devin: there are not many namespaces
- 02:14:24 [dino]
- jaffathecake: ??? (missed sorry)
- 02:14:53 [dino]
- jaffathecake: It won't be the case that all browsers implement everything under the namespace though.
- 02:15:05 [dino]
- rickbyers: isn't this very similar to vendor prefixing?
- 02:16:05 [dino]
- drousso: there is the concept of vendor namespaces. considered private for experimentation.
- 02:16:50 [sanketj]
- sanketj has joined #jsbuiltin
- 02:17:00 [dino]
- drousso: this is one reason why we have aliases. it could eventually move into standardisation.
- 02:17:46 [dino]
- 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
- 02:18:06 [kinuko_]
- kinuko_ has joined #jsbuiltin
- 02:18:18 [dino]
- domenic: we are removing the support for import maps from blink because they were not a solution to built-in modules
- 02:18:51 [dino]
- ???: I think that namespaces are there just to avoid conflicts.
- 02:19:01 [annevk]
- annevk has joined #jsbuiltin
- 02:19:07 [jacksteinberg]
- jacksteinberg has joined #jsbuiltin
- 02:19:11 [danclark]
- danclark has joined #jsbuiltin
- 02:19:13 [dino]
- s/???/YukataHirano/
- 02:19:30 [tomayac]
- s/\?\?\?/Yutaka Hirano/
- 02:19:46 [till]
- till has joined #jsbuiltin
- 02:20:08 [dino]
- drousso: we're trying to provide some meaning to names. if there are two implementations of "url" you have to decide which to use
- 02:20:20 [majidvp]
- majidvp has joined #jsbuiltin
- 02:20:21 [dino]
- YukataHirano: but we could solve that with a global namespace
- 02:20:36 [rbyers]
- rbyers has joined #jsbuiltin
- 02:20:40 [dino]
- drousso: but then it's not clear where you can use the module. e.g. is url available when using node.js?
- 02:21:12 [dino]
- s/jaffathecake/JakeArchibald/
- 02:21:46 [dino]
- RickByers: It sounds like your goal is to be able to reason about the ownership of the API.
- 02:21:57 [dino]
- drousso: it's more about the origin of the API, rather than the ownership.
- 02:22:19 [dino]
- RickByers: It makes more sense in TC39, but less sense for the Web because there is no real owner.
- 02:22:58 [pmdartus_]
- pmdartus_ has joined #jsbuiltin
- 02:23:04 [dino]
- ???: (mozilla) you talk about aliasing. how do you see it evolving? if now other namespaces want to alias to an already shared namespace.
- 02:23:08 [heycam]
- s/???/till/
- 02:23:17 [till]
- indeed
- 02:23:27 [dino]
- drousso: that is an expected effect. at some point you might want to talk to TC39
- 02:23:37 [dino]
- s/\?\?\?/Till/
- 02:24:46 [cb]
- cb has joined #jsbuiltin
- 02:25:08 [dino]
- 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
- 02:25:19 [dino]
- s/s g/s-g/
- 02:26:25 [dino]
- 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.
- 02:26:41 [dino]
- Till: What is new is the introduction of a shared namespace for the location of the aliasing.
- 02:26:54 [dontcallmeDOM]
- dontcallmeDOM has joined #jsbuiltin
- 02:26:58 [dino]
- till: before that it would be aliases into the copied namespace
- 02:28:14 [dino]
- drousso: takeaways - consider built-in modules instead of window interface
- 02:28:25 [dino]
- drousso: even proposals that are in development
- 02:29:19 [dino]
- drousso: open communication between stakeholders and other namespaces. Does your new feature make sense in other namespaces (beyond the web)?
- 02:29:26 [dino]
- drousso: use good names
- 02:30:14 [dino]
- Current proposal is at https://github.com/tc39/proposal-javascript-standard-library
- 02:30:44 [dino]
- heycam: You mentioned freezing. When modules are imported into global, what does that mean?
- 02:31:04 [bashi]
- bashi has joined #jsbuiltin
- 02:31:08 [dino]
- 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.
- 02:31:32 [dino]
- drousso: there can be exceptions, but in general it is not changed.
- 02:31:59 [dino]
- Michael: Obviously the implementation can change. But the exports are not. You can polyfill and change behaviour.
- 02:32:39 [dino]
- Michael: We could have non-breaking additions as a module evolves.
- 02:33:01 [dino]
- heycam: slightly concerned we will end up with "url", "url2"...
- 02:33:17 [dino]
- rickbyers: e.g. we often add new methods. how would that work?
- 02:34:06 [dino]
- 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.
- 02:34:54 [dino]
- 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?
- 02:35:20 [dino]
- drousso: from TC39's perspective the only gatekeeper is the global namespace.
- 02:35:34 [dino]
- RickByers: So no-one can extend a module they don't own.
- 02:36:11 [dino]
- Michael: There can be multiple stakeholders. And different processes. e.g. npm is just a PR and commit. W3C is a more strict process.
- 02:36:39 [dino]
- Michael: W3C and WHATWG would need to come up with rules.
- 02:36:55 [dino]
- Michael: if you do it in your private namespace, then you can import and extend, and then propose back to the originator.
- 02:37:49 [dino]
- ???: (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
- 02:38:24 [dino]
- s/\?\?\?/Joye/
- 02:38:45 [flaki]
- flaki has joined #jsbuiltin
- 02:38:46 [dino]
- drousso: we don't want TC39 to be the gatekeeper, other than to avoid pollution.
- 02:39:03 [dino]
- drousso: once it is in the registry, it's up to you
- 02:39:36 [dino]
- RileyGrant: In the previous discussion, static maps was mentioned. It seems dynamic import is not supported by built-in modules.
- 02:39:40 [dino]
- is that correct?
- 02:39:53 [dino]
- MichaelSaboff: it is supported, just wasn't in the example.
- 02:40:05 [dino]
- Riley: I was worried that you could not detect. Thanks.
- 02:40:22 [dino]
- drousso: anywhere you can use a module you can use a built-in module
- 02:40:32 [reillyg]
- s/RileyGrant/reillyg/
- 02:40:36 [reillyg]
- s/Riley/reillyg/
- 02:40:53 [reillyg]
- present+ Reilly Grant, Google LLC
- 02:41:00 [dino]
- Jeremy: (Google) you said all the built-in modules are frozen. Does that mean you can't polyfill new features?
- 02:41:25 [dino]
- drousso: it doesn't create a frozen JS object, just that the API is locked
- 02:42:04 [dino]
- Michael: You can definitely import something, polyfill onto it, and use it. The built-in module is untouched.
- 02:42:23 [dino]
- Jeremy: But how does that work? Is the prototype module untouched?
- 02:42:56 [dino]
- Jeremy: e.g. you have a constructer that has the same prototype in all instances, or it doesn't. How does that work?
- 02:44:28 [dino]
- 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
- 02:44:53 [dino]
- Jeremy: sounds inconvenient. e.g. I make a better url, but I can't pass that on to other things that expect a url.
- 02:45:21 [Berwin]
- Berwin has joined #jsbuiltin
- 02:45:32 [dino]
- drousso: the idea is that you absolutely know what you're getting.
- 02:46:15 [dino]
- Jeremy: the tradeoff is not the same way the web has worked
- 02:46:51 [dino]
- 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.
- 02:47:29 [jbroman]
- (for the log: Jeremy == me == Jeremy Roman)
- 02:47:58 [dino]
- 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.
- 02:49:03 [dino]
- 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.
- 02:49:38 [dino]
- Domenic: The global `this` is the only example of this so far. I don't think this proposal solves it.
- 02:50:40 [dino]
- 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
- 02:51:03 [dino]
- RickByers: i.e. you can get the benefits without the idea of governance
- 02:51:33 [dino]
- Domenic: yes. it comes back to what we're trying to solve. if it is pollution, there are other solutions e.g. namespaces
- 02:52:39 [dino]
- Domenic2: (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.
- 02:52:56 [dino]
- drousso: the idea is that all the stakeholders would agree
- 02:53:02 [drousso_]
- drousso_ has joined #jsbuiltin
- 02:53:36 [dino]
- RickByers: this is scary to us. it means that things can only evolve if everyone agrees at the pace of the slowest person.
- 02:53:51 [dino]
- Michael: this is the current situation on the Web anyway
- 02:53:58 [dino]
- Michael: we
- 02:54:09 [dino]
- Michael: we're working on how to do version checking
- 02:54:24 [reillyg]
- s/Domenic2/DominicFarolino/
- 02:54:34 [prushforth]
- prushforth has joined #jsbuiltin
- 02:54:37 [dino]
- Michael: even if everyone agrees it will appear in the platform at different times
- 02:54:46 [prushforth]
- present+
- 02:55:05 [dino]
- DomenicFarolino: It's just that it isn't really a guarantee on the primordial version.
- 02:55:33 [dino]
- 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.
- 02:55:38 [dino]
- it can be from any version
- 02:57:00 [berwin]
- berwin has joined #jsbuiltin
- 02:57:51 [dino]
- Riley: 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.
- 02:57:58 [dino]
- s/\./?/
- 02:58:01 [reillyg]
- s/Riley/reillyg/
- 02:58:25 [dino]
- Michael: hard to do without breaking
- 02:58:46 [dino]
- Domenic: we've been experimenting. it isn't clear how or if there are benefits.
- 02:59:05 [dino]
- drousso: please give feedback to TC39
- 02:59:08 [dino]
- ------- end -------
- 02:59:18 [denis]
- RRSAgent: make minutes
- 02:59:18 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/18-jsbuiltin-minutes.html denis
- 03:01:59 [shimazu]
- shimazu has joined #jsbuiltin
- 03:10:43 [denis]
- denis has joined #jsbuiltin
- 03:57:23 [denis]
- denis has joined #jsbuiltin
- 04:29:39 [dontcallmeDOM]
- dontcallmeDOM has joined #jsbuiltin
- 04:34:06 [drousso]
- drousso has joined #jsbuiltin
- 04:34:44 [shimazu]
- shimazu has joined #jsbuiltin
- 04:34:59 [dino]
- dino has joined #jsbuiltin
- 04:40:29 [denis]
- denis has joined #jsbuiltin
- 04:43:46 [dom]
- dom has left #jsbuiltin
- 04:52:37 [dino]
- dino has joined #jsbuiltin
- 05:16:45 [shimazu]
- shimazu has joined #jsbuiltin
- 05:19:18 [dino]
- dino has joined #jsbuiltin
- 05:22:15 [Zakim]
- Zakim has left #jsbuiltin
- 05:31:33 [drousso]
- drousso has joined #jsbuiltin
- 05:33:52 [tomayac]
- tomayac has joined #jsbuiltin
- 05:34:17 [dino]
- dino has joined #jsbuiltin
- 05:34:34 [dino]
- dino has joined #jsbuiltin
- 05:36:44 [shimazu]
- shimazu has joined #jsbuiltin
- 05:37:51 [denis]
- denis has joined #jsbuiltin
- 06:32:04 [shimazu]
- shimazu has joined #jsbuiltin
- 06:32:48 [reillyg]
- reillyg has left #jsbuiltin
- 06:49:14 [hiroshige]
- hiroshige has joined #jsbuiltin
- 06:51:10 [hiroshige]
- As for import maps in Blink: we are going to remove "built-in modules support" (e.g. fallbacks) in import maps in Blink (not entire import maps support).
- 06:51:50 [kinuko]
- kinuko has joined #jsbuiltin
- 06:59:01 [denis]
- denis has joined #jsbuiltin
- 07:31:55 [drousso]
- drousso has joined #jsbuiltin
- 07:33:55 [annevk]
- annevk has joined #jsbuiltin
- 07:34:53 [shimazu]
- shimazu has joined #jsbuiltin
- 07:35:22 [dino]
- dino has joined #jsbuiltin
- 08:27:33 [shimazu]
- shimazu has joined #jsbuiltin
- 08:30:35 [drousso]
- drousso has joined #jsbuiltin
- 08:31:08 [drousso]
- drousso has joined #jsbuiltin
- 08:33:04 [dino]
- dino has joined #jsbuiltin
- 08:49:36 [shimazu]
- shimazu has joined #jsbuiltin
- 08:58:05 [shimazu]
- shimazu has joined #jsbuiltin
- 09:19:40 [hyojin]
- hyojin has left #jsbuiltin