
JSC loves ES6 - pizlonator
https://webkit.org/blog/7536/jsc-loves-es6/
======
pfooti
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.

~~~
MBCook
> I mean, where are service workers?

Every discussion about anything in Safari on HN, even if not at all related,
for the last year or two has included multiple people complaining about the
lack of WebRTC.

Now it's here and there is a new complaint /s

I agree with threeseed that it probwont come and frankly I don't see why I'd
want it (or web notification, or even WebRTC). They only seem to support the
use case of replacing real apps with webpages which I don't want to do and
makes no sense to me as an end user (I understand the freedom motivations).

~~~
pfooti
With service workers you can transparently intercept outgoing XHRs and replace
their results with cached values. You can even do a cache race if you want
(cancel the xhr if your cache returns first). This is a hugely important
feature for making web apps work offline-first. I mean, it's also a big part
of progressive web apps, which is the next thing I'm going to complain about.
(I don't personally care much about webrtc, but I can see why people do care
about it).

The general point isn't about any one feature in particular. It is about a
history safari has with not implementing (or half-heartedly implementing, as
with indexeddb for so long) APIs that are important to making the web a useful
platform.

Reasonable people can disagree whether or not those features are _good_ , but
it seems basically true that my mobile web work is constrained by what iOS
safari outright refuses to do, more than anything else.

~~~
millstone
This seems like a very strange API. Why do you need a proxy to intercept
network requests coming from your own app?

~~~
reitanqild
To serve that requests from local storage if your device or the server is
offline.

~~~
Sacho
Can't this be solved by a library? It seems like you could easily build a
facade in front of requests that queried local storage...you would just need
to figure out whether the device/server is online or not.

~~~
marksomnian
It's not just XHRs, it's _all_ requests by your app. The HTML, the CSS,
images, everything. The entire site can be served offline by this API.

------
Androider
The benchmark at the bottom showing how far behind Firefox has fallen on JS
performance is pretty telling. It confirms my own recent observation that
Firefox is _at least_ 3-6 times slower in practice for the particular app I'm
working on.

~~~
om2
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).

~~~
rhizome
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.

~~~
kevin_thibedeau
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.

------
vmasto
I really wish we would stop calling it ES6. Browser vendors should be
especially careful to call ES2015 by its correct name and help stop
perpetuating the confusion (ES6, ES7, ES2016, ES2017, you can see how this
quickly gets confusing).

~~~
ergothus
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.

~~~
vmasto
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.

~~~
ergothus
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.

~~~
vmasto
Just talking about the name.

