10 ms·

Microsoft Edge supports ES6 modules

150 points by pilif 10y ago

pilif 10y 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 10y 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.
- toomanythings2 10y ago
  Wasn't the announcement, yesterday, that webkit/Safari had complete implementation?
  - madeofpalk 10y 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 10y 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.
albasha 10y ago
The ship has sailed, Microsoft. You had your chance and you held the Web back for a decade. Where would we be right now if you didn't hinder the progress. Nice try anyway.
- mevile 10y ago
  How does this comment contribute to the discussion in any meaningful way? Microsoft's browser is actually quite advanced when it comes to new JavaScript features. The biggest problem for developers with Edge is that it requires Windows, a slow internet based testing service, or a VM to test. But really if it works in Chrome, Safari and Firefox it generally works in Edge as well.
  - albasha 10y ago
    I tell you how. Posts like this claiming they are cutting-edge will enable to once again take control of browsers and once they are at the top, they will start playing their monopoly game. And the cycle will start again.
    - KirinDave 10y ago
      The entire ecosystem has changed. Microsoft really isn't in a position to "embrace and extend" and they probably never will be again. And they're taking more radical steps towards ongoing transparency and fairness than most other companies I could name, including things like their compiler & runtime licensing, pledges to never use over API use, directly supporting their cloud service competitors. I'm not sure what value your grudge gives to you, but let me offer you a new target for hate: The only people given a free license to lock down the ecosystem from hardware all the way out to setting prices and fees in the software market is Apple, I guess. THEY won't betray us!
    - ceejayoz 10y ago
      > Posts like this claiming they are cutting-edge will enable to once again take control of browsers and once they are at the top, they will start playing their monopoly game. Microsoft employs smart people. It has become clear that long-term, that approach simply doesn't work. There are legal consequences to being an abusive monopoly, and on top of that we've seen that the software ecosystem routes around the bottleneck pretty rapidly.
koolba 10y 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.
- deleted 10y ago
  [deleted]
- Spivak 10y ago
  You could do something like try { eval('"use strict"; import "jquery";'); } catch (e) { // No imports. } but I wouldn't really recommend it.
  - MatthewPhillips 10y ago
    That won't work, you can't eval modules.
- wavefunction 10y 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 10y ago
  Given that transpilers give better performance at the moment, there's not much reason to use ES6 features natively for now.
mevile 10y 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).
- MatthewPhillips 10y 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 10y 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.
    - MatthewPhillips 10y ago
      That's a really smart idea, I hadn't considered that. Once you add in caching you might get pretty reasonable performance.
      - WorldMaker 10y ago
        Also, the not yet implemented module loader spec would include a format similar to the AMD bundle format where modules are wrapped in calls to `System.register`.
MatthewPhillips 10y 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 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-module https://matthewphillips.info/posts/loading-app-with-script-m...
- silverwind 10y ago
  > All imports must include the file extension (.js) Or, .mjs [1]. [1] https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md#determining-if-source-is-an-es-module https://github.com/nodejs/node-eps/blob/master/002-es6-modul...
  - nacs 10y ago
    > .mjs [1]. I was worried this was short for "Microsoft JS", thanks for the link.
- WorldMaker 10y 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.
  - 10y ago
regnet 10y ago
What a time to be alive. Microsoft IE shipping modern features! Well done.
- giancarlostoro 10y 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.
  - gsnedders 10y 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!")
    - giancarlostoro 10y ago
      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 10y ago
        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.
    - adrianba 10y ago
      When the time between releases is measured in years you better be sure that new features are somewhat stable before you ship, especially when customers take a long time to upgrade because of the support you offer them. We always have to make a judgement about when things are ready enough but it is much easier now than it was back then. Sometimes we guess wrong but with faster release cycles it is more possible to fix things so we don't have to be _quite_ so conservative. We can also ship things behind flags now (which is how we are experimenting with modules) and we can include things in Insider builds so you can try them without waiting for a full release.
