Safari Technology Preview supports 100% of the ES2015/16/17 features | Hacker News Reader

17 features

kangax.github.io

202 pointsnacs124 comments

At the same time, right now it's relly backwards[1]. Luckily the shelf-life of Safari is much shorter than others, so we'll be able to use fetch() natively without polyfills soon-ish if you target modern browsers.

[1] http://caniuse.com/#feat=fetch

This is the important list. I don't care about ES2015 or more—we'll always use Babel. I care about Service Workers and WebRTC more.

We'll use babel for builds.

Most development will be happening on modern browsers, so being able to reduce compilation requirements improves your iteration cycle and it makes it much easier to debug.

Source maps have lots of issues. Compare debugging async/await usage between the compiled and native version.

If you're working on a larger project, compilation times start becoming a huge pain. Cutting down on the number of transformations reduces development latency.

Of course, all of this is true. It makes the life of a developer marginally easier. Unless there are edge cases where Babel and browser-native functionality differs.

Either way, WebRTC and Service Workers would allow us to expose totally new functionality to users. Huge difference.

Even if you use Babel your users will still benefit from less polyfill.

I wish someone would come up with something better than webrtc. It's such a mess, and appears to be impossible to standardise.

Is WebRTC ready yet? Completion Score: 68.5% http://iswebrtcreadyyet.com/

WebRTC 1.0: Real-time Communication Between Browsers https://w3c.github.io/webrtc-pc/

Identifiers for WebRTC's Statistics API (Draft) https://w3c.github.io/webrtc-stats/

Media Capture and Streams (Draft) https://w3c.github.io/mediacapture-main/

Nearly all these new language features can be polyfilled, so this doesn't change anything for most developers.

On the other hand, WebRTC and Service Workers would make Safari meaningfully better, since these cannot be polyfilled.

Not Proxy, which I'm using heavily in a recent experimental project. Luckily since I started Safari came up to the 10 which supports them, and most of Safari users are already in the version 10. Which is a crazy (in a good way) adoption rate.

too bad fetch still can't abort a request.

Ah that's true, I totally forgot about that but it was one of my main complains about promises in general. Apparently it's slowly coming:

http://stackoverflow.com/questions/30233302/promise-is-it-po...

Honnest question for Safari users: why Safari?

I don't really know Safari. I used Chrome on Windows and iOS, and when I moved to OSX I naturally continued with Chrome. And the dev tools are really great.

More power efficient which is key because I use a laptop all the time, and often on battery power. It fits better with macOS conventions compared to Chrome and Firefox. It's faster. Safari content blockers (I use 1Blocker) seems to not slow down page loading at all compared to conventional ad-blockers on both Safari and Chrome, which does.

I used Chrome on Mac for years. Then Safari became better, and then it kept getting better with the addition of the Safari Developer Preview[1]. It's not even funny anymore how far behind Chrome is compared to Safari when it comes to UI and UX.

[1]: https://developer.apple.com/safari/technology-preview/

The power efficiency isn't even close. The 2016 MBP battery lasts about 10 hours running Safari versus 3 hours running Chrome. I've never particularly liked Safari, but I'm close to switching myself because Chrome is such a disaster.

From the energy impact tab on the Activity Monitor:

Chrome: 43

Safari: 0.3

+1. I use Safari for everything work, personal stuff like banking and news. Chrome incognito for you know what.

Purchasing secret presents, the use case incognito was designed for ;)

You joke, but if you make the mistake of looking at a possible present in a non-incognito window, Amazon ads will now obnoxiously feature said present in all websites that you visit...

Yeah, Safari kills all JavaScript threads - even on active tabs - after 90 seconds or so.

I haven't checked this recently, but in the past Chrome always turned on the dedicated GPU on my MBP, whereas Safari ran just fine with the integrated one.

It's great, right? :)

10 hours vs 3 hours for current browser versions, running equivalent tabs/extensions/settings? Sorry but I don't believe you.