You can see how this is confusing, here's a recent one just from today by
Craig Federighi
[https://twitter.com/feross/status/871839072590979076](https://twitter.com/feross/status/871839072590979076)

~~~
int_19h
I'm pretty sure this ship has sailed for ES6. It's been referred as such while
it was in development for so long, it's here to stay.

The next one might be different. But they really need to come up with a better
than than "2017" or whatever. There's no similar problem with C or C++, and
that's likely because they use 2 digit years, not 4 digit - C++17 isn't super
short, but it's not a mouthful.

------
caiob
Worth noting that Safari Technology Preview was the first browser to support
all of ECMAScript 2016+ features.

* [http://kangax.github.io/compat-table/es2016plus/](http://kangax.github.io/compat-table/es2016plus/)

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

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

~~~
smitherfield
Just Chrome, but yes:
[http://web.archive.org/web/20160303192336/http://kangax.gith...](http://web.archive.org/web/20160303192336/http://kangax.github.io/compat-
table/es6/)

~~~
pizlonator
That shows WebKit supporting tailcalls. It doesn’t a show Chrome supporting
tail calls.

I vividly remember us implementing tail calls and v8 not having them yet at
that time. This was almost 2 years ago.

~~~
justabystander
Chrome has had them for a while. Supposedly they just hid them behind a flag
because they weren't satisfied with some perceived deficiencies in the spec.
(Check out [https://v8project.blogspot.com/2016/04/es6-es7-and-
beyond.ht...](https://v8project.blogspot.com/2016/04/es6-es7-and-
beyond.html.)) WebKit did have it somewhere between mid-October to early
December of 2015.
([http://web.archive.org/web/20151207203829/http://kangax.gith...](http://web.archive.org/web/20151207203829/http://kangax.github.io:80/compat-
table/es6/)) Chrome didn't get it until late April of the next year
([http://web.archive.org/web/20160526102037/http://kangax.gith...](http://web.archive.org/web/20160526102037/http://kangax.github.io:80/compat-
table/es6/)), though there's no snapshot until late May. People worked on the
spec in a different order.

Chrome also had a failing array prototype under some non-standard syntax for a
while. Despite claiming 100%, Kangax didn't show them passing. Test results
have fluctuated as the tests themselves were refined. I've seen some passing
results later turn into fails. That's why none of the browsers are at 100% for
ES6 currently.

I'm still grudging at Apple for the year's delay between Safari 9 and 10,
which left all the clueless Apple customers on ~53% ES6. Yes, WebKit had
regular updates, but they didn't do a gradual release and few people thought
to install WebKit instead of Safari (or even the TP). Other browsers had much
better beta channels than Apple. And didn't pointlessly delay on things like
WebRTC. Or block other browser engines like iOS to protect their app store.

Chrome did a good job of releasing updates gradually, but there are still some
ES6 performance issues to be ironed out.

~~~
alwillis
_I 'm still grudging at Apple for the year's delay between Safari 9 and 10,
which left all the clueless Apple customers on ~53% ES6._

But Apple got to 100% ES6 support before anyone else:
[https://twitter.com/webkit/status/728643624464883712?lang=en](https://twitter.com/webkit/status/728643624464883712?lang=en)

------
iddan
Another great reason to migrate Electron to WebKit. With WebKit and JSC
Electron will be faster and will use a zero amount of RAM and battery!

~~~
SeoxyS
We shouldn't be migrating Electron to anything… we should be getting rid of
it. Electron is a cop-out for mediocre dev teams to make mediocre desktop
apps. The result is a world where we run apps like Spotify and Slack are the
main battery-killers because their engineering teams were too lazy to make a
real native app.

~~~
fooey
You assume that if there wasn't Electron that those apps would exist at all.

~~~
douche
Maybe if they can't invest in proper native apps, they shouldn't exist.
Electron is a scourge - clock speeds are not getting any faster, and tying a
user application to a single-threaded execution model would have been
recognized as suicidal a decade ago.

~~~
Vinnl
Can't you just not use them if you don't want to, rather than wishing all
other people wouldn't be able to use them either?

~~~
douche
I can wish for something better. It's frustrating when I look at what desktop
applications looked like and ran like ten or fifteen years ago, and how little
has appreciably changed now, beside ballooning resource requirements.

~~~
Vinnl
I think what fooey meant (and what I agree with) is that what has changed now
is that those apps exist at all: compared to ten or fifteen years ago, more
apps are written now, they work better and on more platforms, and they are
updated more frequently. Tools like Electron play a part in that.

Sure, we could wish that more effort would be spent while producing just as
much. Realistically, though, that's not going to happen, and that's not due to
people being lazy.

------
inian
Updated numbers with Dev versions of other browsers -
[https://twitter.com/bmeurer/status/871962560324657153](https://twitter.com/bmeurer/status/871962560324657153)

The difference in speed is much lesser. Wonder how this will all change by the
time their technical preview actually makes it to stable.

------
jacobolus
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.

~~~
franciscop
Do you mean that you saw actual differences when using Javascript in a normal
website? Or that they were slower than the alternatives in a synthetic
benchmark? It would be _really_ surprising that those were the performance
bottlenecks.

------
projectorlochsa
Firefox on Sierra is extremely slow. Not just javascript but everything else.
Can't understand how it differs so much compared to being run on Ubuntu.

~~~
1k2ka
I have the exact same experience. Firefox on macOS is sluggish but on the same
machine on Linux it's very responsive.

------
zurn
Will this translate to better performance for languages that compile to
Javascript and have so far used pre-ES6 constructs?

------
hoodoof
A bit odd that they don't call it ES2015.

~~~
pizlonator
We were calling it ES6 since before it was called ES2015.

~~~
hoodoof
>> We were calling it ES6 since before

Who is "we"?

~~~
pizlonator
The WebKit team.

------
_pmf_
> ES6 requires completely new compiler and runtime features in order to get
> the same level of performance that we have with ES5.

Given that other languages mandate that additional features have zero overhead
if unused, this seems like a particularly bad way of evolving a language.

------
williamle8300
This is huge. Jeff Atwood was right all along...

