
WebKit is now 100% ES6 complete - M4v3R
https://twitter.com/webkit/status/728643624464883712
======
zerocrates
The jump in support from Safari 9 (53%) to TP (99%, and then the last little
bit from TP to current WebKit) is staggering.

------
swang
Webkit was probably one of the last major web engines to start integrating ES6
features, yet they have TCOs done. Anyone explain what's holding it up in
Chrome/FF/Edge?

~~~
LittleDan
We wrote about this in detail in
[http://v8project.blogspot.com/2016/04/es6-es7-and-
beyond.htm...](http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.html)
under the heading "Proper Tail Calls".

tl;dr we implemented it, it works, but we are not shipping it because we
believe it would hurt developers to lose some stack frames from Error.stack in
existing sites, among other issues.

~~~
Dylan16807
If the main worry is information loss when debugging, why not figure out a
mechanism that's 98% accurate but much more efficient than a full redundant
shadow stack?

For example, you could compact the stack every 200 frames it grows, but never
remove frames in the top 50 or bottom 50. How often in practice would that
give you a misleading view of the stack? (Assume that each frame keeps track
of how many tail frames are omitted after it. If needed, assume that tail
frames within X distance of a non-tail frame will not be omitted ever.)

~~~
LittleDan
pizlonator, Is ShadowChicken cheap enough to turn on all the time and make
Error.stack work similarly to without PTC?

~~~
pizlonator
It probably could be, but we deliberately don't do it, because:

1) I'm not aware of complaints about the change to error.stack behavior from
users or developers. I don't know of an app that broke because of the change
to error.stack. I don't know of an app whose telemetry got messed up because
of the change to error.stack. So, we don't have a real-world test case that
would be improved or fixed by integrating ShadowChicken into error.stack.
We're not going to impose any overhead, or spend time trying to optimize that
overhead, if it isn't going to benefit anyone.

I've heard lots of hypothetical fears about error.stack changing, but I
haven't seen a real-world example of the change in error.stack behavior being
harmful. If you know of an app that breaks because of our error.stack change,
please let us know!

2) Philosophically, we view the feature as PTC (proper tail calls), not TCO
(tail call optimization). If it was an optimization then we'd want it to be
hidden from the user. But that's not what PTC is: it's a guarantee to the user
about how the stack will behave. Therefore, we make error.stack precisely
reflect PTC. We go to great lengths to emulate PTCs in some cases to make this
work, for example if the optimizing JIT is involved. For example:

function foo() { ... } // say that this is inlined

function bar() { return foo(); } // this tail-calls foo. say that this is
inlined

function baz() { return bar() + 1; } // say that our top-tier JIT compiles
this

In this case, foo and bar will sort of cease to exist since all that really
matters for execution is the code that the JIT generated for baz, which now
also includes the code for foo and bar. Inlining is super careful about
error.stack. In this case, our optimizing JIT's inlining data will include
complete information about the call stack (baz->bar->foo) but will flag the
bar frame as tail-deleted so that error.stack will only show baz->foo.

