Live data from Hacker News

JSC loves ES6

webkit.org

31–40 of 191 posts

Re: JSC loves ES6

#31
post #30
post #22

Earlier quoted context omitted.

This benchmark is only representative for websites built with lots of new ES6+ features. On general JS performance, Firefox isn't quite that far behind (but still behind to the best of my knowledge).

And that's all fine...in a lab. In the real world, all I have to do to experience Firefox's performance is click "Home" on my Twitter account. More often than not I'll get an alert that "A script has stopped responding [...] Continue / Stop Script," and it will still take 60+ secs to finish refreshing the page. Meanwhile, all Firefox tabs and window instances are frozen.

Oh wow, that's pretty terrible.

Re: JSC loves ES6

#32
post #19

Earlier quoted context omitted.

ES6 is 3 syllables. ES2015 is 6 or 7 (depending if you say "twenty fifteen" or "two thousand fifteen"). I'm a dev. I'm lazy. I have no particular objection to the idea of moving away from ES6 as a name, but if the new name isn't more useful, it's not going to gain any ground.

But the new name is more useful. It tells you how many years you're behind.

Only sort of - it says how far behind the standard I might be, but since we're limited (on the Web at least) to what the browsers have implemented, it's not really measuring the important parts. (And in the backend, we're limited to what Node or other server-side engines support, and generally that goes back to the browser support).

ES2015/ES6 might be 2 years ago, but feature complete support isn't yet available on all major browsers. I expect, however, that ES2016 will hit complete-or-basically-complete support relatively soon after full ES2015 support. If true (or any other irregularity over time), I might be 2 years behind on ES2015 and 1 year behind on ES2016 according to their names, but I might have, say 3 months until ES2015 is an option and 8 months for ES2016.

And of course, unlike, say, Java, it's not really a yes/no choice. I tend to use const/let, native promises, fetch(), and arrow functions, but haven't yet had/found/realized a need for generators...am I behind ES2015? If 30% of ES2016 is implemented by most browsers, and I use one feature included in that 30% in 2017, am I 1 year behind?

The ES6, ES7, etc labels do an equal job (that is, not a great one) of saying how behind you are, in a more compact package.

Re: JSC loves ES6

#33
It seems weird to focus so much on es2015 features, when so many of them are polyfillable (not optimal, sure, but still) when there is such uneven support for DOM (and related browser) API features in safari.

I mean, where are service workers? Give me a nice, cross-platform way to handle offline-first and I'll be happy. But hey, it isn't like there's some kind of browser monopoly on iOS or anything, like there was in windows.

Re: JSC loves ES6

#34
post #21

Earlier quoted context omitted.

ES6 is 3 syllables. ES2015 is 6 or 7 (depending if you say "twenty fifteen" or "two thousand fifteen"). I'm a dev. I'm lazy. I have no particular objection to the idea of moving away from ES6 as a name, but if the new name isn't more useful, it's not going to gain any ground.

Unfortunately it's the name we're stuck with though, and it makes a lot more sense because ECMA releases are yearly. Not judging, but if high profile articles and browser vendors started addressing it correctly we wouldnt have any issues migrating, more syllables or not.

I'm a touch confused...are you saying that if everyone used the year-based nomenclature, the inconsistent support would go away? Today in 2017 I have some ES6/ES2015 features I can use as well as some ES7/ES2016 features, but there are also other ES6/ES2015 that I can't count on being supported, and quite a few ES7/ES2016 features I can't count on.

How are these problems alleviated if we change the name we use? Or have I totally misunderstood your point?

Side Note: I'm not a fan of using a year for the same reason we (i.e. most everyone) stopped using it for versioning - That previous iterations have been done on a yearly cycle does not mean that future iterations will follow that schedule. That, however, is a side argument that neither of us touched on.

Re: JSC loves ES6

#35

I’ve been staying away from most new ES6 features because when I tested them a year ago (either transpiled or with native support) they were slow as molasses in every browser I tried. Hopefully having some better benchmarks gets Firefox and Chrome developers to also get to work on this.

TypeScript is a good solution for this. I use ES2015+ features this way regularly and they perform great. I target ES5 so they are transpiled at build time, and as an added bonus I get async/await which is seriously a life saver in certain situations.

Edit... I work at Microsoft (I'm supposed to disclose this), but not on the TypeScript team.

Re: JSC loves ES6

#36

Earlier quoted context omitted.

Although IIRC Chrome and/or Firefox had all but guaranteed tail-call optimization (not a source code-level feature, obviously) first.

I don’t think that’s right. Source?

Just Chrome, but yes: http://web.archive.org/web/20160303192336/http://kangax.gith...

Re: JSC loves ES6

#37
post #33

It seems weird to focus so much on es2015 features, when so many of them are polyfillable (not optimal, sure, but still) when there is such uneven support for DOM (and related browser) API features in safari. I mean, where are service workers? Give me a nice, cross-platform way to handle offline-first and I'll be happy. But hey, it isn't like there's some kind of browser monopoly on iOS or anything, like there was in…

There never was a browser monopoly on Windows just a bunch of tech illiterates who don't seem bothered by MS's "monopoly" with notepad.exe or anti-competitive moves like taking away the ability to use an alternate graphical shell.

Only one popular consumer OS has prevented the installation of alternate browsers and everyone looks the other way.

Re: JSC loves ES6

#38
post #25

Earlier quoted context omitted.

On the other hand, it's not like Firefox is the side project of a few of people in their spare time -- the Mozilla Foundation has annual revenue of over $400 million! [1] https://en.wikipedia.org/wiki/Mozilla_Foundation

I do not have an inside look, but if I remember correctly there were few calls about Mozilla losing focus on Firefox through making Firefox OS for a few years, which is exactly when the other vendors were reinventing their engines. They made some great work with Rust though (;

Firefox OS led Mozilla to push a lot on the performance front in Gecko, mostly in gfx land. The JS perf is mostly SpiderMonkey and there was very little FxOS specific work done (as far as I remember, we mostly got help to tune the GC heuristics) because the JS team was already streched pretty thin.

These days Moco doesn't even try on mobile anymore (hint, there is no performance testing at all on arm in https://arewefastyet.com/#).

The desktop Firefox front-end didn't evolve so much during the FxOS days but these was not the same team either... and you would notice that key people leading Fx front end have changed since.

Re: JSC loves ES6

#40
post #30
post #22

Earlier quoted context omitted.

This benchmark is only representative for websites built with lots of new ES6+ features. On general JS performance, Firefox isn't quite that far behind (but still behind to the best of my knowledge).

And that's all fine...in a lab. In the real world, all I have to do to experience Firefox's performance is click "Home" on my Twitter account. More often than not I'll get an alert that "A script has stopped responding [...] Continue / Stop Script," and it will still take 60+ secs to finish refreshing the page. Meanwhile, all Firefox tabs and window instances are frozen.

That's more of an indication that Chrome monoculture encourages crap developer practices. There's no reason a messaging site should be so bloated that it brings a modern browser to it's knees.
Post reply on HN