Re: [whatwg/fetch] preload, destinations, and module scripts (#486)

> Do we need the destination override given that https://github.com/dherman/esprit supposedly makes it possible to tell whether something is a module script or not?

@annevk if that is the thing dherman was referencing in his email, it is a custom parser that is attempting to implement a proposal that has been rejected by TC39 a couple times (where you add `"use module"` instead of using `type="module"`). It doesn't help this situation, which deals with standard JavaScript.

> Why can't rel=preload as=modulescript not work? 

@rniwa the above discussion goes into some fairly extensive detail on why rel=preload as=modulescript can't work, but I guess it was not summarized nicely for newcomers. Let me try. Here are the main reasons why rel=preload as=modulescript doesn't work.

- We need to populate the module map, not the preload cache/HTTP cache.
  - In particular, this means that the preload processing model, which e.g. re-fetches whenever various attributes change, does not make sense, since the module map is immutable.
- We need to fetch all the dependent modules, not just the single resource pointed to by the link tag; the processing model for rel=preload does not allow this.

You might then say, why don't we just patch the preload spec to do an "if `as` is `modulescript`, use a completely different processing model" fork? There are three issues with that:

- We'd actually need to do this for four different `as` values (modulescript, moduleworker, modulesharedworker, moduleserviceworker), which is fairly messy.
- This would break the 1:1 correspondence between as="" values and request destinations (i.e., modulescript would mean "module graph processing model with fetch destination script", not "preload processing model with fetch destination modulescript")
- In general people aren't happy with changing the meaning of preload="" so drastically; for different processing models, different rel=""s are appropriate.

> Are we going to add rel=prefecthmodule as well?

We could. However, since prefetch is only about hinting to the browser to populate the HTTP cache, a better solution might be something that expands the hint to ask for all subresources, e.g. HTML documents with images and CSS files with `@import`s, in addition to JavaScript files with `import`s. That was what I was saying with my tentative suggestion for an `includesubresources=""` attribute above. But I think we can separate that from preload, which is about a declarative fetch to make something ready for use by the page right now and thus has much more acute issues with modules.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/486#issuecomment-282044172