15 ms·
WebKit is now 100% ES6 complete
- zerocrates 10y agoThe jump in support from Safari 9 (53%) to TP (99%, and then the last little bit from TP to current WebKit) is staggering.
- deleted 10y ago[deleted]
- Bahamut 10y agoAnyone have any clue when we'll see this land in Safari?
- hochchristoph 10y agoProbably at WWDC, between June 13 and June 17.
- glhaynes 10y agoLikely in the developer previews that they release during WWDC then available to consumers in the fall.
- hochchristoph 10y agoI don't think that it will take this long. They pushed out Safari 9.1 this year, which saw pretty significant changes. I think they could release the things from the tech preview with a 9.2 release for El Cap, maybe a month from now (WWDC coincidently?)
- M4v3R 10y agoIn the latest Technology Preview [0] it's already at 99%. Next release on 25th May will have 100%. [0] https://developer.apple.com/safari/technology-preview/ https://developer.apple.com/safari/technology-preview/
- acbabis 10y agoDoes this include native module import/export? I never saw anything to suggest they were even working on that.
- msvan 10y agoImport/export has been postponed AFAIK.
- jasonellis 10y agoModule import/export syntax was in ES6, but the browser implementation has not yet been standardized.
- domenicd 10y agoWell, it's been standardized, but implementation work is still ongoing. Details at https://blog.whatwg.org/js-modules https://blog.whatwg.org/js-modules
- acbabis 10y agoI'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 https://github.com/ModuleLoader/es6-module-loader) were just guessing how modules would behave?
- WorldMaker 10y agoThe 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.
- domenicd 10y agoAlthough 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/ 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 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.
- hoodoof 10y agoIs ES6 native much faster than transpiled?
- connor4312 10y agoHere's a chart: https://kpdecker.github.io/six-speed/ https://kpdecker.github.io/six-speed/. Often the answer is "not yet". Transpilers convert the code to ES5, which has benefited from six years or optimization. New ES6 features will take some time to catch up.
- brokentone 10y agoFrom my limited anecdotal testing no. In fact it may be slower. This is a good view of this: https://kpdecker.github.io/six-speed/ https://kpdecker.github.io/six-speed/ However... the potential upside is size. Native code will usually be smaller, which for a web client is a win.
- antjanus 10y agoI'm having trouble reading the table, when it says 16x slower, is it saying the implementation is slower or the engine?
- jdcarr 10y agoYou might be missing the header row of the table listing various engines and their versions, and the little note that says "Performance of ES6 features relative to the ES5 baseline operations per second." And I would assume that the baseline has been established on a per-engine basis.
- cormacrelf 10y agoI remember having exactly this impression last time it popped up on HN. Bad design needs explaining.
- coldtea 10y agoHeh, after I saw it was 96-7% last time (when the developer preview versions were announced), I was pretty sure they'd push it to 100% soon, to make a (small) point of it on the WWDC Keynote.
- joeblau 10y agoIs 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.
- M4v3R 10y agoI did use the 1st release on a daily basis, but I had some problems with it (few websites misbehaved). I may revisit it since it's already at its 4th release and they fixed a ton of bugs judging from their release notes.
- liquidise 10y agoI 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.
- sotojuan 10y agoI 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.
- g4k 10y agoI 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 https://bugs.chromium.org/p/chromium/issues/detail?id=24690
- calebegg 10y ago"Long standing" makes me think it's an open issue, but it was closed as WontFix the same day it was filed, in 2009.
- Doctor_Fegg 10y agoYep. If I command-click a same-domain link I expect my login to be forwarded to the new tab.
- mlvljr 10y ago100% ES6 complete ...and abandoned in Qt5, since recently :(
- feiss 10y agoWatching that table makes me think it's about time to start switching to es6
- fooey 10y agoAnd then, IE happens to your plans.
- anarchy8 10y agoEver heard of Babel?
- fooey 10y agoIf 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.
- Chyzwar 10y agoMS now feel the pain when writing a lot web apps: Azure, Office 365, Outlook etc. MS already killed IE 8, 9, 10 and even added nagware in IE11.
- DrJokepu 10y agoAt 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.
- tracker1 10y agoThere 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.
- rhinoceraptor 10y ago
- swang 10y agoWebkit 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?
- nostrademons 10y agoThere's some debate over whether tailcalls should be explicit or implicit, and Chrome/FF/Edge are leaning towards the explicit side: https://news.ycombinator.com/item?id=11563305 https://news.ycombinator.com/item?id=11563305
- paulirish 10y agoThere'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 syntax, but there remains skepticism that implicit TCO is good for users or developers.
- Someone1234 10y agoTCO is "tail call optimization" if anyone is trying to figure it out.
- j_jochem 10y agoHow does tail call optimization cause a regress in performance? Superficially, it seems very counter-intuitive that this should even be possible.
- pizlonator 10y agoIt's not a performance regression in JSC. Maybe the other implementations aren't as good as JSC's.
- 10y ago
- hmottestad 10y agoSo, today I'm using babel to transpile my code to es5. Anyone know of any good tooling to use transpiled code for older browsers and es6 for newer?
- t1amat 10y agoWhat you are describing is serving up different assets based on user agent detection. The "tool" in this case would be the application responsible for serving it, most likely either your custom server-side web app code, or your web server itself. You should continue to use the transpilers for some time though. It has been reported that many ES6 features run quite a bit faster as transpiled ES5 than natively as ES6.
- Cthulhu_ 10y agoIt should be possible to do so client-side by having a bit of loading / bootstrapping JS that does the feature detection.
- t1amat 10y agoWhile technically feasible that is a low quality solution for the sake of keeping the solution space in JavaScript. JavaScript-based feature detection is one thing but conditionally loading the entire application is another. It is wholly pointless if you are already transpiling to ES5, and as mentioned numerous times, a performance problem in at least the short term.
- saidajigumi 10y agoIt'd be nice to see support similar to Autoprefixer[1]'s use of Browserlist queries[2]. Those let the developer to specify the desired target platforms by browser versions, by global usage stats (e.g. '> 5%'), or by custom usage stats ('> 5% in my stats') etc., and derive the correct prefixes needed to deploy to those targets. EDIT (for clarity): It'd be great to see similar query support to derive a "lowest common denominator" Babel preset for an intended ES generation vs. browser profile set. [1] https://github.com/postcss/autoprefixer https://github.com/postcss/autoprefixer [2] https://github.com/ai/browserslist#queries https://github.com/ai/browserslist#queries
- nfriedly 10y agoNote that this doesn't include ES6 modules. The referenced kangax compatibility table doesn't cover modules, so the tweet is technically correct, but the headline here on HN is a bit misleading.
- azinman2 10y agoThey're in JavascriptCore, just not yet integrated into WebCore fully. https://bugs.webkit.org/show_bug.cgi?id=147340 https://bugs.webkit.org/show_bug.cgi?id=147340
- jherdman 10y agoThe opposite appears to be the case: https://twitter.com/xeenon/status/729086068666982401 https://twitter.com/xeenon/status/729086068666982401
- pygy_ 10y agoYet only 98% ES5 compliant: https://kangax.github.io/compat-table/es5/ 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...
- domenicd 10y agoAre you aware of https://javascript.spec.whatwg.org/ 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 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 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.
- lisivka 10y agoIMHO, we should switch from that mess to common repository of JS libraries (CJSAN), which can be referred using tags like <lib name="foo" version="1.0"><script .../></lib>. Such libraries will act as polyfills for an API, while browsers will be able to provide optimized versions of these libraries. I.e. instead of waiting for ecma262 to be implemented by all browsers, scripts can just load common polyfill, which then can be overridden by browser later: <lib name="ecma262" version="1.0"><script scr="https://cdn.host/ecma262.polyfill.js"/></lib>
- pygy_ 10y agoMaybe I should have said a WATWG YavaScript standard... I didn't know the standard existed. Generally, agree with the "let's put back every piece of dung in place after paving the cowpath" approach the WHATWG follows. Anosmic folks come to rely on the reduced friction coefficient... I suppose that the Date.parse stuff was updated between ES5 and the living stabdard.
- _RPM 10y agoopen 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.
- TheCoreh 10y agoMaybe code on the REPL is being evaluated with strict mode on?
- _RPM 10y agois there a `isUseStrictOn()` equivalence? [0] [0] var isStrict = (function() { return !this; })();
- ravenstine 10y agoIt's been hours and nobody has showed up to call this an atrocity? The JS world really is improving.
- nailer 10y agoI guess this means JScore, right? So Phantom will also be ES6 when it updates.
- joantt 10y agonicest
- taf2 10y agoThis is nice. But I still think platform features in WebKit such as webrtc and fewer bugs in indexeddb would be a better place for them to focus... Service workers too
- deleted 10y ago[deleted]
- TylerH 10y agoMaybe now they can fix all their layout bugs they've been adding to the browser and not fixing.
- Fedex 10y agoNot to be inflammatory, just honestly curious, which layout bugs you're referencing?
- anarsdk 10y agotfw when "complete" has degrees. sigh. I'm 99% super confident that this is an almost optimal solution.
- oneeyedpigeon 10y agoOf course it does. If you're working on a task that will take hundreds of hours and your boss asks how far along you are, is your only possible response either "finished" or "not finished"?
- Cthulhu_ 10y agoAnd even when you think it's "finished", is that really true? I'm pretty sure no software is ever 100% finished / to spec, esp when the spec is ambiguous like most specs are.
- kozak 10y agoIf I had to choose between having all the ES6 features except modules, versus having ES6 modules without all the other ES6 features, I would choose the latter. Sure, I'm biased, because I'm working on a huge single-page app with gazillion lines of JS code...
- k__ 10y agoAs far as I know modules aren't a ES6 feature. Edit: To clarify, I want them standardized more than anything else, but as far as I know ES6 only specified the syntax
- udp 10y agoAlthough I'm also looking forward to ES6 modules, I've completely forgotten about the issue since I started using Browserify. It "just works".