Can you point to battery benchmarks or is this an off the cuff personal test?

Are you talking about an old version of Chrome? You're aware they've been making progress recently?

https://9to5mac.com/2016/09/06/google-chrome-mac-battery-per...

>>10 hours vs 3 hours for current browser versions, running equivalent tabs/extensions/settings? Sorry but I don't believe you.

My experience is the same. I have a 2011 MBA. With Safari, the battery lasts 4 hours. With Chrome, about 90 minutes. My browsing habits are the same between browsers.

Are you aware of the recent improvements in Chrome 53 energy use? Are your numbers before or after this?

What was your test methodology, or was this ad-hoc?

If there were reliable sources reporting similar numbers it would be easier to swallow, but I can't find a single source that claims it's this bad.

Yes this was within the last couple weeks, using Chrome 55 and Safari 10. The difference is enormous and unmistakeable, if you have an MBP then just try it yourself.

Spotted the Chrome dev.

I don't work for or advocate for Google.

I'm just skeptical about such a massive difference that I've never seen written about, and where only commenters report it, with no methodology, process, or repro steps.

I have a 2012 MacBook Pro with Chrome and anecdotally I don't notice a 3x battery difference with Safari, but I wouldn't make a strong claim about it without some rigor as I mention above.

'Tis the internet! In this case, your experience is everyone else's when it's good, no one's when it's bad.

You better get to believing, because it is right within the realm of reality. Chrome is _terrible_.

Believing what? I know it's terrible I'm just skeptical its that degree of terrible.

Already other people here are posting different ratios. Its just a loose claim.

On my preview MBP it was about half. 6 hours on Safari meant I got 3 hours on Chrome.

Is there any way to hook up bookmark syncing cross browser? Better battery life would be nice, but I like having Chrome's sync between Mac, Windows, Linux, and iOS.

I believe that iCloud Tabs works to sync Safari bookmarks with Chrome. Not sure it's bulletproof though in my experience...

I use Pinboard for my bookmarks. There's an add-on/extension for every conceivable browser or platform.

Many reasons. Among those I care about:

* It's a lot more power-efficient than any other browser.

* In my experience, it's often faster than Chrome.

* It follows platform conventions. I still get weirded out by Chrome cramming everything into that ⋮ button.

* It syncs history, favorites, and open tabs over iCloud to Safari on my phone. It also supports Handoff.

* It's not made by Google, a company that I prefer to give as little personal information as possible to.

And more generally, it's just more enjoyable to use.

Good list, let me add bad color display.

Chrome shows wrong, washed out or desaturated colors everywhere (not just embedded images without color profiles or wrong gamma, but css hex colors), it's a big difference from Safari, Firefox and specially from browsers on Windows machines and phones.

An FYI regarding "In my experience, it's often faster than Chrome"...

I found during development that Safari will start retrieving suggested URLs even before you finish typing them, so if I'm going to 'news.ycombinator.com', it makes the request when I hit 'n', and by the time I hit a few more characters and enter a few hundred milliseconds later, the request is already complete.

Chrome has been doing that for a long time and more.

If you hunt around you'll find that chrome is even doing things like speculative DNS queries, opening TCP channels to endpoints that are often opened on pages that you might be trying to load, in some very limited cases even pre-downloading and executing a page "hidden" only to swap it in like you changed tabs once you "hit enter". [0][1]

If you tend to be pretty "habitual" when using chrome, fire up something like wireshark before opening it and watch what it does when you first start it. A year or 2 ago I did this and noticed it would instantly fire off DNS queries for gmail and start a TCP channel before i've even typed anything! (as at the time the first thing i'd do when opening chrome was check my email).

It's really cool shit, and I'm sure chrome and safari aren't the only ones doing it. I mean the gains can be substantial (especially for mobile devices! getting the DNS query and TCP handshake out of the way on a shitty 3g network before the user stops typing means it will load a few hundred ms sooner) and for many of the smaller changes there are very few downsides.

