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

Update: Don Melton, who spearheaded WebKit and Safari at Apple, came on the Debug podcast with Guy English, Jim Ray, and yours truly, to talk all about "Safari is the new IE". His response, as you might imagine, was not safe for work.

There's an op-ed by Nowlan Lawson that's making the rounds—Ars Technica re-published it—with the provocative and sensational tile: Safari is the new Internet Explorer. In it, Lawson 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 whose 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 is 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 their absence from EdgeConf is by no means new or the result of these features not being supported. The Safari and WebKit teams do, for example, 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 hole 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 and started pulling ahead, Microsoft was more concerned with maintaining their platform and supporting their massive, entrenched customer-base 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 Lawson is mistaking for complacency is actually an evolution of perspective. Safari and WebKit won the battle for better web technology. Now they're fighting the battle for better security, privacy, and performance (including energy efficiency).

None of this is new—the culture of zero regression has been ingrained into the WebKit and Safari teams since their founding—It's simply moving from purely technical features to user-facing features.

Apple is still doing the tech: They've introduced Fourth Level LLVM and implemented WebGL. But they're also focusing on user-facing features:

  • iCloud Keychain, which syncs password and other data between browser instances.
  • Safari Extensions, which allow for functionality like auto-translation of pages.
  • Safari View Controller, a follow-on to UIWebView and WKWebView, brings login-state, form-fills, and other personalizations to embedded browsers.
  • Content blockers, which allow for plugins to remove resource-killing JavaScript, making browsing faster and more private.

And they're making it so that Safari on a new MacBook, for example, doesn't kill hours of battery life the way some other browsers do.

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

Here's a very brief description of each of them, and a link to more information:

  • Service Worker: Essentially background tasks, so browsers can send notifications, sync, geofence, etc. separately from the loaded page.
  • Web Components: Re-usable widgets for the web.
  • Shadow DOM: A sub-tree of DOM elements, or a way to encapsulate and isolate chunks of code away from the main tree.
  • Manifest: A centralized metadata repository for web apps.

Overall, they're part of the movement to try and make web apps more like native apps. Apple, which has both web and native platforms, 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 went instead to Palm's webOS, where the performance never caught up. Today, Apple doesn't even include Safari or WebKit on the Apple Watch.

That's not a knock—that's a profound understanding of context. The web is incredible flexible and dynamic, but it still isn't fast or efficient enough, especially on mobile. Apple and Facebook, among others, aren't dicking around with more developer-centric, native-hopeful features; they're busting ass to make it faster where it makes sense, and native where it doesn't. (See: TextKit or Instant Articles.)

Web-centric developers or web-only companies tend to see everything from a web-centric perspective. There's nothing inherently wrong with that, but those perspectives and their associated priorities might be very different from Apple's.

There will always be those who want cross-platform made easier for developers, whether it be through a more native-like web, or through better cross-compilers and interpreters. And there will always be those who want to make a platform as great an experience as possible for users, even if it means more or different work for developers.

Apple is no more letting Safari languish any more than other vendors are wasting time implementing features that real native apps already do better. They're all simply choosing to expend their time and money in directions they believe to be the most important. If they're saying "no" or "not yet", it's so they can focus on things they believe are better or more important right now.

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

Updated to better explain, and provide links to, the web technologies mentioned. Updated again to add Nolan Lawson's Twitter handle and fix some typos and phrasing issues.

Rene Ritchie
Contributor

Rene Ritchie is one of the most respected Apple analysts in the business, reaching a combined audience of over 40 million readers a month. His YouTube channel, Vector, has over 90 thousand subscribers and 14 million views and his podcasts, including Debug, have been downloaded over 20 million times. He also regularly co-hosts MacBreak Weekly for the TWiT network and co-hosted CES Live! and Talk Mobile. Based in Montreal, Rene is a former director of product marketing, web developer, and graphic designer. He's authored several books and appeared on numerous television and radio segments to discuss Apple and the technology industry. When not working, he likes to cook, grapple, and spend time with his friends and family.