Live data from Hacker News

ECMAScript 2016+ in Firefox

blog.mozilla.org

21–30 of 93 posts

Re: ECMAScript 2016+ in Firefox

#21
post #7
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?

See here [1], under "Why make this change?". [1] https://www.nczonline.net/blog/2016/10/the-ecmascript-2016-c...

Ah that makes sense - by the time the parser sees a 'use strict' it's too late to apply strict mode to the default arguments. Thanks!

Re: ECMAScript 2016+ in Firefox

#22
post #18
post #8

Earlier quoted context omitted.

That's what Babel[0] is for. Realistically you can't rely on native ES2016 for any target audience yet, but with Babel you can blissfully live in the future, today :) Also, thrown in core-js[1] while you're at it. [0] https://babeljs.io/ [1] https://github.com/zloirock/core-js

Babel is only part of the history, then there is HTML and CSS support levels. Some of our projects are with customers that still rely on XP with IE 8, require using the "Internet Browser" for pre-Android 4.4 or Windows Safari (!) or IoT devices without updatable browsers.

Your customers are lucky to have you. I imagine they will rely on XP and IE8 as long as you are around.

Re: ECMAScript 2016+ in Firefox

#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 standing issue still remains mysteriously unsolved, by anyone.

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

Re: ECMAScript 2016+ in Firefox

#24

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?

Looking forward to the day alternative languages start targeting WebAssembly instead of JavaScript.

Re: ECMAScript 2016+ in Firefox

#25
post #22
post #18

Earlier quoted context omitted.

Babel is only part of the history, then there is HTML and CSS support levels. Some of our projects are with customers that still rely on XP with IE 8, require using the "Internet Browser" for pre-Android 4.4 or Windows Safari (!) or IoT devices without updatable browsers.

Your customers are lucky to have you. I imagine they will rely on XP and IE8 as long as you are around.

Not me personally, my employer is quite big, and any consulting company will happily sell such services.

Re: ECMAScript 2016+ in Firefox

#26

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…

Even if the browsers support modules, you still will want to generate a bundle, because loading modules on the fly would require lots of tertiary HTTP requests.

Re: ECMAScript 2016+ in Firefox

#27

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…

Even if the browsers support modules, you still will want to generate a bundle, because loading modules on the fly would require lots of tertiary HTTP requests.

I was under the impression HTTP/2 would make this concern irrelevant... but I'm no expert on the subject. I suppose its a valid point.

I just don't see what the point in having support for additional js language features natively is if you're forced to use a tranpiler regardless.

If you supported only, say, 50% of ES2016, and modules you could plausibly deliver unbundled native ES6; it'd be pretty cool; but modules aren't just a random feature from the pot; there is literally no serious modern web application that doesn't use them.

So... I'm struggling to see the ES2016 feature complete map (without modules) as really meaningful for anyone, practically.

Re: ECMAScript 2016+ in Firefox

#29
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?

"use strict" has to be outside of the function in this case.

Re: ECMAScript 2016+ in Firefox

#30

Earlier quoted context omitted.

Even if the browsers support modules, you still will want to generate a bundle, because loading modules on the fly would require lots of tertiary HTTP requests.

I was under the impression HTTP/2 would make this concern irrelevant... but I'm no expert on the subject. I suppose its a valid point. I just don't see what the point in having support for additional js language features natively is if you're forced to use a tranpiler regardless. If you supported only, say, 50% of ES2016, and modules you could plausibly deliver unbundled native ES6; it'd be pretty cool; but modules a…

HTTP/2 won't make a serious difference in regards to that, bundling will always be required. Also minifying will always be required, so there's always going to be a build step anyway.
Post reply on HN