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

71–80 of 93 posts

Re: ECMAScript 2016+ in Firefox

#71

Post by jakub_g »

vmasto wrote: post #30
shadowmint wrote: post #27

Earlier quoted context omitted.

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.

Minifying yes but why bundling?

https://hpbn.co/http2/#request-and-response-multiplexing

HTTP2 takes care of loading files via multiplexing, and ES6 modules take care of loading JS in proper order, no need to bundle AFAIU.

Re: ECMAScript 2016+ in Firefox

#72

Post by jakub_g »

mstade wrote: post #41
andrzejsz wrote: post #36

I wonder does ECMAScript 2017 has optional name ES8?

Not really, but there's certainly an off-by-one joke in there somewhere. Since ES2015 the official nomenclature is ES , to convey that a new version of the standard is cut yearly. While this may result in somewhat underwhelming releases, like ES2016, at least it's much easier to reason about and target than previously. Case in point, it took ten years or so to get from ES3 to ES5, and another five-six years I believe…

We must stop using names like ES8 etc. right now, otherwise there'll be a lot of confusion in 4024 about which version of ES your customers' IE supports.

Re: ECMAScript 2016+ in Firefox

#73

Post by tomatsu »

diggan wrote: post #6
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?

According to the documentation on MDN[0], it's a part of "early errors" and you should rather but the "use strict" outside the function instead of on the inside. I'm not entirely sure of why the spec wants it to be outside rather than inside though... - [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> you should rather [put] the "use strict" outside the function instead of on the inside.

Modules and classes are always in strict mode. In practice, it really isn't an issue.

Re: ECMAScript 2016+ in Firefox

#74

Post by emn13 »

whatever_dude wrote: post #66
hajile wrote: post #65

Earlier quoted context omitted.

But webkit has 100% support for ES6 (according to kangex) while nobody else does...

Yeah, and it's great. It's just that WebKit's (and Apple's) efforts are sometimes.. lopsided.

On the one hand, the deficiencies in that table don't look all too serious. Maybe Date.toJSON missing is the worst.

On the other hand, that's a poor excuse - why the heck haven't they fixed these issues? Cross browser compat is annoying enough as it is.

Re: ECMAScript 2016+ in Firefox

#75

Post by tomatsu »

z3t4 wrote: post #70
allover wrote: post #68

Earlier quoted context omitted.

ES6 modules are great because they're statically analysable, whilst CommonJS modules aren't.

just parse it like any other js code

Declarations can be analyzed statically. Declarative stuff is convenient that way.

If you have to execute code, things get messy.

Re: ECMAScript 2016+ in Firefox

#76

Post by emn13 »

hzoo wrote: post #34
paol wrote: 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

Yep and with Babel we recommend using https://github.com/babel/babel-preset-env to compile only what's missing in the targets you support. Hopefully we have a better solution about making multiple bundles (separate one for IE) soon

I'm currently experimenting with if-no-window.Promise-then-polyfill via polyfill.io (I dont quite trust synchronous dynamic script loading yet, but we'll see if that's robust enough on old browsers). Sure, old browsers need an extra roundtrip, and it's an additional point of failure - but it simplifies dev tooling, and if your users actually cared about perf, they wouldn't be using ancient browsers.

It won't fix many issues (e.g. CSS), but at least some, and without making your build complicated, and without performance sacrifices for the majority of devices.

Re: ECMAScript 2016+ in Firefox

#77

Post by phonon »

shakna wrote: post #15
endless1234 wrote: post #11

Earlier quoted context omitted.

Of course it helps, only there is a bit of a lag. How many 'enterprise markets' run <IE9 nowadays?

I know of eight products, compulsory for school's to use, such as OnDemand [0], put out by the Australian government, that only run under IE7/8. (Though the published specs say it runs on IE9+ for admin, and IE10+ for students, but I've never got admin to run under anything but IE7, and students on anything more than IE8.) I'd imagine that enterprises are still running many products with similar insane requirements,…

Have you tried IE11 Enterprise (IE8) mode?

https://www.howtogeek.com/184634/how-to-enable-and-use-inter...

Re: ECMAScript 2016+ in Firefox

#78

Post by nicoburns »

iainmerrick wrote: post #56
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 advertisin…

Native async functions are nice for the better debugging support (chrome will give you full stack traces that are as nice as ones from synchronous code).

Re: ECMAScript 2016+ in Firefox

#79

Post by hzoo »

mstade wrote: post #42
hzoo wrote: post #35

Earlier quoted context omitted.

The purpose of Babel/transpilers is to eventually allow users to use the native versions of language features. Native support will eventually be faster (not at first), will result in less code sent to users (compiled code is larger), and easier to debug (don't need sourcemaps). https://v8project.blogspot.com/2017/02/high-performance-es20... I made https://github.com/babel/babel-preset-env to make it easier to transit…

Thanks for your excellent efforts hzoo, and of course everyone else involved! The new env preset really makes it much easier to maintain a forward looking code base.

Thanks! Will be working torward making the preset-env + babel-minify combo work much better soon.

Re: ECMAScript 2016+ in Firefox

#80

Post by shakna »

phonon wrote: post #77
shakna wrote: post #15

Earlier quoted context omitted.

I know of eight products, compulsory for school's to use, such as OnDemand [0], put out by the Australian government, that only run under IE7/8. (Though the published specs say it runs on IE9+ for admin, and IE10+ for students, but I've never got admin to run under anything but IE7, and students on anything more than IE8.) I'd imagine that enterprises are still running many products with similar insane requirements,…

Have you tried IE11 Enterprise (IE8) mode? https://www.howtogeek.com/184634/how-to-enable-and-use-inter...

Unfortunately there are some minute differences in the way headers get passed to the server, and the user-agent string is slightly different as well.

Badly made software doesn't play ball.

Though it is theoretically possible to force it to work under IE8 mode, its simpler to supply real IE8 over a remote login.

Post reply on HN