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.
WebKit is now 100% ES6 complete
81–90 of 119 posts
Re: WebKit is now 100% ES6 complete
#82Earlier 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.
Re: WebKit is now 100% ES6 complete
#83Earlier 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…
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
#84Earlier 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".
Re: WebKit is now 100% ES6 complete
#85Earlier 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.
Re: WebKit is now 100% ES6 complete
#86Earlier 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.
Re: WebKit is now 100% ES6 complete
#87Re: WebKit is now 100% ES6 complete
#88Earlier 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
Re: WebKit is now 100% ES6 complete
#89Webkit 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.
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
#90Earlier 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…
http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-...