link instead of script?

[bmeck]

Is there a specific reason for the use of <script> instead of <link>? The only reason I can think of is the HTTP Header support that comes with <link>, but am unsure what is problematic about that.

[matthewp]

With <link> you couldn't inline the map in the HTML. You could put it in a header but many servers have size limits on headers that the package map might exceed.

[matthewp]

I take that back, looks like the typical size limit is 8k, I doubt a packagemap would exceed that. I had thought the limit was smaller.

[bmeck]

@matthewp if the link header is mostly a href I don't think it likely to exceed the size limits. Per inlining into the document, I'm not sure if a precomputed workflow like this is as desirable to output back into inline HTML for most situations. If desirable to inline we could certainly support both ways to load things, similar to CSS.

I somewhat still question if inlining is going to be more desirable than linking since you will be doing many resource requests most likely as the README states. Inlining can help with initial load, but could cause fewer cache hits on the initial document load if the package name map changes over time. In particular, being unable to load updated package name maps after initial load means that any changes would require a refresh in order to be synced up. Hopefully, we can find a workflow where package name maps change rarely; I am unsure of that being realistic.

[matthewp]

Good point about cache hits. For a lot (but not all) sites, caching isn't used on documents as they tend to be dynamic. I'm concerned about using hrefs with http/1.1 servers though. The packagemap is a super-dependency of all modules, so it will block the preload scanner from doing its job.

[justinfagnani]

We considered both, but started with <script> because of inlining, and not wanting to have two ways to do the same thing.

[matthewp]

@justinfagnani I'm curious about this:

Adding a second <script type="packagemap"> has no effect.

Should we be concerned that a large packagemap will block scripts from loading? One case where you might want multiple packagemaps would be if you wanted to put essential, above-the-fold scripts into its own tree and then defer the rest for later. For example:

<script type="packagemap">
  [ESSENTIAL MAPPING HERE]
</script>
<script type="module" src="./main.js"></script>

<main> ... </main>

<script type="packagemap">
  [NON-ESSENTIAL MAPPING HERE]
</script>
<script type="module" src="./less-important.js"></script>

The question being whether a packagemap is ever big enough where splitting would be desired. I understand that allowing multiple maps starts to raise conflict resolution problems...

[justinfagnani]

I hope that can be explored more, and my team has asked for it. I understand that there might be blockers, but maybe there's some way to figure it out.

[justinfagnani]

btw, this is a dupe of #1

[domenic]

Hmm, I really tried to pre-empt this by pre-filing #1. Let's please continue discussion there? Some good points have been raised so far though!

[bmeck]

@domenic I'm not sure this fits in either #1 or #2 since the link: header could apply to both.

[domenic]

Well, I agree the issues slightly bleed over, but since #1 is where <script> is the existing proposal, we'd need to establish that link is good enough or better for the window context before considering it for the worker context.