[0] This goes over the bit ones that many browsers have: https://css-tricks.com/prefetching-preloading-prebrowsing/

[1] Here is a somewhat-technical article about chrome from 2012 that goes over the DNS and TCP-preconnect stuff: https://www.igvita.com/2012/06/04/chrome-networking-dns-pref...

I don't know why, but when using a local development server only Safari manages to generate requests while typing the URL for me—Chrome does not. It's possible I've put more work into my Chrome privacy settings.

Chrome disables just about all of this when you have the developer tools open, so that might be what you are running into.

Thanks for the info, I'll keep an eye out for this sometime in the future!

Also, there's a preference under "Search" that toggles this.

Because of this, I've managed to hang Safari once before just by typing a URL, not actually visiting it.

It's nonetheless a neat feature.

I actually think Chrome was doing this long before Safari was

And on the typography front:

* Properly hyphenates

I've been (mildly) irritated for years that Chrome's devs have taken so long to put in CSS hyphenation support; this has been supported in other browsers since ~2012. It looks like it's finally got partial support since Chrome 55, although caniuse.com says it's still Mac-only.

https://bugs.chromium.org/p/chromium/issues/detail?id=605840

FYI chrome on macOS supports handoff too

Huh, I didn't realize that. Of course, I rarely use Chrome (usually only when I need Flash, which is thankfully almost never). I assume when going iOS -> macOS it hands the URL to your default web browser?

Unfortunately not, I believe because when handing off web links, you have to demonstrate to Apple that you own a domain to be allowed to link to it.

What that practically means is if I'm on ycombinator.com, iOS won't let Chrome, a 3rd-party app, claim to be representative of any page on that domain without proof hosted on the domain.

https://developer.apple.com/library/content/documentation/Us...

No, it only works between Chrome on Desktop and Chrome on iOS, and in my experience it's nowhere near as seamless as the one baked into Safari.

Apparently it actually works going from Desktop Chrome -> iOS Safari. I don't have Chrome installed on my iPhone, but if I have Chrome active on my desktop, Handoff will open the page in Safari.

It works both ways.

I find it faster and more power efficient. It also fits with the rest of macOS much better than Chrome. Many long time Mac users are fussy about app consistency.

For example, initially Chrome and Firefox didn't even support text services in their rendering areas — stuff like the system-wide dictionary lookup. That the developers of these browsers ignored what made macOS unique really put me off. (As did hitting the dictionary shortcut on my keyboard when reading and not getting a result.)

One feature I use a lot in Safari is the reader view. Pressing a button turns a page into a consistently rendered and better-typeset version which focuses on the content only. It even collates multi-page content into a single page. I'm sure there are extensions on Chrome which do this (perhaps it even does it natively now?). But Apple's treatment of this feature makes me feel that they prioritise the same things about the web that I do: text and links. Everything else is just noise because I spend 95% of my time on the web reading.

Chrome still does not feel like a first class citizen of macOS. I'm not sure it even saved website passwords in your Keychain, though maybe this has changed.

Edit: oh I also like Safari's gesture based controls better when browsing with a trackpad. For example when you swipe to go back to the previous page, the entire page slides over and you can peek at the previous page underneath the "stack." You don't even need to trigger the actual back action to read content from the previous page if you naturally let your fingers rest mid-gesture. Last time I tried Chrome the "go back" gesture displayed a large, ugly arrow overlay on the left edge of the page. It did not correlate 1:1 with the position of my fingers. It did not show me the previous page's content until I completed the gesture, then it reloaded the previous page. I really did not like this.

>One feature I use a lot in Safari is the reader view.

This is one of the primary reasons why I used Safari when on Mac. Reader view is instantaneous and works really well on almost every site. You can also customize fonts/colors etc which means you can always read article in distraction-free mode and read them that best suits your eyes.

