- No WebRTC (http://iswebrtcreadyyet.com)
- No Service Worker (https://jakearchibald.github.io/isserviceworkerready)
- No WebM/VP8 support
- No ASM.js
- No MediaRecorder
Combined with the following policy decisions from Apple:
- Almost complete lack of engagement with the community
- Default browser on iOS
- No alternative rendering engines supported on iOS. (This is even worse than IE, as users could always install third-party browsers on Windows)
- Safari updates tied to OS updates, which mean users of old iPhones are stuck on old Safari versions because they don't get OS updates anymore
Both WebRTC (https://webkit.org/status/#specification-webrtc) and ASM.js (https://webkit.org/status/#feature-asm.js) are under development.
Service Workers are under consideration: https://webkit.org/status/#specification-service-workers
Regarding community involvement, the WebKit team seems more responsive and accessible than in the past. When one of the developers said he was available to fix CSS bugs (https://twitter.com/grorgwork/status/738486146313773057), I tweeted at him a bug that had been annoying me.
A few days later, it was fixed: https://twitter.com/grorgwork/status/740356645981585408
Things are different now and going in the right direction.
However, no iOS users will see this change until iOS 10 is released. (Hopefully this makes it into 10, instead of waiting for iOS 11).
And just like we see every year, the latest release of iOS will be released in September, so it's just a couple of months away.
- Slot-Based Shadow DOM API (https://webkit.org/blog/4096/introducing-shadow-dom-api/)
- Wide-gamut color support (https://webkit.org/blog/6682/improving-color-on-the-web/)
- 100% ES6 support (https://twitter.com/webkit/status/728643624464883712)
- new JIT compiler (https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...)
- 88% CSS support (CSS1 through CSS4, via http://css4-selectors.com/browser-selector-test/)
It appears that Safari supposedly being the new IE has been greatly exaggerated.
Apple releases a major version about every year, so it's a bit less cutting-edge, but it's very standards compliant contrary to IE in the past.
I know it's not a popular opinion, but I believe that for regular browsing (on the Mac) Safari is the superior choice...
I think it's important to make the distinction between Safari and iOS Safari. It's iOS Safari that is the most comparable to the issues with IE in the past, particularly IE6:
- Updating it is tied to iOS releases, which in turn is tied to hardware model. Thus real world usage of iOS Safari drastically lags behind "Safari latest" as users stick to hardware that works and for various reasons cannot/ upgrade iOS.
- Safari on the iOS is as much as possible intended to be a monoculture on iOS devices.
- iOS still has enough marketshare and share of total browser users and to a lot of people the "smartphone" is still nearly synonymous with "iphone" and "tablet" with "ipad". (That's a lessening concern these days with Android doing well enough, but it was definitely a big problem in early "mobile website design".) So web developers need to develop with it in mind, sometimes from an "iOS first" mentality when their businesses have invested much into iOS hardware. (Some businesses do have an iOS mobile device monoculture and probably will for several years to come.)
That last issue is the one where the comparison to IE has been the scariest in the past and the one where Safari will likely leave its mark on the web "geological strata" in a similar way to classic versions of IE: there will be some things like notable -webkit prefixed CSS rules that will last a long, long time on the web and the other browsers have simply had to adopt checking for the -webkit version. (Edge and Firefox both have lists of -webkit CSS rules they follow.)
The reason to make the comparison is to especially remind web developers to test outside their personal monoculture bubble. To remember that there are mobile devices that aren't iOS out there and there are many users out there not using Safari (or Chrome or whatever the flavor of the month is among developers) as their daily drivers.
"Safari is the new IE" is hyperbole, but it's useful hyperbole.
Web APIs and DOM APIs missing in Safari cannot. You can't polyfill WebRTC (without a plugin and there is no plugin support on IOS obviously).
I would prefer no support for ES6 so they concentrate on implementing APIs such as WebRTC,ServiceWorkers ...
Safari is a little behind Chrome/Firefox/Edge but it is only roughly a couple of releases behind, IE6 on the other hand felt like it was a dozen releases behind and they had a much larger market share relative to Safari.
A better analogy might be "Safari is like IE 11." Meaning out of date, but not by a huge amount. Plus their latest dev' builds seem to have picked up the pace a little, so this might just be a blip.
Pulling from a comment I posted over on Reddit recently:
--
Looking back through my painful history of Safari headaches I've personally encountered in building a single-page app, at least it appears that there's some progress:
* It looks like the pervasive, opaque, and seemingly-random "attempted to assign to readonly property" crap that affected only Safari and broke Angular, Ember, React, and others has been fixed, at least in upstream Webkit (https://bugs.webkit.org/show_bug.cgi?id=138038#c21). I guess we can take out our Safari-only monkey-patch fix now, so that's nice. Would be nice if I could get that entire work week of debugging and workarounds back, but c'est la vie. Assuming, of course, that Safari has finally pulled this fix in from upstream, which is far from guaranteed.
* Date parsing (http://stackoverflow.com/questions/4310953/invalid-date-in-s...) now behaves up to the standard, just like all other browsers; I suppose we no longer need to use Moment.js as "Safari's handicap access ramp" anymore either.
* The broken multi-select bug (http://stackoverflow.com/questions/20039194/multiple-select-...) still seems sporadically there.
* It's unclear whether they've fixed adjacent-element selectors in querySelector (https://github.com/jquery/sizzle/issues/290). It's been fixed in Webkit, so maybe in a year or so Safari will have it fixed too.
This is just stuff I've seen in my normal day-to-day of a not-super-complex Angular single-page app. You can see, I'd hope, why I have plenty of room based on Safari's track record to assume their implementation of anything is subtly-but-painfully broken.
Normally, I'd go check the status of these things on a bugtracker, but unlike the Chromium team, the Firefox team, or the Edge team, I guess the Safari team is just too perfect to need a publicly-accessible bugtracker. Or too embarrassed to have one? Yeah, it's one of those.
Having a green (or more often, yellow-green) checkbox on caniuse or kangax doesn't mean the feature is usable, it just means it's technically available.
Safari (iOS): 65%
Edge: 72%
Safari (macOS): 76%
Chrome (Android): 79%
Firefox: 84%
Chrome (desktop): 87%
Those numbers become much worse when you factor in how long it takes to get rid of old versions of Safari.[0] (scroll to bottom): http://caniuse.com/#cats=HTML5&compare=ios_saf+9.3
According to StatCounter, UC browser is the second most
used smartphone/"mobile" web browser worldwide, passing
Safari in October 2015.
Source: https://en.wikipedia.org/wiki/UC_Browser