[samschooler]

This seems like a good step with import maps. Especially following web standards. I like the idea behind jsr, however I'm interested in how they will be integrating additional specifiers. I don't philosophically like having hard coded [0] strings vs smart redirect urls. I'd be interested why jsr couldn't have used standard smart semver following 301s to dynamically load packages, combined with an import map lock file.

For example:

`import { assertEquals } from "jsr:@std/assert@1";`

could be:

`import { assertEquals } from "jsr.io/std@1/assert";`

With this deno could assume https, as well as follow configs/redirects to get the correct import, then lock those correct paths using import maps (the logistics of this would need hashing out, but it doesn't seem impossible considering they do it with the "special" `jsr:` specifier).

It seems like this would maintain the same pros while avoiding the "special" specifier hard coding that exists now (seems to only be for npm: and jsr: right now; no github: for example).

[0]: https://github.com/denoland/deno/blob/8c2f1f5a55a2a9bb9e04c1...

[skybrian]

There is still a problem with unreliable hosts. They might be temporarily down, or they might change the source code under you.

Although that's pretty rare, it's a security vulnerability that we're more wary of nowadays due to supply-chain attacks. You still have to check new releases, but it would be even worse if old, widely used code were modified to mine crypto or something.

Go ran into a similar problem because 'go get' would import directly from source control systems. For GitHub that's mostly fine, but other hosts are sometimes less reliable. They solved it with a indexing proxy server. You can still turn it off and download directly from source control, or swap in your own proxy server, so it's less centralized than jsr.io.

In practice, most people use the default proxy server, so on most days, jsr.io should work just as well as Go's solution. But it's nice to have alternatives.