Difference between System.import() and import()?

Question

In webpack 1 docs is statement that in webpack 2 will use System.import() for dynamic require:

Luckily, there is a JavaScript API “loader” specification being written to handle the dynamic use case: System.load (or System.import). This API will be the native equivalent to the above require variations.

And during that time all around the web was examples of using this System.import().

---

Before releasing webpack 2, authors decide to change System.import() to import():

add import() as Code Splitting construct. It should be used instead of System.import when possible. System.import will be deprecated in webpack 2 release (removed in webpack 3) as it's behavior is incorrect according to the spec.

This import() is based on tc39/proposal-dynamic-import specification, and you can read more why they made this change here.

---

Can someone explain difference between System.import() and import()?

Despite different name, usage looks the same:

import(modulePath)
  .then(module => module.default())
  .catch(/* ... */);

System.import(modulePath)
  .then(module => module.default())
  .catch(/* ... */);

But in weback 2 doc is: "System.import() behavior is incorrect according to the spec" - so it suggest that there is difference between System.import() and import().

Answer 1

The important part of your first quote is

specification being written

When Webpack 1 implemented System.import, the spec was still evolving. If fact it still is. Webpack 1 implemented System.import because that was what was being tossed around as the potential API at the time.

Webpack 2 implements import() because that is a new proposal to standardize on a syntactic approach rather library-based one.

Answer 2

Here's what you're looking for: tc39 Proposal for Import

An actual function

Drafts of the Loader ideas collection have at various times had actual functions (not just function-like syntactic forms) named System.import() or System.loader.import() or similar, which accomplish the same use cases.

The biggest problem here, as previously noted by the spec's editors, is how to interpret the specifier argument to these functions. Since these are just functions, which are the same across the entire Realm and do not vary per script or module, the function must interpret its argument the same no matter from where it is called. (Unless something truly weird like stack inspection is implemented.) So likely this runs into similar problems as the document base URL issue for the importModule function above, where relative module specifiers become a bug farm and mismatch any nearby import declarations.