Monthly Archives: June 2015

Safari is the new Internet Explorer? Or maybe not.

Today ArsTechnica posted a weak opinion piece by a Squarespace employee named Nolan Lawson. In it, Mr. Lawson uses some weak arguments wrapped in a cliched, flawed narrative about how Apple hates the web to try and rally web developers against Apple’s Safari browser.

What follows is the text of a comment I left in response:

Rapid change is great when everything sucks (for example IE 1-5), and when something that was formerly adequate has fallen years behind (ie IE 6 for of the the 2000s). Other times, steady incremental change is better for for users and developers. Well, most of them. It’s obviously not great for the ones that have an agenda they are pushing. On the web, in 2015, I suspect steady incremental change is best.This OpEd doesn’t really give me much reason to think otherwise.

The author makes a weak case for his assertion. It’s clear from some of the other comments here that some of the specific technologies the author mentions aren’t exactly fully baked or widely supported yet. I know from my own experience that, as a user, Safari is a hell of a lot better for my useage than Chrome on OSX from the point of view of responsiveness, memory use, and battery life (very important to me on my laptop). Apple’s focus on this actually makes web apps more viable for my use — I can have significantly more tabs open in Safari than I can in Chrome without bringing my computer to a grinding halt.

His piece seems driven by the cliched narrative that Apple hates the web because it threatens its platform dominance and the OS X app store. This narrative, while oft repeated, doesn’t really hold up to close scrutiny. For one thing, Apple’s web-friendlyness has a long and continuing history. They helped advance WebKit as a cross-platform alternative to IE and Firefox before Google Chrome was even a Windows-only beta. The original iOS app strategy was Web-app only. They were right in the thick of things trading off with Chrome in javascript performance. The developer tools that people loved about Chrome were originally Apple’s doing, and even though Apple took them in a direction that wasn’t exactly loved, they continued to refine and improve them. Despite the success of the App Store, Apple has continued to advance Safari on iOS as well. Things may have changed recently, but it wasn’t too long ago that Mobile Safari was better for developers and users than the original android browser, or Chrome for Android.

The pace has surely varied, but over time, Apple continues to push steady forward, and has continued to do so even as the App store has prospered, even as people like the author have flogged the “Apple hates the web” narrative.

Its hard not to think that the author might be predisposed to embrace the flawed “Apple Hates the Web” narrative because he identifies on his website as an “Android Fan,” but that’s just speculation on my part. All I know is that he makes a weak case, built on a weak foundation.

I have an alternate explanation that he may want to consider: Apple behaves as it does out of self-interest, yes, but self-interest that is largely and consciously aligned with the interests of end-users. That framing is consistent with my observation that, as an end user, Safari development in recent years has clearly focused on things that are better for me, like responsiveness, memory footprint, CPU utilization and battery life (all obviously interconnected). Putting it another way, Apple is striking a balance between its support for mainstream web standards and nascent web standards in a way that favors the majority of its end-users.

It also gives a hint for another reason why Apple may not be as all-in on the web as some others would like: The web is great, but it isn’t everything, at it isn’t even unambiguously the best at everything it does. Even a bleeding edge web app taking advantage of all the features of whatever browser the author thinks is best is likely to lag what is possible with a iOS or MacOS app using well worn frameworks and APIs. Apple, quite reasonably, thinks it is best for the company and its customers to balance its support of mainstream and nascent web standards with its support for developers of native iOS and OS X apps.

The author is, of course, free to have his own priorities, and to try to persuade Apple to adjust theirs, but in both cases, he’d do well to broaden his perspective, acknowledge his own biases, and think more critically and less dogmatically about the issues.