Contact emails V8 implementation: gsat...@chromium.org
Blink implementation: kou...@chromium.org Spec: dome...@chromium.org Spec JavaScript side: https://tc39.github.io/proposal-dynamic-import/ This is a stage 3 proposal, which per the TC39 process <https://tc39.github.io/process-document/> is the appropriate time to implement (and ship). Web side: https://github.com/tc39/proposal-dynamic-import/blob/master/HTML%20Integration.md This is a (detailed) draft which will be integrated into HTML <https://github.com/whatwg/html/issues/2315> shortly. Summary 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(). Motivation (From https://github.com/tc39/proposal-dynamic-import#motivation-and-use-cases) 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 https://github.com/tc39/proposal-dynamic-import#using-host-specific-mechanisms 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 <https://github.com/tc39/tc39-notes/blob/master/es7/2016-11/dec-1.md#14ii-import-open-issues-and-stage-3-discussion> Firefox: Public support <https://github.com/tc39/tc39-notes/blob/master/es7/2016-11/dec-1.md#14ii-import-open-issues-and-stage-3-discussion> Safari: Shipped <https://bugs.webkit.org/show_bug.cgi?id=166926> in Safari Tech Preview Web developers: Positive Ongoing technical constraints None. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes. OWP launch tracking bug https://crbug.com/711706 Link to entry on the feature dashboard <https://www.chromestatus.com/> https://www.chromestatus.com/feature/5684934484164608 Requesting approval to ship? Not yet, but hopefully soon! -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
