[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

[CGamesPlay]

> 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.

I'm referring to dynamic imports, which do not have any compunctions around dynamic strings being used to import modules. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[danShumway]

Right, sorry. My understanding was that dynamic imports were a separate conversation, and they're not part of this effort at the very least: https://github.com/nodejs/node/pull/36328#issuecomment-73590...

----

That being said, yes, if there are plans to support dynamic imports, then literally all of the reassurances people have been giving me about pinning and fetching dependencies ahead of time and having tools to find out-of-date dependencies -- none of that works at all if dynamic imports are supported, you're completely correct.

Deno does support dynamic imports, but I have always understood that they use a separate system and are handled/installed differently? I might be wrong about that though, I haven't worked with Deno closely enough to be really confident about its internals.