Last weekend I attended EdgeConf, a conference populated by many of the leading lights in the web industry. It featured panel talks and breakout sessions with a focus on technologies that are just now starting to emerge in browsers, so there was a lot of lively discussion around Service Worker, Web Components, Shadow DOM, Web Manifests, and more.
EdgeConf’s hundred-odd attendees were truly the heavy hitters of the web community. The average Twitter follower count in any given room was probably in the thousands, and all the major browser vendors were represented – Google, Mozilla, Microsoft, Opera. So we had lots of fun peppering them with questions about when they might release such-and-such API.
There was one company not in attendance, though, and they served as the proverbial elephant in the room that no one wanted to discuss. I heard them referred to cagily as “a company in California” or “a certain fruit company.” Their glowing logo illuminated nearly every laptop in the room, and yet it seemed like nobody dared speak their name. Of course I’m talking about Apple.
I think there is a general feeling among web developers that Safari is lagging behind the other browsers, but when you go to a conference like EdgeConf, it really strikes you just how wide the gap is. All of the APIs I mentioned above are not implemented in Safari, and Apple has shown no public interest in them. When you start browsing caniuse.com, the list goes on and on.
Even when Apple does implement newer APIs, they often do it halfheartedly. To take an example close to my heart, IndexedDB was proposed more than 5 years ago and has been available in IE, Firefox, and Chrome since 2012. Apple, on the other hand, didn’t release IndexedDB until mid-2014, and when they did, they unveiled a bafflingly incompetent implementation that was so bad, it’s been universally derided as unusable. (LocalForage, PouchDB, and YDN-DB, the major IndexedDB wrappers, all ignore Safari’s version and fall back to WebSQL.)
Now, after one year, Apple has fixed a whopping two bugs in IndexedDB (out of several), and they’ve publicly stated that they don’t find much value in working on it, because they don’t see “a huge use.” Well duh, nobody’s going to use IndexedDB if the browser support is completely broken. (Microsoft, I’m looking at you too.)
It’s hard to get insight into why Apple is behaving this way. They never send anyone to web conferences, their Surfin’ Safari blog is a shadow of its former self, and nobody knows what the next version of Safari will contain until that year’s WWDC. In a sense, Apple is like Santa Claus, descending yearly to give us some much-anticipated presents, with no forewarning about which of our wishes he’ll grant this year. And frankly, the presents have been getting smaller and smaller lately.
In recent years, Apple’s strategy towards the web can most charitably be described as “benevolent neglect.” Although performance has been improving significantly with JSCore and the new WKWebView, the emerging features of the web platform – offline storage, push notifications, and “installable” webapps – have been notably absent on Safari. It’s tempting to interpret this as a deliberate effort by Apple to sabotage any threats to their App Store business model, but a conspiracy seems unlikely, since that part of the business mostly breaks even. Another possibility is that they’re just responding to the demands of iOS developers, which largely amount to 1) more native APIs and 2) Swift, Swift, Swift. But since Apple is pretty good at keeping a lid on their internal process, it’s anyone’s guess.
The tragedy here is that Apple hasn’t always been a web skeptic. As recently as 2010, back when Steve Jobs famously skewered Flash while declaring that HTML5 is the future, Apple was a fierce web partisan. Lots of the early features that helped webapps catch up to native apps – ApplicationCache, WebSQL, touch events, touch icons – were enthusiastically implemented by WebKit developers, and many even originated at Apple.
Around that same time, when WebSQL was deprecated in favor of IndexedDB, you’ll even find mailing list arguments where Apple employees vigorously defended WebSQL as a must for performant web applications. Reading the debates, I sense a lot of bitterness from Apple after IndexedDB won out. The irony here is that Apple nearly gave us the tools to undermine their own proprietary platform, but by rejecting WebSQL, we gave them an opportunity to rethink their strategy and put the brakes on any new progress in web APIs.
I find Application Cache, which will probably soon be deprecated in favor of Service Worker, to be a similar story. It gained wide browser support at a time when Apple was still interested in the web, but unfortunately it turned out to be a rushed, half-baked solution to the problem. I worry that Service Worker might suffer the same fate as IndexedDB, if Apple continues to lag behind the pack.
At this point, we in the web community need to come to terms with the fact that Safari has become the new IE. Microsoft is repentant these days, Google is pushing the web as far as it can go, and Mozilla is still being Mozilla. Apple is really the one singer in that barbershop quartet hitting all the sour notes, and it’s time we start talking about it openly instead of tiptoeing around it like we’re going to hurt somebody’s feelings. Apple is the most valuable company in the world; they can afford to take a few punches.
So what can we do, when one of the major browser vendors is stuck in the 2010 model, and furthermore has a total monopoly on iOS (because no, “Chrome for iOS” is not really Chrome), showing a brazenness even beyond that of 90’s-era Microsoft? I see three major coping mechanisms:
- Stick with what worked in 2010, and use polyfills to support Safari. This is a strategy I highlighted in my opening talk for the frontend data panel, where I showed that you can get nearly the same features as Service Worker by using AppCache and PouchDB (which falls back to WebSQL on Safari). This approach should appeal to the vast majority of web developers, who tend to hit the snooze button on new technologies until they’re available cross-browser. On the other hand, it’s also a good way to coddle Apple and give them no incentive to step up their game.
-
Use technologies like Service Worker that don’t work on Safari, and consider it a progressive enhancement. Alex Russell made a great point about this during the “installable webapps” breakout, arguing that if we create a large body of free webapps that use Service Worker, and which work fabulously well on Android but only meh on iOS, then it will be in Apple’s interest to suck it up and support the API. Unfortunately, while this would be the best outcome for the web community as a whole, it’s going to be hard to convince developers to write code that only reaches half their audience.
-
Contribute to WebKit. The core of Safari is still, after all, an open-source project, so there’s no practical reason why anyone with the C++ chops couldn’t roll up their sleeves and implement the new APIs themselves. (The absurdity of giving free labor to the richest company on earth isn’t lost on me, but we’re talking desperate times here.) The major problem I see with this approach is that WebKit is not Safari, and Apple could still decide to not deploy WebKit features to their flagship browser. To circle back to IndexedDB again, it was fully implemented by Google well before the Blink fork, and for several years, Apple could have just flipped a bit in their build script to include Google’s implementation, but instead they decided to waffle for a few years and then replace it with their own broken version. There’s no guarantee they wouldn’t do the same thing for other outside contributions.
So in summary, I don’t know what the right solution is. I’ve engaged many of the WebKit developers on Twitter, and I’ve even done the hard work of writing reproducible test cases and trying out their beta software so I can give them early warning. (Yes, I fork over $200 a year to Apple, for the privilege of testing their own software for them.) And frankly I’ve grown bitter, because most of the bugs I’ve reported have languished, with little response other than a link to their internal Radar tracker.
I appreciate the work that many of the WebKit developers have been doing (Brady Eidson has been particularly patient and helpful), but at this point it seems to me that the best strategy toward Apple may be the stick rather than the carrot. So I’m inclined to take up Alex Russell’s solution outlined in #2 above, and to start promoting the adoption of new web technologies – Safari support be damned.
If we can start building a vibrant ecosystem of web applications where Apple is not invited, then maybe they’ll be forced to pull a Microsoft and make their own penitent walk to Canossa. Otherwise we’ll have to content ourselves with living in the web of 2010, with Safari replacing IE as the blue-tinged icon that fills web developers with dread.
You can comment on Hacker News, on Ars Technica, and on Twitter. Thanks to Jan Lehnardt, Dave Myers, Beckie Choi, and Julian Applebaum for providing feedback on a draft of this blog post.
Posted by 1 – Safari is the new IE | Offer Your on June 30, 2015 at 5:50 AM
[…] Source: http://nolanlawson.com/2015/06/30/safari-is-the-new-ie/ […]
Posted by Harvey Lubin on June 30, 2015 at 7:55 AM
Re WebKit having been made open source by Apple: “The absurdity of giving free labor to the richest company on earth isn’t lost on me”
Ironic that you, as an Android developer, don’t have the same prejudice against Google (the second richest company on earth) for making Android open source. ;-))
And if WebKit was never made open source by Apple, you and the many other developers would be complaining that Apple is too “closed” to make WebKit open source.
You view Apple as doing the wrong thing, no matter what it does. Since you are an Android developer, it is understandable that you would have this bigotry (many Android fans are prejudiced against Apple).
I think that most people would view Apple making WebKit (and other software) open source as a positive… Not a negative.
Posted by Dmytrii Shchadei (@MeTroFuN) on June 30, 2015 at 8:05 AM
Well…Webkit is a forked version of open sourced engine KHTML and KJS ;)
Posted by Nick on June 30, 2015 at 8:06 AM
WebKit wasn’t open sourced by Apple, WebKit is a fork of open source software called KHTML which is why WebKit is LGPL
Posted by Michael Rose on June 30, 2015 at 8:15 AM
You realize they had to open source it right? webkit us based on khtml
Posted by Harvey Lubin on June 30, 2015 at 8:25 AM
“Webkit is a forked version of open sourced engine KHTML and KJS”
Yes, but you missed my points, entirely. The points are:
1) Apple chose to go open source rather than doing something proprietary like Microsoft did with IE.
2) If Apple had instead decided doing something proprietary, instead of WebKit, Nolan (and others) would be complaining about THAT!
3) Nolan is being hypocritical by complaining that Apple went the open source route, but he is not just as bothered that Google went the open source route with Android (which he develops for).
Posted by Harvey Lubin on June 30, 2015 at 8:36 AM
“WebKit is a fork of open source software called KHTML”
“You realize they had to open source it right?”
YES! OF COURSE I DO!
I never said that Apple created WebKit from scratch. When I said “And if WebKit was never made open source by Apple” I should have been clearer. The intention was to point out that Apple CHOSE to go open source rather than proprietary.
You seem to have missed the points made, and chose to quibble about semantics instead.
Posted by mherchel on June 30, 2015 at 8:49 AM
@Harvey – So are you suggesting that Safari is not the new ID? Please tell. Are you a web developer?
Also, of course Apple forked KHTML. Building a rendering engine is hard. Forking a FOSS project gives them a huge head start. If they had created a rendering engine from scratch, it would most likely suck beyond belief. The only reason Apple chose to go OSS is because it saved them money.
Posted by Percival Derpington (@ascendantlogic) on June 30, 2015 at 9:04 AM
This is not an Android vs iOS holy war. This is a commentary on how one of the major browser vendors is not keeping up with web standards, just like Microsoft did in the 2000’s. Chrome (partially by virtue of Chromium) have been standard-bearers for keeping up with the cutting edge of web standards so your attempt to frame it as “Pro Google bigotry” fails because it’s an Apples (ha) to Oranges comparison.
Go try to stir up that hornets nest somewhere else.
Posted by Harvey Lubin on June 30, 2015 at 9:48 AM
“So are you suggesting that Safari is not the new ID?”
What is ID. I think you meant IE.
Saying Safari is the new IE is just plain ridiculous. The two have very little in common… other than they are both Web browsers.
IE was built on proprietary software.
Safari was built on open source software.
IE was buggy and slow.
Safari while not the fastest browser is certainly not the slowest, and it has nowhere near the bugs that IE had.
“The only reason Apple chose to go OSS is because it saved them money.”
So you are saying that ALL companies that go open source do it just to save money?
That sounds like a very narrow-minded view.
Posted by Josh Kelley on June 30, 2015 at 9:57 AM
In context, the argument isn’t that an Apple product being open source is inherently absurd. Nolan is arguing that fixing Safari’s shortcomings ought to be Apple’s responsibility, and trying to solve those shortcomings by using the fact that Safari’s core is open source to fix them yourself, for free, has an element of absurdity.
Posted by Matthew Fabb on June 30, 2015 at 10:32 AM
I think just about everyone sees WebKit being open source as a positive. I think what he is saying is that a large number of developers having to help out Apple because they are falling behind is a bit absurd considering their wealth.
Yes, Android is open source, but Android developers don’t feel like they have to write new features in Android in order to keep up with iOS, Google is doing that on their own.
Posted by Christopher Ramírez (@chrRamirez) on June 30, 2015 at 9:05 AM
@Harvey Well, Apple forked KHTML at a time when Apple was almost in bankruptcy. Starting from scratch was not a viable option at the time. Why you are bringing Android into the discussion is beyond me…
Posted by Harvey Lubin on June 30, 2015 at 9:34 AM
“Why you are bringing Android into the discussion is beyond me…”
I’ll explain: It’s because Nolan made the comment in his article that “The absurdity of giving free labor to the richest company on earth isn’t lost on me” (I included this in my comment that you are replying to) regarding Apple choosing to go open source.
My point was that Nolan was being hypocritical because as an Android developer he did NOT have an equal comment about the “absurdity” of Google (second largest company) ALSO going open source with Android.
This was not a slight against Android, just an observation of the hypocrisy.
Posted by Harvey Lubin on June 30, 2015 at 9:51 AM
“This is not an Android vs iOS holy war.”
I agree with you 100%.
Why you see things that way, is another matter.
Posted by JKoehn on June 30, 2015 at 12:34 PM
Harvey, you must be a partially retarded troll. YOU’re the idiot who brought Android into the discussion to make it an Apple vs Google one. Fuck off you instigator.
Posted by Joakim on June 30, 2015 at 1:04 PM
Because you brought up that holy war and attributed that motive to Nolan despite it having nothing to do with the topic of browser APIs. Nobody criticized Apple for open-sourcing WebKit, only you. What he did criticize Apple for is neglecting their open-source project, to the point where others have to do that work for the richest company in the world, and even then it may not be compiled in to Safari, whereas Android isn’t neglected in such a way, as Matthew Fabb said above, so it has literally nothing to do with this discussion.
Posted by tobielangel on June 30, 2015 at 6:15 AM
In the title: s/Safari/Mobile Safari
Posted by Andrew Rondeau on June 30, 2015 at 6:15 AM
I think you’re missing the point. The browser is a document viewer, not an application delivery platform. Back in 2005 we all thought that web-based applications were going to take the world by storm, but now that we have slick application stores on all major platforms, this isn’t the case.
If you need functionality like you describe, ship a native application via an app store. It’s a much better experience than web development.
Posted by chris portscheller on June 30, 2015 at 6:25 AM
People still use computers…
Posted by foljs on June 30, 2015 at 6:39 AM
Increasingly less.
Posted by Paul on June 30, 2015 at 8:25 AM
…as do companies. I don’t see many native apps being used in the corporate environment. If it doesn’t work in a browser, and if fact, if it’s not certified to work in a browser, then it’s a big problem for us.
Posted by Me on June 30, 2015 at 8:36 AM
For some reason I can’t reply to the “Increasingly less” comment, but this point that people keep trotting out is so irritating. Yes, fewer people use traditional desktop computers now than five years ago, and the decline corresponds to an increase in the use of mobile devices like tablets and smartphones. But this does not mean that this trend will continue forever. Equilibrium will be reached at some point (barring another revolution in technology hitherto unforeseen), and when it is there will still be a vast number of traditional PCs in use, not least in business. Deciding to stop fully supporting applications on desktop browsers now because, in this moment, desktop PC usage is falling as mobile device usage is increasing would be ludicrously myopic.
Posted by ronnykaram on June 30, 2015 at 2:17 PM
I fail to understand the approach where people decide that computers are used less than before. Well, smartphones and tablets are the new comers and yes their numbers increased significantly, but that doesn’t mean that people who use computers dropped them completely in favor of handhelds.
There are more people accessing the internet through their smartphones, true, but when you want to do actual work you’re not gonna struggle with your iPad or smartphone to fill a 2 pages Excel sheet.
But that is also not the debate here.
It’s Safari… not implementing Web APIs as fast as they should (or sometimes not at all) because they’re being lazy, or maybe have other plans in mind. And that’s breaking Web developers backs.
Posted by Carlin Scuderi (@carlinscuderi) on June 30, 2015 at 6:26 AM
I disagree. HTML5 in of itself was built with applications in mind, and I’ve seen numerous web applications that, when used, are not different from their native counterparts in terms of performance and features. There’s also technology on the horizon that is going to push this even further.
Posted by robotlovesyou on June 30, 2015 at 6:36 AM
This whole “The web is for documents, apps are for everything else” position is based upon a false dichotomy. There is a whole spectrum of functionality between a dumb web document with a couple of hyperlinks and images in it and a super slick iOS UI coded in swift or ObjC and a more homogeneous and performant web helps us, as developers, deliver it.
Posted by Dennis on June 30, 2015 at 8:44 AM
It is a nonsense line of logic that has everything only ever being useful for its original purpose, ignoring enormous changes that have happened since. The “for documents” line being a particularly dumb one.
Posted by mherchel on June 30, 2015 at 6:42 AM
wut?
Posted by Arielext on June 30, 2015 at 7:36 AM
ignorance is bliss
Posted by Me on June 30, 2015 at 8:20 AM
A native app doesn’t necessarily give a better experience (or it needn’t), and often a native app is just overkill. In any case, I don’t want to live in a world where I have to choose an operating system that has satisfactory versions of the greatest number of apps that I want to use available in its app store. I want to have applications that run on any platform I choose, be it Windows, iOS, Mac OSX, Chrome OS, etc., and this achieved by web applications running in browsers available on all of those platforms.
Moving away from web standards and web apps towards native apps in walled gardens is so glaringly obviously a retrograde step. It’s annoying enough as a consumer when choosing a mobile OS, but it could be crippling for a business if required Native App A is in one company’s app store and required Native App B is another company’s.
Posted by joelhandwell on June 30, 2015 at 6:25 AM
I think Apple needs to hire you.
Posted by mherchel on June 30, 2015 at 6:41 AM
Good post. I’ve been saying this for a while now, too.
I think the crux of this comes down to motivations. Apple has a financial interest in selling as many apps as possible. If the web continues to evolve, it has the real potential to include functionality that is now only possible in apps. If this happens, companies will naturally cut out the middleman – who is Apple.
Microsoft did the same thing in the early 2000’s with IE6. They saw the potential of web apps taking over the Windows runtime. It’s scummy.
Apple is the new Microsoft.
Posted by Harvey Lubin on June 30, 2015 at 8:02 AM
“Apple is the new Microsoft”
Yes, Apple has taken over Microsoft’s position as the most valuable company in the world.
Apple and Microsoft also have something else in common… Neither of them is in the business of invading your privacy and collecting personal information about you, the way that Google does.
(͡° ͜ʖ°)
Posted by mherchel on June 30, 2015 at 8:50 AM
What does this post have to do with Google? Why are you drawing ASCII faces? Are you 13? Why are you attempting to defend Apple so much?
Posted by Harvey Lubin on June 30, 2015 at 9:39 AM
I am very sorry that you are offended by “ASCII faces” (text emoticons), but as the saying goes, you can’t please all of the people all of the time.
“Why are you attempting to defend Apple so much?”
My comment was NOT to defend Apple in particular, just to point out the hypocrisy. Your comment that it was all about “defending” Apple (as if they needed defending) is just a non sequitur, and may be indicative of your own thinking.
Posted by Luv Duv on June 30, 2015 at 10:06 AM
“Neither of them is in the business of invading your privacy and collecting personal information about you, the way that Google does.”
This statement discredits any viewpoint you may have on this topic.
Posted by JKoehn on June 30, 2015 at 12:37 PM
Harvey is a far too obvious troll trying to get everyone riled up with stupid irrelevant comments. Ignore the pathetic neckbeard.
Posted by Dennis on June 30, 2015 at 7:05 AM
“but a conspiracy seems unlikely, since that part of the business mostly breaks even”
I actually may have missed the humor, but that four year old link wasn’t even valid then (Apple’s sense of “barely breaks even” was estimated to be around $200 million in profit, which is enormous for most companies), and is certainly untrue now — Apple is making a gross $6-$7 billion per year from their cut of the app store. Running it takes money, of course, but in no imaginations does that cost even withing billions of Apple’s take.
The App Store has turned into the sort of enormously profitable venture that most organizations could only have fantasy dreams about. I’m not trying to support any conspiracy notion (the malaise about Safari is not likely someone weighing the two), but it is a misrepresentation.
Posted by eoghanmurray on June 30, 2015 at 7:49 AM
The ‘app store … mostly breaks even’ source is from 2011
Posted by Safari is the new IE | The WordPress C(h)ronicle on June 30, 2015 at 8:00 AM
[…] visit Read the Tea Leaves […]
Posted by Kroc Camen on June 30, 2015 at 8:29 AM
I wrote something very similar in nature five years ago!
“I do so hope that I will be wrong, but my gut feeling says that Safari will be the next IE6. Not in terms of being out of date (or ever reaching 99%), but in terms of being the elephant that will move for no man but Steve Jobs.” – http://camendesign.com/not_the_web
Posted by Pierre on June 30, 2015 at 8:57 AM
Having to add special code to handle Safari, when everything works flawlessly in all other browsers (even IE!) has led me to the same conclusion. Safari still does NOT validate HTML5 form (eventhough it does have all the plumbing in place), it still requires -webkit- prefix for features that are now standardize everywhere else… Ugh.
Posted by Spence Wetjen (@wetjen) on June 30, 2015 at 9:04 AM
I use Safari because its the most energy efficient browser for the mac. My battery life is about twice as long with Safari vs. Chrome. The downside to supporting every new thing will be energy consumption.
Posted by JKoehn on June 30, 2015 at 12:38 PM
Sorry but that’s just idiotic. You are obviously clueless about computers. No wonder you had to buy Apple.
Posted by mherchel on June 30, 2015 at 1:25 PM
Safari hater here. You’d think this is idiotic, but it’s not. I’m a completely remote dev, and whenever I use Google hangouts it runs way better in Safari (meaning my fan doesn’t turn on, computer slow down, etc). It’s very counterintuitive, but it’s 100% true.
I use Safari for two things: 1) Debugging crappy Safari issues and 2) Google Hangouts (so my MBP doesn’t slow to a crawl).
Posted by lattimorethomas on June 30, 2015 at 2:09 PM
I do the same as Mike. When I run any CPU intensive process like Google Hangouts or watch video, I do it in Safari. It handles these far better than Chrome or Ff.
Posted by George Stephanis on June 30, 2015 at 9:28 AM
Reblogged this on George Stephanis.
Posted by Jacob on June 30, 2015 at 9:52 AM
Surfin’ Safari used to be something I read on a regular basis. I don’t remember when it died for me, I think it just kind of faded off into the sunset.
Posted by Mike Bell on June 30, 2015 at 9:57 AM
Nolan Lawson blog post… aka how to lose little credibility some jackoff had.
Posted by John Bacon on June 30, 2015 at 12:14 PM
What is wrong with you?
Posted by JKoehn on June 30, 2015 at 12:39 PM
He’s proving how easy it is for a jackoff like him (Mile Bell) to lose credibility with one single sentence.
Posted by Piotr Lenczowski on June 30, 2015 at 1:09 PM
Man, those Apple fans get angry quickly.
Posted by Matthew Fabb on June 30, 2015 at 10:28 AM
I wonder if one of the reasons Apple is dragging behind with Safari is the fact that they lost one of their biggest contributors to WebKit, when Google forked it for Bink. Back when the fork first happened, some people made graphs out of the WebKit repository showing that Google contributed to about half of the code of WebKit, with Apple being responsible for 1/4 and the last 1/4 being made up with various other 3rd parties who use WebKit. That means Apple would have to triple their output on WebKit to keep up. Looks like they haven’t and are slowly but surely falling behind.
Posted by Vimarsh (@VimarshApi) on June 30, 2015 at 1:07 PM
I think it’s an amazing post where someone has the balls to talk about what they feel. I respect his opinion. It is about the Web and the things that should matter in a Browser. It isn’t about Apple vs “Any other Company”.
Posted by Tyler on June 30, 2015 at 2:09 PM
Option 4: Leave Safari behind and just start developing without it. If it’s the new IE, let it be so, with disclaimers that “this site will only work in modern browsers. Please use a different browser or switch to a device that supports one.” That’s the only way to put pressure on a company Apple’s size.
Also, regarding the “these days” paragraph: “Chrome is pushing the web about as far as it will go” is putting it nicely; in reality Chrome is busy introducing as many rendering bugs and regressions as it can.
Posted by Mikael on June 30, 2015 at 2:43 PM
It seems to me that most of the functions you list is WD? and only Chrome and Opera is supporting them.
Posted by Michael Tsai - Blog - Safari Is the New IE on June 30, 2015 at 3:02 PM
[…] Nolan Lawson (comments): […]