I am now using Linux most of the time (MBP got stolen, didn't buy a new one yet) and I miss Reader view the most. It's a HUGE timesaver.

All of your points still remain true to this day, however Firefox does indeed have a reader view which works pretty nicely.

No Keychain integration is an issue for me as well.

I used Chrome before but gave Safari another go about a year and a half ago, haven't looked back since and now Safari is my main browser on macOS. I only open Chrome when I need to test something, or come across a site that puts up a screen saying nothing but Chrome is supported (regardless of whether or not it works.)

My main reason for switching is efficiency. Safari is blazing fast, and reasonably memory efficient as far as browsers go even with 100+ tabs. Chrome would deplete my memory even with only a moderate amount of tabs open.

Also Safari seems much more power efficient.

I don't like the chrome of Chrome.

Safari looks like it belongs here. Chrome does not. Also:

• The resources thing. I often use Safari windows with 100+ open tabs.

• I like Safari's tabs implementation better: new tabs go to the far right. In the past all browsers with tabs did that, now Safari seems to be the last holdout while the others seem to put new tabs to the right of the opening tab. I can understand the logic there but I find it unusable without a tree-like visualization like some Firefox extensions. If there is a browser which had this natively I'd be tempted. I still miss OmniWeb.

Safari's ⌘W-behavior for the new tab now jumps back to the tab which opened the newly closed tab. I really hope that isn't a hint of bad days to come.

Why this heavy focus on tabs? I basically use my default browser window as a LIFO stack of tabs to read. It works great for me, thirteen years and counting. I don't want that to change.

• When Safari went through its bad time, the WebKit2 area, I was tempted. Another detail which held me at the time: Safaris Pinch to Zoom on the trackpad was superior to everything else elsewhere. It still is but Firefox and Chrome at least but a little bit work into it.

While they don’t really list it as an official product anymore, to this day they produce test builds of OmniWeb 6.0:

http://omnistaging.omnigroup.com/omniweb/

Battery life. Chrome absolutely obliterates my MBP's battery.

edit: this is the same reason I have for hating Electron apps so much.

One of my friend who is travelling moved from Chrome to Opera (!) for the battery life reason.

Opera uses Blink now, so I wouldn't expect it to be much better than Chrome.

Opera's done a lot of work on power consumption and not all of it has as of yet been upstreamed, AFAIK.

Opera would surely have less built-in botnet than Chrome, maybe that accounts for the lower power consumption ;)

Were you being sarcastic? I can't tell.

Why not? It's incredibly efficient, fast, follows the standard OS X design guidelines, doesn't spy on me constantly. It's what Chrome was BUILT FROM (later they forked).

