Safari isn’t the new IE: it’s the user-centric web

There's an op-ed that's making the rounds—Ars Technica re-published it—with a fairly provocative and sensational tile: Safari is the new Internet Explorer. It argues that Apple has become complacent with Safari and is letting it languish by not more aggressively adopting emerging web technologies like Service Worker, Web Components, Shadow DOM, and Web Manifests. It reads as sincere—and as frustrated.

From the point of view of a developer who's personal favorite new technologies aren't getting as wide or deep support as he'd like, that's certainly understandable. But there's another, arguably more important point of view to consider, which also seems to be the one Apple considering: users.

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.

First, Apple engineers, including WebKit and Safari engineers, don't typically go to conferences outside WWDC. That's been changing in recent years, and may change further, but the author noting their absence from EdgeConf is by no means noteworthy. They do, however, participate in the standards bodies, including in person.

Second, Internet Explorer was never intentionally complacent. It was a lock-in. ActiveX was originally designed to fill a gaping whole in web functionality, but through that it became a platform. That allowed a level of dominance over the web, and a symptom of that dominance was complacency. By the time the web caught up, Microsoft was more concerned with maintaining their platform than evolving IE, and it hurt them. The same thing happened later with Adobe and Flash.

Apple is doing the opposite. Safari is of and for the open web. It has no delusions of becoming a platform. HTML5 is its platform. (If anything, Chrome and ChromeOS are in far greater danger of becoming an IE-style platform than Safari and WebKit.)

Safari and WebKit won the battle for better web technology. Now they're fighting the battle for better security, privacy, and performance.

You have only to look back at KHTML to see WebKit's roots, and its contributions to the open web. Especially to the mobile open web, which previously languished in WAP, Pocket IE, and Blazer purgatory.

What the author is mistaking for complacency is actually evolution. Safari and WebKit won the battle for better web technology. Now they're fighting the battle for better security, privacy, and performance.

None of this is new, of course. The culture of zero regression has been ingrained into the WebKit and Safari teams since their founding. They're simply moving from pure technical features, like FTL, to user-facing features.

Apple is still doing the tech: They've implemented WebGL and secured it all the way down the stack, but they're also use facing features:

• Safari View controller means we can bring our login-state, form-fills, and other personalizations with us into apps, securely and privately.
• Content blockers mean resource-killing JavaScript can itself be killed, making our browsing faster and more private.
• News will allow web-based content to be better and more consistently presented.
• Pinned tabs and easy mute buttons will make browsing more convenient and less maddening.
• The new Web Inspector will even make developers' jobs easier.

Most of the technologies the author mentions don't seem to be well or fully implemented by other browsers either, and philosophically not every vendor may agree with them either. The web is not only a velocity, after all, but a direction.

That's' especially true for a company like Apple, which has both web and native platforms, and has historically been smart about using the right one for the right job.

Many years ago there was an argument about whether web technology or native technology should form the interface layer for the iPhone. Native won, and web technologies ended up on Palm's webOS. We all know how that ended. Today, Apple Watch doesn't even include Safari or WebKit.

That's not a knock—that's a profound understanding of context. The web isn't fast enough, especially on mobile, and Apple and Facebook and others aren't dicking around with more developer-centric features; they're busting ass to make it faster where they can, and native where they can't. (See: TextKit.)

That doesn't mean web-centric developers or web-only companies are wrong, but it does mean they may have different priorities and perspectives from Apple.

In other words, the WebKit and Safari teams aren't sitting around the Cupertino offices making paper airplanes, thinking there are no browser world's left to conquer. They're simply conquering different browser worlds.

And that's an incredibly Apple thing to do.