pyrophane 10y 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 10y ago
(function() { ___MODULE["foo"] = foo })(); function require(m) {return ___MODULE[m]}
salamanca 10y ago
This is cool: "Modules let you write componentized and sharable code."

150 points by pilif 10y ago

pilif 10y 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 10y 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.
toomanythings2 10y ago
Wasn't the announcement, yesterday, that webkit/Safari had complete implementation?
- madeofpalk 10y 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 10y 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.

albasha 10y ago

The ship has sailed, Microsoft. You had your chance and you held the Web back for a decade. Where would we be right now if you didn't hinder the progress. Nice try anyway.

mevile 10y ago
How does this comment contribute to the discussion in any meaningful way? Microsoft's browser is actually quite advanced when it comes to new JavaScript features. The biggest problem for developers with Edge is that it requires Windows, a slow internet based testing service, or a VM to test. But really if it works in Chrome, Safari and Firefox it generally works in Edge as well.
- albasha 10y ago
  I tell you how. Posts like this claiming they are cutting-edge will enable to once again take control of browsers and once they are at the top, they will start playing their monopoly game. And the cycle will start again.
  - KirinDave 10y ago
    The entire ecosystem has changed. Microsoft really isn't in a position to "embrace and extend" and they probably never will be again. And they're taking more radical steps towards ongoing transparency and fairness than most other companies I could name, including things like their compiler & runtime licensing, pledges to never use over API use, directly supporting their cloud service competitors. I'm not sure what value your grudge gives to you, but let me offer you a new target for hate: The only people given a free license to lock down the ecosystem from hardware all the way out to setting prices and fees in the software market is Apple, I guess. THEY won't betray us!
  - ceejayoz 10y ago
    > Posts like this claiming they are cutting-edge will enable to once again take control of browsers and once they are at the top, they will start playing their monopoly game. Microsoft employs smart people. It has become clear that long-term, that approach simply doesn't work. There are legal consequences to being an abusive monopoly, and on top of that we've seen that the software ecosystem routes around the bottleneck pretty rapidly.

koolba 10y 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.

deleted 10y ago
[deleted]
Spivak 10y ago
You could do something like try { eval('"use strict"; import "jquery";'); } catch (e) { // No imports. } but I wouldn't really recommend it.
- MatthewPhillips 10y ago
  That won't work, you can't eval modules.
wavefunction 10y 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 10y ago
Given that transpilers give better performance at the moment, there's not much reason to use ES6 features natively for now.

mevile 10y 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).

MatthewPhillips 10y 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 10y 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.
  - MatthewPhillips 10y ago
    That's a really smart idea, I hadn't considered that. Once you add in caching you might get pretty reasonable performance.
    - WorldMaker 10y ago
      Also, the not yet implemented module loader spec would include a format similar to the AMD bundle format where modules are wrapped in calls to `System.register`.

MatthewPhillips 10y 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 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-module https://matthewphillips.info/posts/loading-app-with-script-m...

silverwind 10y ago
> All imports must include the file extension (.js) Or, .mjs [1]. [1] https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md#determining-if-source-is-an-es-module https://github.com/nodejs/node-eps/blob/master/002-es6-modul...
- nacs 10y ago
  > .mjs [1]. I was worried this was short for "Microsoft JS", thanks for the link.
WorldMaker 10y 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.
- 10y ago

regnet 10y ago

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

giancarlostoro 10y 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.
- gsnedders 10y 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!")
  - giancarlostoro 10y ago
    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 10y ago
      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.
  - adrianba 10y ago
    When the time between releases is measured in years you better be sure that new features are somewhat stable before you ship, especially when customers take a long time to upgrade because of the support you offer them. We always have to make a judgement about when things are ready enough but it is much easier now than it was back then. Sometimes we guess wrong but with faster release cycles it is more possible to fix things so we don't have to be _quite_ so conservative. We can also ship things behind flags now (which is how we are experimenting with modules) and we can include things in Insider builds so you can try them without waiting for a full release.

pyrophane 10y 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 10y ago

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

salamanca 10y ago

This is cool: "Modules let you write componentized and sharable code."