So, instead of making ShadowChicken hide PTC from error.stack, we actually
have an entirely separate set of features to make error.stack precisely
reflect the reality PTC. On the other hand, if you open the inspector, we want
ShadowChicken to show you the tail-deleted frames and to flag them
appropriately. The inspector integration WIP is here:
[https://bugs.webkit.org/show_bug.cgi?id=156685](https://bugs.webkit.org/show_bug.cgi?id=156685)

Screenshot:
[https://bug-156685-attachments.webkit.org/attachment.cgi?id=...](https://bug-156685-attachments.webkit.org/attachment.cgi?id=279050)

TL;DR. JSC doesn't try to lie to its clients about PTC. PTC is part of the
language, so we precisely reflect PTC's behavior in error.stack and in the
inspector (the tail-deleted frames show up but are flagged as such).

(EDIT: I changed the definition of bar and baz above because my original
example didn't have the tail calls that I wanted.)

~~~
xixixao
I will bite the bullet: Do you have a sense of how many devs use Safari
compared to Chrome/FF for debugging?

~~~
pizlonator
I don't have such numbers, and I'm not sure they would be relevant to this
discussion.

We already know that debugging isn't the issue. ShadowChicken solves the
debugging problem and other VMs could do it, too. ShadowChicken is just one
possible algorithm in a much larger family of chicken algorithms.

The only way that PTCs are observable outside the debugger - beyond making you
run faster and use less memory - is error.stack. Hence the challenge: find me
a website that uses error.stack in such a way that PTC breaks that website.
Surely if the other VMs are so against PTC on the grounds that it will break
websites, they will be able to tell us about a website that broke in Safari
because of PTC.

------
pygy_
Yet only 98% ES5 compliant: [https://kangax.github.io/compat-
table/es5/](https://kangax.github.io/compat-table/es5/)

No browser is at 100%, BTW.

Waiting for a WATWG JavaScript standard that removes these parts from the
spec...

~~~
domenicd
Are you aware of
[https://javascript.spec.whatwg.org/](https://javascript.spec.whatwg.org/)? :)
Thankfully that spec is almost obsolete as TC39 has moved much of it into the
main spec over time. It used to be the only place important de-facto language
features like __(define|lookup)(Getter|Setter)__, or String.prototype.blink,
or Function.prototype.{arguments,caller} were specified. You can see the
history of it getting smaller in
[https://github.com/whatwg/javascript/commits/master](https://github.com/whatwg/javascript/commits/master).

On the subject of the table, it's interesting that Firefox's only failure is
in "Date.parse produces NaN for invalid dates". However, as far as I can tell
this is not a requirement of the spec, since per
[https://tc39.github.io/ecma262/#sec-
date.parse](https://tc39.github.io/ecma262/#sec-date.parse)

> If the String does not conform to that format the function may fall back to
> any implementation-specific heuristics or implementation-specific date
> formats.

~~~
lisivka
IMHO, we should switch from that mess to common repository of JS libraries
(CJSAN), which can be referred using tags like <lib name="foo"
version="1.0"><script .../></lib>. Such libraries will act as polyfills for an
API, while browsers will be able to provide optimized versions of these
libraries.

I.e. instead of waiting for ecma262 to be implemented by all browsers, scripts
can just load common polyfill, which then can be overridden by browser later:

    
    
       <lib name="ecma262" version="1.0"><script scr="https://cdn.host/ecma262.polyfill.js"/></lib>

------
coldtea
Heh, after I saw it was 96-7% last time (when the developer preview versions
were announced), I was pretty sure they'd push it to 100% soon, to make a
(small) point of it on the WWDC Keynote.

------
taf2
This is nice. But I still think platform features in WebKit such as webrtc and
fewer bugs in indexeddb would be a better place for them to focus... Service
workers too

------
acbabis
Does this include native module import/export? I never saw anything to suggest
they were even working on that.

~~~
jasonellis
Module import/export syntax was in ES6, but the browser implementation has not
yet been standardized.

~~~
domenicd
Well, it's been standardized, but implementation work is still ongoing.
Details at [https://blog.whatwg.org/js-modules](https://blog.whatwg.org/js-
modules)

~~~
acbabis
I'm confused by what it means that the semantics of imports weren't part of
the spec yet. Do you mean polyfills like es6-module-loader
([https://github.com/ModuleLoader/es6-module-
loader](https://github.com/ModuleLoader/es6-module-loader)) were just guessing
how modules would behave?

~~~
domenicd
Yes, that's exactly correct. Babel, polyfills, etc. were all just guessing at
the future.

~~~
anonymoose1234
When TC39 creates ES modules, it's re-inventing the wheel ("The node community
has already made modules that work, why'd you make a new one??").

When the Babel community creates a module loading approach, it's guessing at
the future ("The spec is the law! When the community makes something, it's
guessing at the law!").

------
nfriedly
Note that this doesn't include ES6 modules. The referenced kangax
compatibility table doesn't cover modules, so the tweet is technically
correct, but the headline here on HN is a bit misleading.

~~~
azinman2
They're in JavascriptCore, just not yet integrated into WebCore fully.

[https://bugs.webkit.org/show_bug.cgi?id=147340](https://bugs.webkit.org/show_bug.cgi?id=147340)

------
kozak
If I had to choose between having all the ES6 features except modules, versus
having ES6 modules without all the other ES6 features, I would choose the
latter. Sure, I'm biased, because I'm working on a huge single-page app with
gazillion lines of JS code...

~~~
udp
Although I'm also looking forward to ES6 modules, I've completely forgotten
about the issue since I started using Browserify. It "just works".

------
joeblau
Is anyone using Safari Technical Preview as their main Browser? I was hesitant
to use it, but I've heard a few people say that it's stable.

~~~
cormacrelf
It was good for a bit, then 1Password broke and I accepted that my Slack
messages were never going to load.

It's a dev preview. There is no reason to use it as your main browser. There
isn't even much point testing your site in it, since you can never tell who's
responsible for something being broken, and it becomes more a test of how
production-ready the preview is, which is a really pointless metric. The only
real reason for its existence is so we can all track progress in benchmarks,
and for this story to get publicity when all us browser nerds check ES6 compat
and then try little code snippets in the console.

If you want the cool purple icon, copy it to to Safari 9. That's what I've
done.

~~~
joeblau
Ah if 1Password doesn't work, that's definitely a blocker for me. I could
always copy the usernames and passwords from the app, but I don't think I need
to test the latest and greatest features that badly.

~~~
mackey
I think that was fixed in the last TP.

~~~
joeblau
I don't think I'll be able to handle any instability in that right now. My
primary development focus doesn't involve web development so having the latest
and greatest browser won't benefit me that much. I do want to try the latest
features, but I have patience and can wait a few more months.

~~~
nizmow
I mean, you can have it installed alongside regular Safari and just switch
between them at will. It's not an all or nothing decision.

------
hmottestad
So, today I'm using babel to transpile my code to es5.

Anyone know of any good tooling to use transpiled code for older browsers and
es6 for newer?

~~~
saidajigumi
It'd be nice to see support similar to Autoprefixer[1]'s use of Browserlist
queries[2]. Those let the developer to specify the desired target platforms by
browser versions, by global usage stats (e.g. '> 5%'), or by custom usage
stats ('> 5% in my stats') etc., and derive the correct prefixes needed to
deploy to those targets.

EDIT (for clarity): It'd be great to see similar query support to derive a
"lowest common denominator" Babel preset for an intended ES generation vs.
browser profile set.

[1]
[https://github.com/postcss/autoprefixer](https://github.com/postcss/autoprefixer)
[2]
[https://github.com/ai/browserslist#queries](https://github.com/ai/browserslist#queries)

~~~
hzoo
Yep, it's our plan to do something like that with community help - have a PR
open for discussion at
[https://github.com/babel/babel/pull/3476](https://github.com/babel/babel/pull/3476).

Also
[https://twitter.com/samccone/status/722826060161617923](https://twitter.com/samccone/status/722826060161617923).

------
hoodoof
Is ES6 native much faster than transpiled?

~~~
brokentone
From my limited anecdotal testing no. In fact it may be slower. This is a good
view of this: [https://kpdecker.github.io/six-
speed/](https://kpdecker.github.io/six-speed/)

However... the potential upside is size. Native code will usually be smaller,
which for a web client is a win.

~~~
antjanus
I'm having trouble reading the table, when it says 16x slower, is it saying
the implementation is slower or the engine?

~~~
jdcarr
You might be missing the header row of the table listing various engines and
their versions, and the little note that says "Performance of ES6 features
relative to the ES5 baseline operations per second."

And I would assume that the baseline has been established on a per-engine
basis.

------
feiss
Watching that table makes me think it's about time to start switching to es6

~~~
fooey
And then, IE happens to your plans.

~~~
anarchy8
Ever heard of Babel?

~~~
fooey
If you're using Babel already, WebKit hitting 100% support is irrelevant. IE
is going to be the thing that prevents us from running ES6 natively in the
browser for several years more.

~~~
Joeri
I was going to reply it wasn't that long, until i realized ie will be around
in meaningful numbers for another 4 years. Windows 7 is supported until 2020,
and IE is the only game in town there for enterprises. The new distribution
policies of w10 will mean plenty of places will run out the clock on w7
support. So, yeah, I guess we're supporting IE 11 for half a decade to come.

~~~
ddoolin
I think we're going to see high IE usage in some markets well past that point.
Just as an example, almost every Korean website that keep any sensitive data
(and many, many that don't), rely on old IE plugins that are never going to be
supported by Edge. Although the gov't is now throwing money at developers to
rid themselves of the outdated tech, it's going to be a long process.

Chrome JUST took over IE in market share in the last few months here. All
other browsers are sub-5%.

------
Bahamut
Anyone have any clue when we'll see this land in Safari?

~~~
hochchristoph
Probably at WWDC, between June 13 and June 17.

~~~
glhaynes
Likely in the developer previews that they release during WWDC then available
to consumers in the fall.

~~~
hochchristoph
I don't think that it will take this long. They pushed out Safari 9.1 this
year, which saw pretty significant changes. I think they could release the
things from the tech preview with a 9.2 release for El Cap, maybe a month from
now (WWDC coincidently?)

------
_RPM
open up chrome console, type `class Foo { }` and it works now out of the box.
For what it's worth, when you try define a class that already exists. it
throws an error. It seems that re-defining an identifier with the `var`
keyword will throw an error too. I don't remember this being the case before.

~~~
TheCoreh
Maybe code on the REPL is being evaluated with strict mode on?

~~~
_RPM
is there a `isUseStrictOn()` equivalence? [0]

[0] var isStrict = (function() { return !this; })();

------
TylerH
Maybe now they can fix all their layout bugs they've been adding to the
browser and not fixing.

~~~
Fedex
Not to be inflammatory, just honestly curious, which layout bugs you're
referencing?

------
nailer
I guess this means JScore, right? So Phantom will also be ES6 when it updates.

------
anarsdk
tfw when "complete" has degrees. sigh.

I'm 99% super confident that this is an _almost_ optimal solution.

~~~
oneeyedpigeon
Of course it does. If you're working on a task that will take hundreds of
hours and your boss asks how far along you are, is your only possible response
either "finished" or "not finished"?

~~~
Cthulhu_
And even when you think it's "finished", is that really true? I'm pretty sure
no software is ever 100% finished / to spec, esp when the spec is ambiguous
like most specs are.

