Re: [w3ctag/design-reviews] <link> rel="modulepreload" (#213)

> and wondered what you think the relationship is between the two?

I think they're _mostly_ orthogonal, but I agree it's tempting to stretch package name maps (now renamed import maps) to cover similar cases. In particular:

> If you have to list out a set of module URLs to preload, why do both this + a package name map? (Assuming both concepts land)

Import maps are not about loading at all. They're about how to translate certain strings into HTTP(S) URLs.

In particular, the format used for specifying this string -> URL translation cannot be used to derive an exhaustive list of the URLs of all modules in an app. This is for two reasons:

- Only some strings need translation into URLs. That is, the only URLs that will appear within an import map are those that you want to address by a "bare import specifier", which will be a subset of an application. Roughly speaking, based on our experience with the npm ecosystem, third party libraries are more likely to be addressed in this way, whereas the application code will not be.

- The translation format has an important shorthand that allows you to map a specifier prefix to a URL prefix, e.g. you could map `lodash/` to `https://unpkg.com/lodash/`. But, a potentially unlimited number of URLs could be derived from this mapping. That is, the import map format just provides a rule, not any concrete instances.

> the package name map probably is a superset of the things that might want to be preloaded. Would it makes sense to add the concept of "please preload" to the package name map as well (possibly instead of modulepreload)?

As explained above, it would probably end up being a subset, or perhaps just overlapping.

We could say that, for the subset of modules that appear by explicit URL in the module map, there could be a hint added to the module map to preload them. (Or, browsers may want to do so anyway, without an explicit hint.) But, given that we'd still need modulepreload for other cases, I'd be hesitant to add this. It seems nicer to keep the preloading and string -> URL translation mechanisms separate. Thoughts welcome.

> clearly the package name map can specify subresources of resources. However, not everything requested by the module graph need be in the package name map. So, from that standpoint, perhaps the use-cases are sufficiently different that the two concepts aren't as synonymous as I thought?

Exactly :)


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/213#issuecomment-437480306