Live data from Hacker News

WebKit is now 100% ES6 complete

twitter.com

51–60 of 119 posts

Re: WebKit is now 100% ES6 complete

#51
post #49
post #33

Earlier quoted context omitted.

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.

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.

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

Re: WebKit is now 100% ES6 complete

#52

Earlier quoted context omitted.

I tried for about a week. My complaints with it were the same i have with base Safari, but TP specifically worked fine. No unique issues despite using it as dev platform and a consumer browser.

I wish Safari would have the same incognito mode as Chrome's. Currently, tabs in the same incognito window do not share sessions so you have to log in again on every new tab.

Yep. If I command-click a same-domain link I expect my login to be forwarded to the new tab.

Re: WebKit is now 100% ES6 complete

#53
post #19

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?

We wrote about this in detail in http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.htm... 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.

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

Re: WebKit is now 100% ES6 complete

#54
post #19

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?

We wrote about this in detail in http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.htm... 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.

Our approach was to make our debugger still show those frames, and to observe that in the year since we've had tail calls in builds, we haven't seen a single compatibility issue from the change to error.stack behavior.

Re: WebKit is now 100% ES6 complete

#55
post #46

Earlier quoted context omitted.

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…

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.

[deleted]

Re: WebKit is now 100% ES6 complete

#56

Earlier quoted context omitted.

We wrote about this in detail in http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.htm... 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.

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 a…

We figured out such a mechanism and we call it ShadowChicken: http://trac.webkit.org/changeset/199076

It works great!

Re: WebKit is now 100% ES6 complete

#57

Earlier quoted context omitted.

We wrote about this in detail in http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.htm... 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.

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 a…

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

Re: WebKit is now 100% ES6 complete

#58
post #19

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?

There's been heavy discussion (especially recently) on the value of implicit TCO for developers. I believe all three V8/Chakra/Spidermonkey all found TCO regresses performance a bit. Additionally, it hampers debugging considerably as call stacks are completely twisted. There's been a lot of active discussion between browser vendors and TC39 recently to sort out a path forward. All teams are excited about explicit TCO…

How does tail call optimization cause a regress in performance? Superficially, it seems very counter-intuitive that this should even be possible.

Re: WebKit is now 100% ES6 complete

#59

Earlier quoted context omitted.

We wrote about this in detail in http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.htm... 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.

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 a…

[deleted]
Post reply on HN