Live data from Hacker News

WebKit is now 100% ES6 complete

twitter.com

81–90 of 119 posts

Re: WebKit is now 100% ES6 complete

#81
post #13

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.

It is my main browser. Last week there was an update that bricked it. I had to redownload it from apple.com ignorer to get it to work. Other than that it is very good, can't really tell the difference between it, webkit nightly, and reg safari (I don't dev on bleeding-edge though).

Re: WebKit is now 100% ES6 complete

#82
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?

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

I wouldn't say es6ml was "guessing", it was based on the old loader spec that was removed from ES2015, and was quite accurate. It's no longer relevant though, since whatwg/loader is quite different.

Re: WebKit is now 100% ES6 complete

#83
post #80

Earlier quoted context omitted.

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

That's not correct, Yehuda. For HTML especially, we work on a rough consensus model wherein features are not added to the spec unless they have multi-vendor implementation interest and review.

If you'd like to analogize to the TC39 process, features are merged into the HTML Standard once they've reached TC39 "stage 3".

Re: WebKit is now 100% ES6 complete

#84
post #80

Earlier quoted context omitted.

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

That's not correct, Yehuda. For HTML especially, we work on a rough consensus model wherein features are not added to the spec unless they have multi-vendor implementation interest and review. If you'd like to analogize to the TC39 process, features are merged into the HTML Standard once they've reached TC39 "stage 3".

So are you saying that, for example, the change to CORS from in has multi-vendor consensus?

Re: WebKit is now 100% ES6 complete

#85

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.

It's not a performance regression in JSC. Maybe the other implementations aren't as good as JSC's.

Shots fired.

Re: WebKit is now 100% ES6 complete

#86
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.

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.

Setting up a build watcher in Grunt/Gulp/etc is really worth the time savings, especially if you use Live Reload. I make a change to a file in vim, and the page reloads with the new build.

Re: WebKit is now 100% ES6 complete

#88
post #31

Earlier quoted context omitted.

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.

I prefer it this way around. There is even a long standing issue in the Chromium bug tracker https://bugs.chromium.org/p/chromium/issues/detail?id=24690

"Long standing" makes me think it's an open issue, but it was closed as WontFix the same day it was filed, in 2009.

Re: WebKit is now 100% ES6 complete

#89
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.

I program in Lua, which does to TCO and I've never found it to be an issue with debugging. Now, that could be because of the ways I use TCO---I tend to use it in a recursive routine:

    function mainloop()
      local packet = receive()
      if not packet then
        syslog('warning',"error")
        return mainloop()
      end
      process(packet)
      return mainloop()
    end
(mainly because Lua does not have a 'continue' statement, and this is the best way I've found to handle that) or in state machines:

    function state_a(state)
      return state_b(state)
    end

    function state_b(state)
      return state_c(state)
    end

    function state_c(state)
      if somecondition()
        return 'done'
      else
        return state_a(state)
      end
    end
The thing to remember is that a TCO is a form of GOTO. And with GOTO, you have no stack entry, but given that this is a controlled GOTO, I don't see much wrong with it. Do most programmers find TCO that confusing? Or is it the perception that most programmers will find TCO confusing? Have any real studies been done?

Re: WebKit is now 100% ES6 complete

#90
post #89

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.

I program in Lua, which does to TCO and I've never found it to be an issue with debugging. Now, that could be because of the ways I use TCO---I tend to use it in a recursive routine: function mainloop() local packet = receive() if not packet then syslog('warning',"error") return mainloop() end process(packet) return mainloop() end (mainly because Lua does not have a 'continue' statement, and this is the best way I've…

You will like the examples in the `original TCO' paper.

http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-...

Post reply on HN