Which browsers support import and export syntax for ECMAScript 6?

Question

I am currently writing a web application using the MEAN Stack, and am attempting to write code in ECMAScript 6 JavaScript; however, I am getting errors in both Chrome and Firefox when using import and export syntax. Are there currently any browsers that fully support ECMAScript 6?

Please note: I am not asking when ECMAScript 6 will be supported by browsers. I'm asking which browsers support ECMAScript 6 import and export syntax. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla#Features_not_yet_supported_by_Firefox

Answer 1

Chrome and Firefox support import and export syntax (there exists tests for proper parsing).

What isn't supported is module loading - you can't load module by any means, because specification for it isn't complete. You have to use some kind of module bundler for this. I'm not front-end developer, but I have heard good opinions on Rollup from my coworkers.

Answer 2

It's supported in:

• Safari 10.1
• Chrome 61
• Firefox 54 – behind the dom.moduleScripts.enabled setting in about:config.
• Edge 16

Answer 3

Now there's a pollyfill that you can use to import ES6 module.

I tested it successfully on Chrome.

Here is the link: http://github.com/ModuleLoader/browser-es-module-loader

---

It is also implemented natively in Edge 14:

https://blogs.windows.com/msedgedev/2016/05/17/es6-modules-and-beyond

Answer 4

As others have said, support for it is still very limited. But even if there was full support.... would it be smart to use it? How would we do that?

Think about it. A typical JS app written with Node JS modules easily contains dozens, even hundreds of (very small) packages. Do we really want that many requests?

Browserify, Webpack, Rollup etc are so popular because they allow us to bundle many small packages into one fast download. With code splitting we can let the module bundler decide at transpilation time, based on the code our pages are actually using and on some configuration settings, how many bundles to create and what to put in each of them. That way we can write many small packages and serve them as a (couple of) big bundles.

My point is that we should divide our code into packages that work well on a conceptual level, then bundle those packages into bundles that work well on a technical (network) level. If we write our code based on optimum network packet size, we end up sacrificing modularity in the process.

In the meantime, using it will probably only add to the confusion. For example, look at the example on the Edge blog:

import { sum } from './math.js';

Note how they add the extension .js to the from string? In Node JS we usually write this as:

import { sum } from './math';

So will the above code also work on Edge? And what about named packages? I fear we will see a lot of incompatibility here before we figure out how to make these paths work across the board.

I would hazard to guess that for most developers, System.import will remain mostly invisible in the browsers and that only the bundling software itself will start to use it (for efficiency purposes) when it becomes mainstream.

Answer 5

According to Google's Javascript Style Guide:

Do not use ES6 modules yet (i.e. the export and import keywords), as their semantics are not yet finalized. Note that this policy will be revisited once the semantics are fully-standard.

// Don't do this kind of thing yet:
//------ lib.js ------
export function square(x) {
    return x * x;
}
export function diag(x, y) {
    return sqrt(square(x) + square(y));
}

//------ main.js ------
import { square, diag } from 'lib';

However, import and export are implemented in many transpilers, such as the Traceur Compiler, Babel or Rollup.