
Microsoft Edge supports ES6 modules - pilif
https://blogs.windows.com/msedgedev/2016/05/17/es6-modules-and-beyond/
======
MatthewPhillips
For those thinking about using this, it bears mentioning that there are a few
caveats to script type=module that makes it difficult to use with a lot of
modern workflows, namely:

1\. No way to dynamically import a module (the article explains this).

2\. All imports must be relative or absolute urls, so either ./foo.js or
/foo.js or [http://example.com/foo.js](http://example.com/foo.js)

This means you can't npm install lodash and import the string "lodash".

3\. All imports must include the file extension (.js). So even if you set up a
server route for /lodash it would break as soon as one of lodash's imports
didn't use .js (or it imports another package). This is assuming lodash is
written with import/export; it's not so it wouldn't work at all.

4\. Until http2 comes around, this is probably not something you want to ship
to production (unless you have a small app with only have a handful of scripts
being imported), so bundlers are here to stay for a while.

It might be possible to work around 1, 2, and 3 using Service Workers, I wrote
about this a while ago: [https://matthewphillips.info/posts/loading-app-with-
script-m...](https://matthewphillips.info/posts/loading-app-with-script-
module)

~~~
silverwind
> All imports must include the file extension (.js)

Or, .mjs [1].

[1] [https://github.com/nodejs/node-
eps/blob/master/002-es6-modul...](https://github.com/nodejs/node-
eps/blob/master/002-es6-modules.md#determining-if-source-is-an-es-module)

~~~
nacs
> .mjs [1].

I was worried this was short for "Microsoft JS", thanks for the link.

------
pyrophane
Honestly I'm perfectly happy with Typescript and browserify. At this point I'm
not sure I need support for JS in the browser to advance unless it allows my
transpiler to produce more optimized code.

------
regnet
What a time to be alive. Microsoft IE shipping modern features! Well done.

~~~
giancarlostoro
The reason IE used to be behind was that at one point Microsoft decided to
only publish features which had been standardized, which sounds nice, but the
rest of the web wants to be on the bleeding edge with new features.

~~~
gsnedders
I don't think anybody really believed that. Maybe some manager. Everyone I
knew on the IE team at the time wanted to be on the bleeding edge, but they
were up against it catching up years of no work on IE—the "Recommendations
only" line was as far as one could tell something made up by marketing to
justify the fact they were so far behind and what they were implementing as a
result. (It's also laughable—for a specification to become a REC at the W3C,
post-2001, one practically needs two implementations. Practically it's saying
"we're always behind two others!")

~~~
giancarlostoro
I can't remember where I read it, if on HN or elsewhere, but that was what I
heard, it sounded plausible enough. I guess it was likely another excuse. At
the very least they're aiming towards the bleeding 'Edge'.

~~~
gsnedders
It originally comes from the IE Blog in, I think, the IE7 release cycle (my
memory of the date could be wrong; it's certainly a while ago!). At the time
almost everything there was pretty censored and overly-dressed-up.

------
mevile
So what I still don't understand is how es6 module imports work with requests.
Even reading through that blog post it's not obvious to me. Does the browser
make an HTTP request for the file on the server based on the relative location
on the server? So if I have type="module" and app.js is in
example.com/js/app.js and then I have an import statement for ./foo/bar.js it
makes that request to example.com/js/foo/bar.js? I imagine all these requests
would add up and will block if so. With HTTP2 maybe it would be OK to do it
this way but I see myself creating single JavaScript builds for the
foreseeable future making this sort of module support unlikely to help in
anything other than development (which still is nice).

~~~
calebegg
Note that since ES6 imports are statically defined, the browser can find and
begin to download dependent files before even parsing the actual JS. They
could even start downloading dependent files in parallel before the first file
is fully downloaded.

But bundling will still probably be faster and will probably continue to be a
mainstay of production web apps, just like minification already is.

~~~
WorldMaker
Bundling may not necessarily be faster with HTTP/2 and proper cache controls.

~~~
MatthewPhillips
I don't see a practical difference between bundling and server push to the
developer. You are still using tooling that traces your dependency graph and
produces... something. In the case of a bundler it produces a concatenated
script and in the case of http push it produces a list of files that should be
sent with a particular route. To the developer, why should the latter be
preferred over the former?

~~~
rajivm
Three reasons off the top of my head: \- Smaller cacheable objects -- every
change you make doesn't invalidate the whole "bundle". \- If there are many
permutations of the optimal bundles: different browsers, different pages use
different scripts, etc. \- The browser does not need to wait for the "full
bundle" to download to execute your app/site -- it can start once the first
necessary assets are loaded.

In one project I worked on, we had 3 bundles: \- early load (inside the head
tag) \- deferred load secondary (after body tag, for the other site pages) \-
deferred load primary (after the body tag, for the 'hot' pages of the site)
With a optimal http/2.0 setup, we wouldn't need to make these never fully
optimal bundles.

------
koolba
Short of browser useragent sniffing ( _yuck..._ ) is there any way to make use
of ES6 features in a browser agnostic app? Seems like the only way to work is
with a transpiler and series of polyfills.

~~~
Spivak
You could do something like

    
    
        try {
            eval('"use strict"; import "jquery";');
        } catch (e) {
            // No imports.
        }
    

but I wouldn't really recommend it.

~~~
MatthewPhillips
That won't work, you can't eval modules.

------
jakegarelick
Always glad to see Microsoft stepping up their game :)

Not surprised by this, they made it pretty clear at their dev summit that ES6
was a priority.

------
z3t4

      (function() {
      ___MODULE["foo"] = foo
      })();
    
      function require(m) {return ___MODULE[m]}

------
pilif
Who'd have though that the first vendor to build in support for ES6 modules
was going to be Microsoft?

Of course it will be at least 10 years before people can safely require Edge
and another 5 years before that version of Edge current enough to support
modules.

Remember: IE11 will be supported with Windows 8, 8.1 and 10 until at least
2020 and the enterprise version of Windows 10 never gets feature updates and
thus never an updated Edge.

~~~
toomanythings2
Wasn't the announcement, yesterday, that webkit/Safari had complete
implementation?

~~~
madeofpalk
The catch is there's the JS Module syntax, controlled by TC39, which WebKit
may or may not support (not sure whether its a part of ES6 or not), and then
there's the browser module loading standard, which is controlled by WHATWG.

