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

Gilleod

#13355986 – Parang

Astonishingly, Microsoft Edge claims to fully support it. – Emu

@vaultah: The question you posted was asked 2 years ago. See developer.mozilla.org/en-US/docs/Web/JavaScript/… The feature is not yet supported in Firefox, nor Chrome. – Gilleod

But the answer in that question links to a fantastic up-to-date resource. – Ponytail

Also: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/… – Ponytail

@deceze: I have visited that page prior to posting this question, and can't seem to locate the feature name (import and export syntax) Can you please guide me as to what the feature name may be for these syntaxes. Thanks! – Gilleod

It seems import and export are missing from that page. However, I've linked to the MDN compatibility chart for specifically that feature above. In short: no browser fully supports ES6 at this point and apparently none supports import/export. – Ponytail

Seems as it's not supported yet on any browser. Quoting from website: "Note: This feature is not implemented in any browsers natively at this time. It is implemented in many transpilers, such as the Traceur Compiler and ES6 Module Transpiler." developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/… – Gilleod

@GregoryR. Your note directly conflicts with the title of your question. If you are asking specifically about import/export syntax I would update your title. – Habile

Title updated. Thanks. – Gilleod

The actual module loader is not part of the ES6 standard and there is currently no standard for it. If a browser cannot load modules (according to a standard) it doesn't make much sense to support the syntax for modules. So I guess we'll have to wait until a standard is finished. – Wildawildcat

note that despite the module standard not being supported, 'import' and 'export' and 'default' are reserved words on Safari 9 and Chrome 50 (and possibly older versions too), so messing around in the Developer Console may give the false impression that there is support. – Asiatic

@zeroflagL Thanks for the link. I noticed the GitHub repo for the standard also contains links to the implementation status of the milestones on different browsers. – Outcaste

I would bundle (using rollup) modules anyway since loading them from the browser seems crazy to me, sending a request to the server per module..30+ requests? 100? – Stagecoach

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.

Bicameral

Webpack, SystemJS, AMD, to name a few more bundlers :) – Regazzi

Rollup is the best (its super fast) and easiest to start with, and require zero learning. just run the command and it works. I've been using it for over a year with great success of several projects ranging in sizes. – Stagecoach

@Bicameral SystemJS is module loader , and webpack is module blunder.. is my understanding correct ? – Rein

@Ginden, What do you mean by Chrome supporting import and export syntax? I'm getting Unexpected token export – Salangi

@Salangi Because token "export" isn't allowed in context that you are trying. Actually you can't create context where export would be valid - it's hidden from end user and available only from internals. – Bicameral

@Bicameral So wait, it "supports" it but can't actually use it in any context? Isn't that a rather loose usage of the term "supports"? – Assiniboine

Chrome doesn't support import yet. – Cherubini

It seems like this is now supported in modern browsers (except IE) caniuse.com/#feat=mdn-javascript_statements_export caniuse.com/#feat=mdn-javascript_statements_import – Heighho

Answer 2

It's supported in:

• Safari 10.1 - IOS 10.3
• Chrome 61
• Firefox 60
• Edge 16

Cowpea

Now natively in Firefox since v60 – Hamate

any references? – Mideast

@DaviLima: caniuse.com/mdn-javascript_statements_import – Wernick

Answer 3

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.

Macrae

Note that HTTP v2 means that making 1000s of small requests has only a small overhead compared to making 1 big one. Node js is also used for server side apps and scripts, tools, etc, which don't suffer from the requests issue (using 'import' would be mostly identical to using 'require' for these in terms of semantics). – Rhizome

@Rhizome And if you look at it in more detail, you will find out that actually, Node too has issues when you use too many small packages. For large systems comprised of hundreds of small package, the inital require tree can become so big that you get (many) seconds of startup delay. In fact some people recommend bundling for the server side as well (also for HMR etc). – Macrae

@StijndeWitt, all those hundreds of requests can be cached. Or even serviceworker-ed. – Salangi

@Salangi No need to insult. There is a reason that in guidelines for progressive web apps they advice you to inline your critical styles and JS code in the head of the document. These requests will hurt your Time To Interactive in the real world. Yes those requests might be cached... then again they might not. Everyone taking perf seriously is doing their best to minimize number of requests, number of roundtrips and payload size per request. Because that's what kills performance if you don't limit it. – Macrae

First-layer inlining is needed to stop that 200 msec load time blank screen. That's only for the initial load. Every other request do not get inlined in HTTP 2.0 since there's multiplexing. Even in HTTP 1.0, if they are service-workered, then they are already considered inlined. – Salangi

I think in simple implementations, like a very simple website, it is a better option to use import than to include both scripts as script tags, for more complex scenarios I would stick with webpack – Lindeberg

Answer 4

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

Hamate

There is a reason the support is very limited though... I'll write an answer – Macrae

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.

Gilleod