[wperron]

If you actually read the (admittedly long) thread, it's pretty clear that those imports are not resolved at runtime, and Deno has never evaluated imports at runtime either. Dependencies get evaluated and downloaded prior to startup, very similar to Go in fact.

[CGamesPlay]

I don't see that listed anywhere in the thread, so I'll ask here instead:

Does prior to startup mean there's a separate build step, or are you saying it happens during the loading of the script. I'm pretty confident that the latter is what deno was doing, although I'm happy to be proven wrong.

Are dynamic imports simply disallowed? Since it is impossible to download in advance a script to which you don't know the URL without running the program, they'd have to be, in order for your assertion to be true.

[wperron]

The whole conversation is a bit hard to follow, there was an issue initially, then this PR and then another Discussion that's linked somewhere in the PR. I'll let you go read those, I don't recall exactly what decisions were taken and what's the roadmap for this to become stable.

Dynamic imports are... wild, to say the least. Unfortunately they will always be inherently harder to secure, and will most likely always be treated differently than static import statements. At least that was the consensus in Deno.

[danShumway]

ES imports on the web have a lot of restrictions around where they can be placed in code. Trying to pass a variable in for the path results in a syntax error. There are basically a lot of syntax requirements that make it basically impossible to do imports that aren't statically analyzable without the need to run the code.

However, given that ES imports are basically trying as hard as possible to be explicitly defined static imports that can be analyzed ahead of time before code is run -- it prompts the question, why would you ever choose to use that system in a native environment where you could have have an explicit install step?

ES Imports are trying very hard to imitate what Node already has, and I can't figure out what the advantage is of building an import system that imitates dynamic imports, but isn't dynamic. My understanding was that Deno went that direction just to make webpack bundling easier and to decrease the amount of new syntax. I felt like that was not great reasoning at the time, but I sort of get it.

But note that when I look at Deno's docs[0], the first paragraph I see says:

> One convention places all these dependent URLs into a local deps.ts file. Functionality is then exported out of deps.ts for use by local modules.

> Continuing this convention, dev only dependencies can be kept in a dev_deps.ts file.

It's almost like Deno is advising developers to put their dependencies in (just trying to come up with a random descriptive term off the top of my head) a package file. Next, wouldn't be it be great if that list of dependencies could also specify other things like a set of common scripts, or instructions on how to run the program if it's imported? There's potentially a really good concept embedded in those docs.

Deno was made by smart people, and it was made by smart people who also created Node and are intimately familiar with it. So I don't want to be dismissive because I'm sure they had some reasons for this, but I don't understand why any of this exists or who it benefits, or why the syntax is exciting given that Deno itself seems to be immediately advising people not to use it directly.

----

[0]: https://deno.land/manual/examples/manage_dependencies