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.
WebKit is now 100% ES6 complete
61–70 of 119 posts
Re: WebKit is now 100% ES6 complete
#62Webkit 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.
Ah, too bad to hear that's the route you're going that route given the discussion here https://twitter.com/getify/status/716861612850749440
What changed your/the team's mind?
Re: WebKit is now 100% ES6 complete
#63Earlier quoted context omitted.
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?
In the linked commit the "readme" states a 6% overhead.
Re: WebKit is now 100% ES6 complete
#64Earlier 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.
I think that was fixed in the last TP.
Re: WebKit is now 100% ES6 complete
#65Earlier quoted context omitted.
Well, it's been standardized, but implementation work is still ongoing. Details at https://blog.whatwg.org/js-modules
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 ) were just guessing how modules would behave?
The wonders of standards: the standards committee for JS language syntax (ECMA TC39) is a different standards committee from the committee for Browser behaviors like loading (WHATWG). (So many standards bodies to choose from!) The WHATWG Module Loader spec has been slower to be "finalized" and adopted than the ES2015 spec.
Re: WebKit is now 100% ES6 complete
#66Earlier 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.
At the very least, if you use Safari for development you won't need to run Babel every time you change something and want to test it, only for release builds or when you want to test on other browsers, which is nice.
There are a lot of node/npm modules that aren't ES6 friendly... unless they pull in and shim out cjs/npm modules, then it will still be some time before it's really useful.
Re: WebKit is now 100% ES6 complete
#67Earlier quoted context omitted.
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?
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
Screenshot: https://bug-156685-attachments.webkit.org/attachment.cgi?id=...
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.)
Re: WebKit is now 100% ES6 complete
#68Earlier quoted context omitted.
Well, it's been standardized, but implementation work is still ongoing. Details at https://blog.whatwg.org/js-modules
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 ) were just guessing how modules would behave?
Yes, that's exactly correct. Babel, polyfills, etc. were all just guessing at the future.
Re: WebKit is now 100% ES6 complete
#69Earlier quoted context omitted.
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.
It's not a performance regression in JSC. Maybe the other implementations aren't as good as JSC's.
Re: WebKit is now 100% ES6 complete
#70Earlier quoted context omitted.
pizlonator, Is ShadowChicken cheap enough to turn on all the time and make Error.stack work similarly to without PTC?
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 ShadowC…
I will bite the bullet: Do you have a sense of how many devs use Safari compared to Chrome/FF for debugging?