Microsoft Edge supports ES6 modules

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

by pilif • 10 years ago

150 55 10 years ago

blogs.windows.com

pilif• 10 years ago

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.

GlitchMr• 10 years ago

Enterprise LTSB (as opposed to just Enterprise) is least of your problems, it's a niche Windows release, not supposed to be used by end-users, but rather by systems like kiosks, ATMs, medical devices, and other devices that shouldn't break, and doesn't need new features in an operating system.

I doubt many LTSB browsers browse the internet (beyond perhaps having a website open in kiosk mode disallowing entering other websites), and even if they do, not with IE.

toomanythings25• 10 years ago

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

madeofpalk• 10 years ago

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.

jakegarelick• 10 years ago

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.

koolba• 10 years ago

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• 10 years ago

You could do something like

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

but I wouldn't really recommend it.

MatthewPhillips8• 10 years ago

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

wavefunction• 10 years ago

Depending on the ES6 features and your supported browsers, you don't need anything.

If you want to use all the ES6 features, no single modern browser implements them all (Webkit is still lacking on modules) and so you will need to use a collection of polyfills.

33degrees• 10 years ago

Given that transpilers give better performance at the moment, there's not much reason to use ES6 features natively for now.

mevile2• 10 years ago

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).

MatthewPhillips8• 10 years ago

Yes, it makes separate requests, like if you made separate script tags (just using module semantics instead). With HTTP2 it will be ok, but you will still need something that understands your dependency graph so your server knows which modules to include with the request.

eknkc• 10 years ago

I guess service workers might solve a lot of issues here. You could do weird stuff like basically serving a tar file for all assets and use a service worker to handle individual requests.

calebegg• 10 years ago

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.

Arnavion2• 10 years ago

Note that since ES6 imports are statically defined, the browser can find and begin to download dependent files before even parsing the actual JS.

I think you meant executing the actual JS. Finding the imports requires parsing the file, and imports can be anywhere in the file as long as they're at the top level.

MatthewPhillips8• 10 years ago

You still have to fetch a module before you know it's dependencies. So if A depends on B which depends on C, you must fetch those sequentially. With a deep dependency graph this will be a problem.

WorldMaker6• 10 years ago

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

GundersenM• 10 years ago

I recently wrote about this, and how it can be solved using HTTP/2 and Service Workers: https://mariusgundersen.net/module-pusher/

MatthewPhillips8• 10 years ago

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

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...

silverwind• 10 years ago

All imports must include the file extension (.js)

Or, .mjs [1].

[1] https://github.com/nodejs/node-eps/blob/master/002-es6-modul...

nacs• 10 years ago

.mjs [1].

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

WorldMaker6• 10 years ago

The article doesn't mention 2 and 3, but just as with 1 the module loader spec that is not yet implemented would also happen to help address 2 and 3 by providing plugin mechanisms to support name mappings like automatic file extensions and mapping canonical module names like 'lodash' to file paths.

MatthewPhillips8• 10 years ago

Just to clarify, the mappings for names to paths isn't enough to load an NPM-based project. With NPM you can have multiple semver-incompatible packages. It's very common to happen, actually.

For example, you might depend on "foo" and "bar". "foo" also depends on "bar", but it needs version 1 and you need version 2. In this case, setting paths for "bar" won't work, the paths are different for each parent.

The loader spec provides a hook "resolve" that allows you to work around this, just wanted to point out that configuration alone wouldn't be enough.

It's also worth noting that the Loader spec doesn't have a real urgency to it. What I mean is that likely browsers will implement script type=module first, give it some time to brew, and then pull in things from whatwg/loader over time. In the meantime we'll want solutions that do allow us to use script type=module and still have modern workflows we are used to.

toomanythings25• 10 years ago

Until http/2 comes around? I've been using it for a couple of months on all our client sites and the standard was finalized last year. It's now available in all current, major browsers.

hyperknot3• 10 years ago

Please have a look at the data before writing such statement. In the latest CloudFlare article [1] about it (Feb 2016), they concluded that only 52.93% of their users are connecting over HTTP/2.

[1] https://blog.cloudflare.com/cloudflares-impact-on-the-http-2...

regnet• 10 years ago

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

giancarlostoro2• 10 years ago

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.

gsnedders4• 10 years ago

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!")

pyrophane• 10 years ago

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.

z3t4• 10 years ago

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

  function require(m) {return ___MODULE[m]}

Microsoft Edge supports ES6 modules

Related Stories