Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebKit is now 100% ES6 complete

twitter.com

Post reply on HN
Print view View original

71–80 of 119 posts

Re: WebKit is now 100% ES6 complete

#71

Post by domenicd »

WorldMaker wrote: post #65
acbabis wrote: post #32

Earlier quoted context omitted.

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.

Although your larger point stands, about the division of responsibilities, it's important to distinguish "specifying browser module loading" from the Loader spec draft.

The loader repository at https://whatwg.github.io/loader/ is an experimental proving ground, as noted by its title ("A Collection of Interesting Ideas") and its Status section ("This document is a work in progress and dreams of becoming a living standard."), as well as the fact that it's in the whatwg.github.io namespace instead of the spec.whatwg.org namespace. To my knowledge no browser implementers have begun implementation of the experimental ideas here.

Contrast that with the agreed-upon work in the WHATWG HTML Living Standard discussed at https://blog.whatwg.org/js-modules, which is relatively finalized and is being actively implemented now in all browser engines.

I think we will see a gradual stabilization of the experimental ideas in the Loader spec, either in the Loader spec itself (with the stable ideas staying, and the experimental ones moving to a supplementary document) or by moving the relevant spec text into other locations (HTML and/or ES, probably). For example, I would hope that we will soon see a very simple promise-returning `importModule("./foo.js")` async module loading API, far ahead of the loader's more experimental in-browser-transpilation APIs or create-a-module-from-scratch-reflectively APIs. That could be done either by specifying it in the Loader spec, or by specifying it in ES with a call-out to a HostFetchModule() abstract operation, which HTML then specifies for browser hosts.

Re: WebKit is now 100% ES6 complete

#72

Post by joeblau »

mackey wrote: post #64
joeblau wrote: post #46

Earlier quoted context omitted.

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.

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.

Re: WebKit is now 100% ES6 complete

#73

Post by [deleted] »

pizlonator wrote: post #67
LittleDan wrote: post #57

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

[deleted]

Re: WebKit is now 100% ES6 complete

#74

Post by __s »

j_jochem wrote: post #58
paulirish wrote: post #27

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

Messes with calling conventions. Citing Rust: https://mail.mozilla.org/pipermail/rust-dev/2013-April/00355...

Re: WebKit is now 100% ES6 complete

#75

Post by domenicd »

pygy_ wrote: post #60

Yet only 98% ES5 compliant: 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...

Are you aware of 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.

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

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

Re: WebKit is now 100% ES6 complete

#76

Post by pizlonator »

xixixao wrote: post #70
pizlonator wrote: post #67

Earlier quoted context omitted.

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?

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.

Re: WebKit is now 100% ES6 complete

#77

Post by pizlonator »

__s wrote: post #74
j_jochem wrote: post #58

Earlier quoted context omitted.

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

Messes with calling conventions. Citing Rust: https://mail.mozilla.org/pipermail/rust-dev/2013-April/00355...

I agree that it messes with calling conventions.

This is a problem for AOT languages, where binary compatibility is paramount and so you cannot change the calling convention. Since tail calls don't play well with existing native conventions, they end up being hard (or sometimes even impossible) to implement.

That's not really an issue in JS or other VM-based languages. JS VMs don't make their internal calling conventions public. In JSC, our old calling convention was incompatible with PTC, so we changed our calling convention to make PTCs work.

Re: WebKit is now 100% ES6 complete

#80

Post by wycats »

domenicd wrote: post #71
WorldMaker wrote: post #65

Earlier quoted context omitted.

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.

Although your larger point stands, about the division of responsibilities, it's important to distinguish "specifying browser module loading" from the Loader spec draft. The loader repository at https://whatwg.github.io/loader/ is an experimental proving ground, as noted by its title ("A Collection of Interesting Ideas") and its Status section ("This document is a work in progress and dreams of becoming a living stand…

> Contrast that with the agreed-upon work in the WHATWG HTML Living Standard discussed at https://blog.whatwg.org/js-modules, which is relatively finalized and is being actively implemented now in all browser engines.

Just to clarify, unlike TC39, the WHATWG HTML ("Living Standard") spec requires no consensus at all in order to add new features. Consensus is arrived at once all implementers have implemented the relevant features to the stable versions of their browsers.

To say that what is in the spec has consensus at the same time as browser implementers are beginning implementation (and expressing some concern over details) gets the WHATWG process backwards.

Post reply on HN