The only thing Chrome seems to offer is a big plugin ecosystem (which I've never cared about, the one or two I care about exist for Safari) and the fact it's the same browser on other OSes which doesn't matter to me.

It's often the little things. I like being able to use AirDrop and Handoff with my phone/iPad. I like having a native print dialog (who the hell thought THAT was a good idea?). I like my laptop not trying to melt it's self when I open a few pages.

If you were stuck on Windows when FF was nearly dead and Chrome and IE were your only choices I get why people chose it.

If you were on a Mac at the time I've never seen the appeal.

Battery, reliability, memory usage, are all part of the reason I use Safari.

I've found Chrome to be fairly unstable. We had a case last year with our corporate website relaunch, where a single user reported that our site was crashing Chrome for them and we probably had 60 or 70 people try to unsuccessfully recreate the bug, we tried Browserstack and Sauce to try and had no luck.

Another time we had a few users report incorrect fonts and traced that to a bad build of Chrome that was out for a week or so and the users that updated that week had broken fonts until they updated again.

Then there was the time one of our analytics suites broke when tracking certain links on our site since the request body to their service contained 'cgi-bin' in it, they blackholed the tracking request, and their (rather poor quality) script blocked the page until the request returned - no timeout set at all. This would completely lock Chrome for 10+ minutes when Safari would force a timeout after 20 seconds or so.

All those stories make it clear to me that the most stable option is Safari.

p.s. Not to mention the number of sites I run into now that only work in Chrome because the developers can't be bothered to do cross browser testing. Chrome is like the new Internet Explorer at this point.

Safari on macOS is the only browser on this planet that implements color management correctly.

Safari gives me at least three hours of autonomy on my laptop. Chrome burns CPU like crazy. Not to mention that on Youtube (a Google site) 1080p video uses 1% CPU in Safari while 720p video in Chrome (a Google browser) manages to use 80% CPU.

Safari is the only browser that can do ad blocking without javascript extensions.

Why not Safari?

> Safari on macOS is the only browser on this planet that implements color management correctly.

This is one of those things that I almost never noticed until I was working with a site that was using one specific color of orange that was dramatically different from what I had in photoshop. It usually isn't something that concerns me too much, but I was adding the ability for content editors to select primary colors of pages (think a super advanced, easy to use CMS), and with the images selected it was painfully obvious. Took me hours of tweaking settings in photoshop and comparing it to various browsers to finally give up and accept that color management in browsers is broken.

>Not to mention that on Youtube (a Google site) 1080p video uses 1% CPU in Safari while 720p video in Chrome (a Google browser) manages to use 80% CPU.

This is because Google/YouTube is pushing VP9 streams when they detect that you're using Chrome. It saves them few megs on bandwidth (over H.264) but you suffer for it because VP9 is not hardware accelerated so it chews through your CPU and makes your system less responsive. YouTube/Google also doesn't allow you to set your preference for H.264.

It's irresponsible for Google to waste so much electricity for everyone who uses Chrome.

> This is because Google/YouTube is pushing VP9 streams when they detect that you're using Chrome. It saves them few megs on bandwidth (over H.264) but you suffer for it because VP9 is not hardware accelerated

VP9 can be hardware accelerated, and AFAIK current Chrome supports hardware acceleration for VP9 with hardware that supports it.

Can and is are two very different things. My brand new Nvidia GPU doesn't support it. Neither does iGPU. I'd wager that 99% of devices in use don't support HW decoding of VP9.

Which means that Google is wasting tons of electricity by pushing their own codec. That's not good for the environment and for global warming. Extremely irresponsible.

Are there any normal desktops/laptops that support it?

I'd be amazed if anything other than Chromebooks and Android had it.

> Are there any normal desktops/laptops that support it?

From what I've been able to find:

NVidia Pascal has full hardware decoding for VP9, as does the NVidia GM206.

And Intel's (now shipping, but not in consumer hands yet until probably next month, IIRC) Kaby Lake has full hardware decoding support, too.

(A lot more existing GPUs have hybrid support, but that's still got a CPU cost.)

Interesting. Given basically everyone but Google is happy with H.264 I'm surprised they would bother.

> Given basically everyone but Google is happy with H.264 I'm surprised they would bother.

Well, YouTube alone is something like 1/6 of internet traffic, and probably a sizable amount of the time people spend on the internet.

And everyone besides Google isn't happy with H.264, either. While it's true that Google is the main source of VP9, Netflix 4K is, IIRC, H.265-only (for which hardware acceleration is becoming more common just as it is for VP9).

I tend to try and use Safari when I'm at home just surfing the web or checking email because of battery life. If I'm not plugged in I will use Safari over Chrome. When I'm actually working I tend to use Chrome just because I enjoy the experience and have all the plugins I enjoy using there. Generally I am also plugged into a wall outlet when actively working in a browser (I'm primarily a frontend developer).

I just got the new tMBP 13" and have been making it a habit to use Safari over Chrome on it. It's a pretty noticeable different so far. I'm going to try and record some usage information over the next few weeks and see how much of a difference it really makes. In general though it appears that with Safari and general browsing I can get the advertised 10 hours or so. If I start using chrome (even just browsing) it turns to 7 or so hours.

> If I start using chrome (even just browsing) it turns to 7 or so hours.

And if you start youtube (even 480p), it drops to 3 hours with Chrome, while still getting the 10 hours with Safari.

(Not sure how to format this)

  - Battery life
  - Bookmark syncing and continuity (opening tabs from any of your other devices)
  - Content blocker API (so that ad blocker extension doesn't see all of the content)
  - Not having browsing history sent to Google

I use Chrome for Flash content and Facebook.

> - Bookmark syncing and continuity (opening tabs from any of your other devices)

Is it not the same with Chrome?

I have not heard of Chrome sending browser history without my consent. Source?

Chrome is ugly. Chrome forces tabs on you (the real estate is wasted whether or not you believe in tabs; I don't, I think it's the sign of a failed window manager). Chrome is slow.

I use Chrome every day because all of my work stuff on my work laptop goes in Chrome, and all of my personal stuff goes in Safari, because that's what I like the best and use at home. Separate browsers mean separate session tokens for work vs personal gmail.

Nicer looking, faster (feeling, at least), iCloud Keychain.

For me, it feels a lot faster, and drains power a lot slower.

I agree that the dev tools are poor. But I've gotten into the habit of running a "dev" browser and a "user" browser, so Safari works out great - I do dev work in Chrome, and when it (infrequently) crashes, I don't lose my personal stuff.

Because historically on OSX, Safari offered roughly an extra hour and a half of battery life over Chrome.

It seems to be a little better for battery life than Chrome. On my aging MacBook Air, every little bit helps.

I was a Web Dev for about a decade and I swore by Firefox (started using at 0.6) and then later I switched to Chrome. Recently I've been solely focused on mobile application development and I don't really need most of the development tools that Chrome offers (even though Safari has most of them). At the end of the day, I just need a fast browser without bloat to go here, stack overflow, google, web-based documentation sites, github, product hunt, designer news, youtube and a few other sites.

Chrome is extremely bloated and resource intense on macOS. Each subsequent tab you open linearly increase your CPU and memory Usage. I need CPU cycles to build code, not load gifs from a website that I have in the background. Safari has way better memory and CPU management than any other browser on macOS. The only thing I use Chrome for are websites that require Flash since it's built in.

I just had my friend who uses Chrome take a screenshot of his Activity monitor - He has one "Google Chrome Helper" that's using more resources than my entire Safari browsing experience - http://imgur.com/pMHkKsz

Safari has always been faster and less resource-hungry than the competition on OS X/macOS. (The competition here meaning mostly Chrome and Firefox; before Opera migrated to use Chrome's renderer/engine, it was also similarly lightweight.) To me, Safari also feels more like a native app.

I still use Chrome for development, because Safari's development tools are next to completely useless. I don't even know why they bother.

For me Safari works good enough, so I don't have many reasons to switch. Chrome development tools are marginally better, so it's still installed and I use it for some heavy JavaScript development, but outside of this I prefer Safari.

Funny enough, I had to use Windows 10 for a short time, and Edge was actually not that bad. I remember IE being the terrible product and everyone used some other browser. Now Edge is usable and there's no much reason to install Chrome there as well.

Chrome on iOS is really Safari when it comes to rendering engine, which is what the current news is about...

if you're an iPhone user, you get one choice Mobile Safari... or a webkitWebView that is Safari. Yes, you can install other browsers, but they are only allowed to use Safari's rendering engine.

It's efficient.

It's fast.

I don't use plugins (for ads I use GasMask).

Bookmarks and tabs sync with my iPhone.

i also use Safari on my Macbook;

Firefox sucks because it still doesn't support the smooth "pinch to zoom", which Safari and Chromium have had for years. To me zooming seems such a basic functionality which is used so often, it feels like driving a car without rear mirrors or something...

Chromium/Chrome = Google, which i avoid due to lack of privacy.

One of the things i dislike in Safari is the lack of many extensions/addons which Chromium/Firefox do have. I wonder why this functionality is missing ?

Chrome looks really ugly, like it was designed by a programmer.

Hot keys for Bookmarks in Favorites Bars (Command+Option+N).

The dev tools are indeed better on chrome. Which is why I mainly develop in Chrome. But just for casual reading? Safari is much better.

battery life/CPU usage.

>I used Chrome on Windows and iOS

Chrome on IOS is really Safari under the covers.

Trackpad gestures, mostly. It's better on battery life too. But for development I use Chrome, I agree its dev tools are better than Safari's. (And Firefox's, which are really unfortunate.)

EDIT: Forgot the reading mode. That one is really important.

Im guessing for a large number, its the same reason people still use Microsoft's browser. It's the default and it's good enough.

You're guessing wrong. I am using Safari because I like Safari the most.

I didn't say every Safari user, how does your comment prove my comment wrong?

If only it supported WebRTC like even Edge does. I'm running a WebRTC startup and its killing me that Safari and Mobile Safari don't support it at all.

Well, at least it's in development: https://webkit.org/status/

Can I use lists Safari as not supporting WebRTC. I thought that was part of the spec.

http://caniuse.com/#search=webrtc

WebRTC is a browser spec, it's not part of ECMAScript the language. That's what this submission is referring to.

Not the ES spec; one is JavaScript the language, the other (WebRTC) is part of the browser ecosystem.

This is great, but I wish Apple pushed out updates to Safari (particularly on iOS) more frequently - as it is, we might not see this on phones until September 2017. Not to mention WebRTC, Service Workers... you can't polyfill them like you can ES2015.

Safari Web Technology preview not the one that is in macOS Sierra currently.

Though that still is a good thing.

Now add WebRTC and it will be fine :)

There are numerous comments like this and they ALWAYS come up on Safari posts.

Why exactly do so many people care?

People want to use Hangouts and Skype in their browsers, WebTorrent (https://webtorrent.io/), and file sending services like https://dropub.com/, to name just a few

Hangouts/Skype don't surprise me much. Didn't realize you could use it for torrents.

Personally I'm heavy in the native app camp instead of trying to turn everything into webpages, so I guess that explains why I don't really know what this feature is and haven't been waiting for it.

Thanks

Post like these bother me because they lack context. Sure, the claim in the title is true, (and will remain true, unless something goes terribly wrong at Apple) but by the very nature of the linked resource, at some point it won't tell you whether or not the claim is valid.

>but by the very nature of the linked resource, at some point it won't tell you whether or not the claim is valid.

What are you talking about? The linked resource is a JS feature matrix that shows how each browser does against those 2015/16/17 features, and it shows exactly what Safari tip passes.

When other browsers/engines reach compliance, it will be impossible to tell that Safari was "first".

So? The post is meant for immediate consumption.

I mean the title is the whole context. If you're worried about the table not being static, one can ideally refer to an archive [0] (just saved it) or since this is an open source project that is version controlled, the specific revision [1] displayed.

[0]: https://web.archive.org/web/20161208203812/http://kangax.git...

[1]: https://github.com/kangax/compat-table/blob/559825d41e7b8773...

I wouldn't say that I'm "worried", but the title states a fact that will likely, at some point, not be supported by the given link.

That's why you watch the date (despite several clickbait farms working hard to hide or fake them)

Does it support JS Modules? (I don't think the kangax compatibility table has a test for that, but the last time I looked, no browser supported it yet.)

The compat table does not include the modules (See the rationale here[1]). But STP19 supports the modules.

[1]: https://github.com/kangax/compat-table/issues/316#issuecomme...

It is supporting ES2015/16/17 completely but its ES5 support is 99%. All other major browsers have 100% support ES5 for years. http://kangax.github.io/compat-table/es5/#test-Miscellaneous

Unless I'm mistaken, the same resource shows Chrome 55/56/57 is also at 99%?

I'd be curious if a JavaScript guru could give a little more context about the significance of that last 1%: namely, for Safari, "enumerable properties can be shadowed by non-enumerables," and for Chrome, "Array.prototype.sort: compareFn must be function or undefined."

Awesome!

Reply on news.ycombinator.com