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

31–40 of 93 posts

Re: ECMAScript 2016+ in Firefox

#31

Post by moron4hire »

shadowmint wrote: post #27
moron4hire wrote: post #26

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…

Transpiling also drastically increases the size of code. Having these features natively could significantly reduce bundle size.

Re: ECMAScript 2016+ in Firefox

#32

Post by evilpie »

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…

Preliminary modules supports can be enabled in Firefox Nightly by changing dom.moduleScripts.enabled to true in about:config. There are still some bugs (https://bugzilla.mozilla.org/show_bug.cgi?id=568953) to fix before we can ship this.

Re: ECMAScript 2016+ in Firefox

#33

Post by CSMastermind »

paol wrote: post #8
pjmlp wrote: post #4

Earlier quoted context omitted.

It doesn't help when one needs to target enterprise markets or devices that only have their factory provided browser.

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 has it's own set of flaws like causing a performance hit.

Re: ECMAScript 2016+ in Firefox

#34

Post by hzoo »

paol wrote: post #8
pjmlp wrote: post #4

Earlier quoted context omitted.

It doesn't help when one needs to target enterprise markets or devices that only have their factory provided browser.

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

Re: ECMAScript 2016+ in Firefox

#35

Post by hzoo »

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…

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 transition. Hoping that Babel makes it easier to not have to think about whether you are using native or not, so we'll work on that workflow.

Re: ECMAScript 2016+ in Firefox

#38

Post by dualogy »

pjmlp wrote: post #24
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? Looking forward to the day alternative languages start targeting WebAssembly instead of JavaScript.

You mean "the day WebAssembly gets out of preview/alpha/worse status in all major browsers".. yeah, don't we all --- wouldn't hold my breath. Once there, give it another 2 years to actually mature in the wild.

Re: ECMAScript 2016+ in Firefox

#39

Post by dotancohen »

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…

With native support you can debug in a current web browser. Also, native support means that you can ditch the compiler / transpiler earlier.

Re: ECMAScript 2016+ in Firefox

#40

Post by Crespyl »

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…

I wouldn't be surprised if a lot of the major players are holding back on JS modules until after WASM gets farther along.

It could seem like a waste of effort to standardize and implement JS modules (which "everyone already has" via transpilers) when they expect people to move quickly to language agnostic WASM modules once they become available.

Post reply on HN