Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ECMAScript 2016+ in Firefox

blog.mozilla.org

Post reply on HN
Print view View original

51–60 of 93 posts

Re: ECMAScript 2016+ in Firefox

#51

Post by Bahamut »

mstade wrote: post #45
shadowmint wrote: post #23

Realistically, when are we going to see the modules situation resolved? ES2017? ES2018? I know, I know, just use a transpiler and emit a bundle... but really? It's been a draft since 2015, and no browsers have any support for it yet, despite full support for the rest of the standard? Are modules really that controversial? I'm kind of disappointed, honestly, that despite all the progress in the ecosystem, this long st…

Note to people reading this: module support in this post seems to mostly refer to the loading of modules. The spec is pretty clear about the syntax and semantics of modules, except when it comes to loading which it more or less says is "up to the runtime" to figure out. There's some interesting (or not, depending on your POV) conversation/debate going on between the nodejs world and the browser world, which are – I s…

From what I have been told, this proposal is likely to win out: https://github.com/tc39/proposal-dynamic-import

Re: ECMAScript 2016+ in Firefox

#52

Post by pas »

rocky1138 wrote: post #48

Do any of these changes make the language objectively better? All I see are nice-to-haves that aren't really required.

Well, realistically, if you want an objectively better JS, use TS. It's completely opt-in, transpiles/compiles to JS, and you can finally maintain projects with more than 1 JS file in them, and no longer have to rage-delete the whole scripts.js file when - after adding the 66th god forsaken jQuery lib - something blows up the whole damn thing and all you're left with is a ridiculous error deep from within an unrelated library.

Re: ECMAScript 2016+ in Firefox

#53

Post by whatever_dude »

M4v3R wrote: post #2

Good to see such quick progress in this area in major browsers. It's worth noting that WebKit also has 100% support for ES 2016+. So now only Edge is lagging in this regard. [0] http://kangax.github.io/compat-table/es2016plus/#webkit

And yet WebKit has 99% on ES5, while Edge and Firefox have 100% (and Chrome has 98%).

http://kangax.github.io/compat-table/es5/

Re: ECMAScript 2016+ in Firefox

#54

Post by chrisl99 »

shadowmint wrote: post #23

Realistically, when are we going to see the modules situation resolved? ES2017? ES2018? I know, I know, just use a transpiler and emit a bundle... but really? It's been a draft since 2015, and no browsers have any support for it yet, despite full support for the rest of the standard? Are modules really that controversial? I'm kind of disappointed, honestly, that despite all the progress in the ecosystem, this long st…

JS modules are working in Safari Technology Preview today - so it should be available to everyone soon enough. Pretty simple too, you load your entry point like this -

And then main.js runs in strict mode, can use "import", etc.

Re: ECMAScript 2016+ in Firefox

#55

Post by NegativeLatency »

JoshGlazebrook wrote: post #44
shadowmint wrote: post #23

Realistically, when are we going to see the modules situation resolved? ES2017? ES2018? I know, I know, just use a transpiler and emit a bundle... but really? It's been a draft since 2015, and no browsers have any support for it yet, despite full support for the rest of the standard? Are modules really that controversial? I'm kind of disappointed, honestly, that despite all the progress in the ecosystem, this long st…

Forget about browsers, have you read the clusterfuck that Node.js is aiming for with ES6 Modules? https://medium.com/the-node-js-collection/an-update-on-es6-m...

Oh goodie another file extension.

Re: ECMAScript 2016+ in Firefox

#56

Post by iainmerrick »

shadowmint wrote: post #23

Realistically, when are we going to see the modules situation resolved? ES2017? ES2018? I know, I know, just use a transpiler and emit a bundle... but really? It's been a draft since 2015, and no browsers have any support for it yet, despite full support for the rest of the standard? Are modules really that controversial? I'm kind of disappointed, honestly, that despite all the progress in the ecosystem, this long st…

If you're using a transpiler anyway, who really cares if you have native support for the language features?

I've been wondering the same thing. Surely the only exciting new language features are the ones that can't be polyfilled?

Native support means it can be smaller and faster, sure. But I don't think you can blame web bloat on Javascript's lack of built-in modules. Web bloat is caused by an arms race of advertising and tracking plugins. I don't care much about making those more efficient, I just want the advertising and tracking stripped out.

Re: ECMAScript 2016+ in Firefox

#57

Post by mstade »

Bahamut wrote: post #51
mstade wrote: post #45

Earlier quoted context omitted.

Note to people reading this: module support in this post seems to mostly refer to the loading of modules. The spec is pretty clear about the syntax and semantics of modules, except when it comes to loading which it more or less says is "up to the runtime" to figure out. There's some interesting (or not, depending on your POV) conversation/debate going on between the nodejs world and the browser world, which are – I s…

From what I have been told, this proposal is likely to win out: https://github.com/tc39/proposal-dynamic-import

Looks to be a stage 3 proposal[1] so that seems likely. Had a quick read through, looks like a pretty solid proposal. If I read it correctly, it means `import()` will only load ES2015 modules. (I.e. the result of HostResolveImportedModule is a Module Record. That's a good thing as far as I'm concerned.

Given the history of discussion around this, this seems surprisingly low key and reasonable. (The System.loader stuff was gnarly!)

But what does this mean for nodejs? I don't see how this rhymes with current proposals re `require.import` and the likes. If the above proposal wins out it becomes a language spec, so presumably will also become available in nodejs, and if they go ahead with the ideas mentioned in another comment here, we'd have both `import(specifier)` and `require.import(specifier)` – seems pretty confusing, but maybe I'm getting it all wrong?

[1]: https://github.com/tc39/proposals

Re: ECMAScript 2016+ in Firefox

#59

Post by uwu »

nailer wrote: post #3

I can see that strict mode inside a function using default parameters should throw according to the spec ( https://tc39.github.io/ecma262/#sec-function-definitions-sta... ) but does anyone know why? Is strict mode something we should now be avoiding?

my guess: to not complicate parsing complex expressions in default parameters

  // non-strict mode top-level code
  
  function foo (complex = eval("1+1"), moreComplex = (function(){ with (this) { return bar; } }())) {
      
	  "use strict"; // go back and parse the parameters again but this time with strict mode semantics
      
	  // ...
	  
  }
Post reply on HN