
Safari Technology Preview supports 100% of the ES2015/16/17 features - nacs
http://kangax.github.io/compat-table/es2016plus/#safaritp
======
franciscop
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](http://caniuse.com/#feat=fetch)

~~~
sotojuan
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.

~~~
TheAceOfHearts
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.

~~~
untog
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.

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

~~~
eridius
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.

~~~
JasonSage
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.

~~~
Klathmon
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/](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...](https://www.igvita.com/2012/06/04/chrome-networking-
dns-prefetch-and-tcp-preconnect/)

~~~
JasonSage
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.

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

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

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

~~~
timdeneau
Well, at least it's in development:
[https://webkit.org/status/](https://webkit.org/status/)

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

[http://caniuse.com/#search=webrtc](http://caniuse.com/#search=webrtc)

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

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

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

~~~
brian_herman
Though that still is a good thing.

------
anovikov
Now add WebRTC and it will be fine :)

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

Why exactly do so many people care?

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

~~~
MBCook
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

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

~~~
cooper12
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...](https://web.archive.org/web/20161208203812/http://kangax.github.io/compat-
table/es2016plus/)

[1]: [https://github.com/kangax/compat-
table/blob/559825d41e7b8773...](https://github.com/kangax/compat-
table/blob/559825d41e7b8773d8c466d3c5bb00535b7b23b6/es2016plus/index.html)

~~~
johnhenry
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.

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

------
nfriedly
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.)

~~~
yusukesuzuki
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...](https://github.com/kangax/compat-
table/issues/316#issuecomment-252433401)

------
malekpour
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](http://kangax.github.io/compat-table/es5/#test-Miscellaneous)

~~~
wux
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."

------
nunez
Awesome!

