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