TC39 considering standard/built-in ES modules

[kenchris]

https://github.com/tc39/Reflector/issues/153

[domenic]

That's a private link; I'm not sure sharing it publicly helps this repository very much.

[kenchris]

Ah, sorry, didn't notice it was private, sorry

[littledan]

Even aside from the private link, TC39 has been discussing adding built-in modules for some time. What's the relationship between this proposal and those efforts?

[domenic]

@littledan I'm not aware of any TC39 efforts toward built-in modules. I've seen individual committee members provide various opinions, but never anything from the committee itself.

Personally, as one of those committee members with his own opinion, I think TC39 should continue its long tradition of leaving how module specifiers map to JavaScript module records up to the host (HostResolveImportedModule etc.).

If TC39 changes their historical stance to something new that would impact the HostResolveImportedModule mappings we're proposing here, I'd be happy to collaborate with them and work through any such impacts.

[bterlson]

@domenic it would be helpful if you could help me find people other than yourself which think built-in modules are out of scope for TC39.

I have been very clear about my desire to work on this inside TC39, including bringing it up at past meetings and getting stage 1 over your objections. And again on the Reflector, tc39 members express a desire to work in this space, and your objections are the only objections. Help me find others!

Glad to hear you're willing to work with TC39 on this, though. Unless you know of other people objecting, let's assume TC39 wants to work on this and go from there?

[zenparsing]

@domenic I have a clarifying question (just link me somewhere if it's already been discussed or documented). What is the motivation for using the "built-in" namespace instead of URLs?

Just to make something up:

https://dom.js/async-local-storage

URLs already have all of the semantics that we need and browsers could (in principle) choose to "preload" resources from this magic domain for performance.

[matthewp]

@zenparsing the std: namespace from the examples are URLs. Try new URL('std:async-local-storage') in your dev console.

[zenparsing]

@matthewp As you probably have guessed, I mean a URL that I can type into the address bar and see something in the browser. 😄

[matthewp]

I hadn't guessed that. What would you expect to see exactly?

[zenparsing]

What would you expect to see exactly?

The source code for the module. I assume that it would be entirely equivalent to the response of the "fallback URL" in this proposal.

[matthewp]

So are you saying that dom.js would be a real domain controlled by whatever standards body owns this, and it would serve polyfills? Interesting idea.

If that's the case, what happens once the browser implements https://dom.js/async-local-storage? If you type it in the address bar do you continue to see the polyfill from the domain or do you see something else? Remember that these standards might be implemented in C++ or something other than JS.

Going a step further, what happens when you do fetch('https://dom.js/async-local-storage')? Does it fetch the built-in (not sure what that would even mean) or the remote resource?

[zenparsing]

If you type it in the address bar do you continue to see the polyfill from the domain or do you see something else?

You would still see the polyfill.

Remember that these standards might be implemented in C++ or something other than JS.

Ideally, an implementation written in C++ would not be observably different from the polyfill written in JS. From the developer's point of view a module implemented internally would simply look like a long-cached version of the polyfill.

There's probably a bunch of challenges with making a C++ implementation observably equivalent to a polyfill, though (or alternatively, a polyfill strictly equivalent to the spec). What are those challenges?

I can think of a couple:

• Debugging and the ability to step through layered API code
• On the polyfill side, being able to implement "internal slots" easily and efficiently

[domenic]

@bterlson we had a group call a while back where several TC39 members concurred with my opinion. I'll let them speak for themselves, as I don't really think it's great to try to assume things about TC39 based on any one person's opinion (either mine or yours).

@zenparsing I don't really see the advantage of using HTTP URLs that are magically redirected away from their hosting company to somewhere else, instead of using a separate scheme. As @matthewp points out, all HTTP URLs are fetch()able, which would be an unfortunate property to break (but we could not fulfill, since e.g. the implementation may be in C++, which is not something we want to return from a fetch()).

[littledan]

In the call we had in April 2018, I don't think we came to a solid conclusion here, and we didn't get around to publishing notes or giving a report to the TC39 plenary. Let's follow up with discussion in the July 2018 TC39 meeting to clarify committee feeling on built-in modules, and in particular, the question of how the specifier space should be allocated.