Intent to Implement: JavaScript module import()

Skip to first unread message

Sathya Gunasekaran

Jul 5, 2017, 8:04:08 PM7/5/17
to blink-dev, v8-users

Contact emails

V8 implementation:

Blink implementation:



JavaScript side:

This is a stage 3 proposal, which per the TC39 process is the appropriate time to implement (and ship).

Web side:

This is a (detailed) draft which will be integrated into HTML shortly.


import() is an addition to the JavaScript module system which allows dynamic importing of modules, as opposed to the static/declarative importing provided by the import declaration. It is a new JavaScript "function-like" syntactic form, similar to super().



The existing syntactic forms for importing modules are static declarations. They accept a string literal as the module specifier, and introduce bindings into the local scope via a pre-runtime "linking" process. This is a great design for the 90% case, and supports important use cases such as static analysis, bundling tools, and tree shaking.

However, it's also desirable to be able to dynamically load parts of a JavaScript application at runtime. This could be because of factors only known at runtime (such as the user's language), for performance reasons (not loading code until it is likely to be used), or for robustness reasons (surviving failure to load a non-critical module). Such dynamic code-loading has a long history, especially on the web, but also in Node.js (to delay startup costs). The existing `import` syntax does not support such use cases.

Truly dynamic code loading also enables advanced scenarios, such as racing multiple modules against each other and choosing the first to successfully load.


Today this is also possible via dynamically creating and inserting <script type="module"> elements. However, this has a number of disadvantages. See for more information on that comparison.

Interoperability and Compatibility Risk

This is a mature feature in the TC39 process, implying at least support from at least all JavaScript engine teams at each browser. We anticipate it being implemented rapidly, either alongside initial implementations of JavaScript modules or shortly thereafter.

Edge: Public support

Firefox: Public support

Safari: Shipped in Safari Tech Preview

Web developers: Positive

Ongoing technical constraints


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?


OWP launch tracking bug

Link to entry on the feature dashboard

Requesting approval to ship?

Not yet, but hopefully soon!

Zac Hansen

Jul 5, 2017, 10:56:09 PM7/5/17
to v8-users,
Is this related, in any way, to ?

Will this documentation be updated as a part of this implementation, if appropriate?

Sathya Gunasekaran

Jul 6, 2017, 1:48:32 PM7/6/17
to v8-users, blink-dev
On Wed, Jul 5, 2017 at 7:56 PM, Zac Hansen <> wrote:
> Is this related, in any way, to
> ?
> Will this documentation be updated as a part of this implementation, if
> appropriate?

The relevant documentation is here:

The tracking bug for V8
( has more
information (including a design doc).

Jul 6, 2017, 2:37:33 PM7/6/17
to blink-dev,,, Eric Lawrence, Mike West, Artur Janc
This is a good opportunity to get more strict about content type validation.

It looks like the current behavior in Chrome is that specific media content types (png, etc.) will not be loaded as script, but other non-script types (at least application/octet-stream and text/plain) will load as script.

I'd like to propose that import() switch to an allow-list strategy.  Since import() is a new API, we have the ability to lock down here without breaking existing sites.  Maybe it's not too late to do the same with the import statement as well.

Would it be appropriate to include the allow-list requirement in either of the specs associated with this intent to implement?

I bounced this around some web security folks within Google and there is agreement that an allow-list would be a good thing.  Also, from Eric Lawrence:
Mike West sounds on board; he'd made the original fix which blocks image/*.

Adam Klein

Jul 6, 2017, 3:09:00 PM7/6/17
to, blink-dev, v8-users, Sathya Gunasekaran, Eric Lawrence, Mike West, Artur Janc
Good news: this is already part of the spec (and this implementation).

For module scripts (loaded either via <script type=module>, an import declaration in a module script, or via this new import() API), the HTML spec requires an appropriate JavaScript mime type. See step 7 for the spec text.

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit

David Ross

Jul 6, 2017, 6:55:29 PM7/6/17
to Adam Klein, blink-dev, Sathya Gunasekaran, Eric Lawrence, Mike West, Artur Janc
Nice.  Also, I found this test case on Jake Archibald's blog:
I'll close the bug.

Jul 7, 2017, 9:56:41 AM7/7/17
to blink-dev,,
Thanks for this resourceful tools, it' great to have you guys here. Zik Israel

Jul 16, 2017, 5:13:59 AM7/16/17
to blink-dev,,
On Thursday, 6 July 2017 18:48:32 UTC+1, Sathya Gunasekaran wrote:
The relevant documentation is here:

I think there's an error in the comment there: should read 'HostImportModuleDynamicallyCallback'
Reply all
Reply to author
0 new messages