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...
ECMAScript 2016+ in Firefox
21–30 of 93 posts
Re: ECMAScript 2016+ in Firefox
#22Earlier 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.
Re: ECMAScript 2016+ in Firefox
#23ES2017?
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
#24Realistically, 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…
Looking forward to the day alternative languages start targeting WebAssembly instead of JavaScript.
Re: ECMAScript 2016+ in Firefox
#25Earlier 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.
Re: ECMAScript 2016+ in Firefox
#26Realistically, 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…
Re: ECMAScript 2016+ in Firefox
#27Realistically, 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 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
#28Re: ECMAScript 2016+ in Firefox
#29I 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?
Re: ECMAScript 2016+ in Firefox
#30Earlier 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…