Safari is the new IE 2: Revenge of the Linkbait

The things I write rarely have broad appeal. I tend to write about weird esoteric stuff like IndexedDB and WebSQL, maybe throwing the normals a bone with something about CSS animations. I’m not some kind of thought-leader.

My “Safari is the new IE” article, however, got shared incessantly, was picked up by Ars Technica, and attracted the attention of people a lot smarter than me on both sides of the ensuing debate. Having no less than Don Melton call me out on Twitter has pretty much been the highlight of my career so far. It’s been overwhelming, to say the least.

I thoroughly enjoyed the resulting debate, though, and yes, there are valid arguments on both sides. So I’d like to pick up where I left off, and respond to my detractors while doubling-down on my claim that Safari is acting as an anchor in the web community. I’ll also end on a hopeful note, with some suggestions for reconciliation with Apple.

And since, judging by the response, people tend not to read much further than the first few paragraphs (or even the title!), I’ll keep the most important points up top, so nobody can miss them.

“Linkbait,” Safari != IE, etc.

I wrote that article in a mad rush the morning after I got back from EdgeConf. It was the culmination of a lot of frustration I’ve had with Safari over the past year or so, compounded by the fact that I just got back from a conference where I would have loved to pick the brain of somebody from Apple about it.

To be honest, I penned the whole thing in one go before settling on the title, which was based on something funny Calvin Metcalf had said in a presentation. Yes, the title was snappy, and yes, it was a bit sensational. But hey, nobody would be talking about it if I had called it “Meditations on the uncanny parallels between…” I choose headlines that grab attention; welcome to journalism 101.

So I find the “linkbait” accusations to be a boring argument, because it’s an argument that can be had without discussing the content of the article at all. More interesting were the arguments that the IE analogy is flawed, because Safari doesn’t have anything like ActiveX and Apple didn’t walk away from Safari for 5 years. All very good points. There’s also a case to be made that Android is more reminiscent of the old IE days, what with so many devices frozen in time on ancient versions of WebKit. (Although Lollipop, default Chrome, and Crosswalk have helped a lot lately.)

That being said, my point was to compare Safari to IE in terms of 1) not keeping up with new standards, 2) maintaining a culture of relative secrecy, and 3) playing a monopolistic role, by not allowing other rendering engines on iOS. Those accusations are pretty undeniable.

Web Components, Shadow DOM

I basically pulled these two examples out of a hat, because they were oft-discussed at EdgeConf, but I couldn’t find where Apple had even commented on them. Of course, such information is buried in mailing list discussions where I should have done the research to find it. (“Read the mailing list” is the “RTFM” of the W3C community.)

So yes, it was unfair of me to say that Apple “has shown no public interest” in those specs. I corrected the article and personally apologized to Ryosuke Niwa, who has been very active in the design of Web Components and Shadow DOM. Mea culpa; I made a dumb mistake.

The “user-centric web”

This point was made in a rebuttal article by Rene Ritchie, and although I enjoyed reading it, I don’t find the argument very persuasive. It boils down to a false dichotomy, saying that Apple can either focus on user-facing features (like speed and battery life) or new web APIs, but it can’t do both.

Other browser vendors, though, seem to be able to keep up with Google’s relentless pace (another counterargument), so I don’t understand how Apple, with its heaps of moolah, can’t do the same. And to those saying “it’s not the money, it’s finding the right people,” well, then maybe there’s a valid question about why Apple can’t find enough good browser developers. Something must have driven Google away when they forked WebKit into Blink (taking most of the committers with them), and I wonder if that same thing is keeping away new talent. But that’s a story I suspect only the WebKit/Blink developers really know.

From my own interactions with the WebKit developers, I can only conclude that they are sincere folks who take an extreme pride in their work. However, it’s become clear to me that Apple has different priorities, and that those priorities are limiting the potential of the WebKit team. One need only glance at the Safari 9 release notes to see both a paucity of new features, as well as a focus on proprietary and user-facing features. In terms of standards, a one-year release from Safari is comparable to two releases from Chrome, representing about 3 months of work. That’s a shockingly deep deficit.

(Proprietary or user-facing: force touch events, AirPlay, Picture in Picture, pinned tab icons, secure extensions, shared links, content blocking. Standards: scroll snapping, filters, ES6, unprefixing. Other: responsive design mode, Web Inspector overhaul, SFSafariViewController.)

As for Ritchie’s other argument that Apple is shying away from “native-hopeful” web features that “don’t make sense,” given the miraculous speed boosts that both WebKit and Chrome have demonstrated recently, I doubt anyone on either team actually shares that opinion. The web can reach 60 FPS, and where it can’t, that’s an argument for more progress in the web, not less.

IndexedDB, my idée fixe

Since nobody else brought this up, I’ll offer what I think is the best counterpoint to my article. What I basically did was take Apple’s utter bungling of IndexedDB, add in their lack of clear signals and iron grip on iOS, and extrapolate that Safari is dragging us back into some kind of new web Dark Ages. Okay! It sounds a bit hyperbolic, I’ll agree.

However, you’ll have to forgive me if I fixate on IndexedDB. While CSS features like scroll snap points and position:sticky are nice, I happen to think the thing that stores user data is pretty damned important. Imagine writing an iOS/Android app without SQLite/CoreData, and you’ll understand how badly web devs need consistent IndexedDB support. The fact that Apple messed it up so catastrophically shows a carelessness in their approach to the new, “appy” web.

Of course, that statement exposes my own bias in this debate, which I’ll gladly divulge. Namely: I’m an Android developer who’s tired of writing apps for a single platform, and wants webapps that can compete with native apps. That’s why I contribute to PouchDB – because although the IndexedDB spec is 5 years old, you still need a mountain of shims to get anything done with it. It’s a nasty situation, but PouchDB makes it bearable.

Even with tools like PouchDB, though, it’s still maddeningly difficult for web developers to create anything resembling a native app. And for that, the blame usually falls square on Safari, and especially mobile Safari. For instance, when PouchDB users ask me how much data they can store on iOS, and they find out it’s capped at 50MB with a modal popup after 5MB, they often say, “Thanks, but I’ll write a native app instead.” Yet when I complain about this stuff to Apple, they mostly shrug their shoulders.

Working on mobile webapps, I often find myself reaching for Safari polyfills (e.g. FastClick, which I cannot believe we still need), or relying on years-old standards that are in sore need of a replacement (WebSQL, AppCache, touch icons). Whereas at the same time, I’m seeing constant innovation from other browsers to improve the state of the “appy” web: Service Worker from Google, pointer events from Microsoft, and just about everything Mozilla has done on Firefox OS.

Gestures (touch-action). Vibration API. Ambient Light API. WebRTC (or Microsoft’s version). Device Orientation API. Permissions API. There’s a laundry list of things that would make my life easier as a webapp developer, and the one unifying feature is that their CanIUse page has two big red columns under “iOS” and “Safari.” You can add Web Manifests and Push API if you want to talk about stuff that’s still in the planning phase (not by Apple, though).

So yeah, by the raw HTML5Test numbers, Safari isn’t so far behind. But in the stuff that matters to me as a mobile and webapp developer, they’ve got a lot of catching up to do. And based on their priorities and release cycle, I’m not confident that they’re even keeping pace.

Engaging the community

The response to my article from web developers has been telling. Amidst all the “hear hear”s and their own tales of woe with Safari, you could detect that web developers just have an intense distrust of Apple. It’s revealing how quickly they started a petition against Apple, which to be honest made me kinda uncomfortable.

Let’s explore those feelings a bit, though. Why are web developers so wary of Apple? I have my own answer, and it touches on some of the most important points I raised in the article.

The web is increasingly becoming an open community. JavaScript is the most popular language on Github, and web developers are drowning in conferences, meetups, and hackathons. I regularly attend several meetups in New York City, many of which did not even exist a year ago. There are so many of these things nowadays, I can attend nearly one a week.

Through these community events and my activity on Github, I’ve had the pleasure of meeting and collaborating with people from Mozilla, Microsoft, and Google. Sometimes they’ve even come out of the blue to propose a pull request to PouchDB, or ask for feedback on IndexedDB. And yet, I’ve never once seen an Apple employee at any of these events, nor have I ever worked with any of them on an open-source project. My sole interaction with Apple has been through their bugtracker (or on Twitter, poking them to look at their bugtracker).

With even Microsoft being all chummy these days, the web has become an open party, but Apple is frequently tossing their invitation in the trash. This extends beyond the official discussions in the W3C mailing lists. As IE engineer Jacob Rossi put it, conferences like EdgeConf are “a crucial part of participating in standards.” As with any human endeavor, some of the most important discussions about the web platform are happening in hallways, at restaurants, and in face-to-face meetings. Apple can’t complain about getting cut out of the standards process, if they won’t even show up to join the conversation.

Apple’s lack of engagement with the broader web community has also been damaging to their reputation. By not making the effort to attend meetups, write blog posts, or set up forums for feedback, it’s no wonder developers are left with the impression that Apple doesn’t care about the web. Even just sending a developer evangelist to a few meetups to smile, nod, and answer questions politely would do wonders for their public perception.

Furthermore, Apple’s lack of boots on the ground at everyday developer soirées means that they’re increasingly out of touch with what developers want from the web platform. The fact that so many meetups and conferences have sprung up recently, and the fact that the web is fast becoming the world’s most advanced cross-platform application runtime are not isolated incidents. Developers like myself are getting excited about the web precisely because it’s supplanting all the old application paradigms. But as I pointed out above, the “appy” aspects of the web are exactly where Safari tends to falter.


Personally what I want out of this whole debate is for Apple to realize that the web is starting to move on without them, and that their weird isolationism and glacial release cycle are not going to win them any favors in this new, dynamic web community. I don’t even want them to open up iOS to other browsers nearly as much as I want them to just start coming to events and talking with web developers. Once they hear our gripes and see the frustration in our eyes as we describe how much we’ve struggled to support their browser, I think they’ll be motivated by empathy alone to start fixing these problems.

I do regret the generalizations and errata in my original post. However, I don’t regret starting the debate, because clearly I’ve touched a nerve at Apple, while casting a light on the widening divide between them and the rest of the web community. Maybe a harsh diatribe is exactly what Apple needs to shake them out of their complacency, even if it loses me a few friends in Cupertino.

So what I’m saying is this: next time I’m at a conference, I hope someone from Apple comes up to me, takes off a glove, and slaps me right in the face. Number one, because I kinda deserve it for being a jerk to them, and number two, because that would mean they’re finally coming to conferences.

Thanks to Jan Lehnardt, Chris Gullian, and Dale Harvey for reviewing a draft of this post.

41 responses to this post.

  1. Funny how Jobs #Flash flash for iOS. Nicely that stubbornness turned Apple into the loser in the end.

    And the winners are Chrome then Firefox. But especially open source.


  2. I read the original post and went “Well yeah, duh.” and moved on.

    Seeing this followup I’m pretty shocked that my (our) perspective was so different to what seems like a large swath of the community.

    I suspect that these truths are only self evident if you spend a lot of your time writing cross-platform applications on a web stack. It’s hard. It shouldn’t be this hard and we should be trying to fix it.

    “Just write a native app” is an easy thing to say to Facebook. One of my clients, though, is an educational publisher writing an application targeted at primary and early secondary students. They want to spend their budget dollars on new lesson plans, better resources to engage the students, etc. What they don’t want to do is quadruple their engineering budget to support writing a native app on all of their target platforms (Windows, OSX, iOS, Android), or succumb to what so much of the educational market does and just release on iOS only.

    When we, as an industry, fail at supporting these kinds of use cases it has consequences in the real world. The problem here is not just that using lots of shims is a PITA, it’s that worthwhile projects end up on the scrapheap because building them is cost prohibitive.

    Software is eating everything. This stuff matters.

    (And thanks for your work on Pouch. It’s easily the most interesting thing about the Couch ecosystem.)


    • Thank you. I appreciate the comment. :)

      I think the idea of “we’ll implement the same app twice, and WindowsPhone/Blackberry/FirefoxOS/web users can go jump in a lake” is an unsustainable business model, long-term. It’s a shame that the web is not currently up to the task, for the reasons I outline above.


  3. Posted by seriously on July 5, 2015 at 8:15 PM

    If you had just stated in the first article that you want every visited website to be able to store 50MB of data on


  4. Posted by seriously on July 5, 2015 at 8:17 PM

    If you had just stated in the first article that you want every website I visit to be able to silently store 50MB of data on my phone then we all could have had a good laugh and people wouldn’t have been tricked into taking it so seriously.

    Apologies for the partial comment. Your comment system somehow ate half of it when I clicked Post Comment. Another clear win for web applications.


    • Posted by bgallia on July 6, 2015 at 4:27 AM

      No one said they want to “silently store 50MB of data on [your] phone.” There are plenty of other ways than modal dialog boxes to notify the user. Also, to put 50MB in context, Apple will do over the air installs/updates of iOS applications up to 100MB and now allows applications up to 4GB in size.

      There is a big difference between notifying someone how much space is being used by an application and putting up a modal dialog box. Can you imagine what it would be like if every application purchased from the app store that is larger than 5MB produced a modal warning of it’s size?

      What is worse is some versions of Safari force you to ask up front for more than you may ever use. So, for example, if you have a game which has phone optimized graphics and tablet optimized graphics, it might be nice to ask for 20MB initially and only if someone enables tablet optimized graphics then ask for 50MB of space. However, Safari requires you ask for the 50MB regardless.

      As far as your partial comment issue, if you agree to stop referring to PHP applications and WordPress as “clear win for web applications” then I promise not to continually bring up Baby Shaker as an example of how bad iOS apps can be.


      • Exactly right. Other browsers have non-modal popups (“This website is storing a lot of data. Do you want it to continue?”) There are also proposals for a more interactive Quota Management API:

        I mostly see this as a UX problem. The fact that people are surprised that their browser can store 50MB of data tells me they’ve never looked in their browser’s “offline storage” settings:

        Chrome: Preferences -> Advanced -> Content Settings -> All Cookies and Site Data
        Firefox: Preferences -> Advanced -> Network
        Safari: Preferences -> Privacy -> Cookies and Website Data -> Details

        I also have a demo of a site that stores nearly 1GB:

      • Posted by seriously on July 7, 2015 at 4:44 AM

        Trying to reply to Nolan Lawson but, in another stunning victory for web apps, there’s no Reply button on that post, for me. I’m well aware that websites can store data, and I wish they were allowed less persistent storage (a couple kB for a login token at most) and not more, as you’re arguing for. Most features that browsers have added to support web apps have only made the internet worse for non-app/document use. I wish browsers would start removing features, e.g. the “leaving this page” notification, heavy use of javascript, etc. Ideally you guys were all forced onto some alternate “web” of badly-designed apps shoehorned into websites that I could ignore entirely.

      • Posted by bgallia on July 16, 2015 at 5:10 PM

        @seriously I understand now what you need so that “[we] guys” and our heavy use of javascript are kept segmented away.

        Please visit this page for the software you are asking for:

        In terms of your assertions that web applications are inherently badly-designed, even Apple disagrees with this premise. Instead, Apple has invested a lot of time and money in creating iCloud Drive web applications of Pages, Number and Keynote. There is no war on if web applications are coming in the future. Even Apple has accepted there will be web applications. The war is on the how rather than if. The resulting question is, what web browser in popular use will define the lowest common denominator of web APIs. Currently, among the top four web browsers, Safari is the most restrictive web API provider.

        Let me repeat that to make it clear: the bottom line is Safari has become the lowest common denominator for adoption of W3C standards and is the most restrictive environment for web application developers.

        Outside of that bottom line, nothing else really matter in terms of the topic. So, things like if someone can find which reply button to hit or if 8-track is better than new fangled Compact Discs aren’t part of this discussion. There is computer literacy courses to help you find the reply button or understand the concept that in the age of 64-bit computing that storage has become cheap. If someone wants a multi-platform application to do offline wikipedia reading, the application shouldn’t be restricted to the technical specifications of your TRASH-80 computer. Grow up and learn to live in 2015.

  5. Posted by Ggr2280 on July 5, 2015 at 9:39 PM

    More link bait propaganda. I will use safari over chrome any day.


    • You do realize that “use” and “develop for” are two entirely different things? This article is written from developers perspective. The fact that many people use Safari only makes it worse.


  6. iOS Safari still doesn’t support fullscreen and screen orientation lock! This is a niche feature, but really useful for interactive contents and mobile web games.


  7. Posted by UrFather on July 6, 2015 at 6:32 PM

    I’m with you Nolan and so are billion plus users on the planet. Ignore those “linkbaitstards” with “it” silent. they are crybabies just looking for attention.


  8. Posted by andypsolomon on July 6, 2015 at 8:58 PM

    Ladies and Gentlemen; we are currently in the First Great War of “Native(iOS) vs AppyWeb”. I love that term btw “appy”. And its time for everyone to be binary about this issue. You must choose one side. This may be a good time for the flash developers to sneak back onto the scene. I’m excited to see the outcome.


  9. I always use Safari. Its a good web browser…however, I still think Chrome is the best in term of functionality and flexibility. Safari does not seem to improve a lot nowadays.


  10. Posted by Ace McLoud on July 7, 2015 at 3:36 AM

    Why would I want a “Web app” when I can have native applications that are way more powerful and reliable while using much less power at the same time?


  11. Bravo ! I totally agree with your point of view. I also have lot of troubles with Safari (especially mobile Safari) when developping websites/web apps. Before your article, a few months ago I posted this tweet comparing Safari with IE6:


  12. […] week, Nolan Lawson wrote Safari is the New IE (and a follow-up), and it received quite a lot of attention. Nolan admitted that the title is linkbaity, and several […]


  13. Reblogged this on Wiadomości o technologiach IT and commented:

    Good bye Safari, you are old…


  14. […] Safari is the new IE 2: Revenge of the Linkbait […]


  15. […] and Nolan made a number of errors in his article – which he quickly corrected in his Safari is the new IE 2: Revenge of the Linkbait article. But the perception among web developers is that right now Safari is no longer a front […]


  16. Would love to hear your thoughts on whether you actually like JavaScript, or just tolerate it because it’s widespread and there’s no other choice? And I presume you’ve seen this:


  17. Posted by Laurie Ingriss on July 30, 2015 at 6:51 AM

    This is your blog; write what you want. This is your soapbox, for your opinion. You do not need to be an apologist to the rabid masses.


  18. The new IE 2? It’s much more advanced than that.


  19. Posted by Double Rider on December 16, 2015 at 9:27 PM

    Follow the money. Apple makes the most on the iPhone. They want iOS apps only so there is a reason to buy their hardware. Web apps mean you can run on anything. Google is a browser company. They make money on web ads. Microsoft is just desperate just to stay in the game. You think Google is big now, wait till Apple goes the way of MS. It will happen. People will get sick of their milking the cash cow. Then Google will rule like you have never seen before.


    • Posted by esalija on February 1, 2016 at 2:49 PM

      This is a false comparison bevause benefiting from the open web is like benefiting from curing cancer while benefiting from trying to kill the web and the ridiculous anti-competitive acts Apple does is like benefiting from selling tobacco.


  20. Posted by DWalla on September 21, 2016 at 1:46 PM

    I pick Opera over Safari or Chrome. All the advancements of Chrome without the data mining.


  21. […] and Nolan made a number of errors in his article — which he quickly corrected in his Safari is the new IE 2: Revenge of the Linkbait article. But the perception among web developers is that right now Safari is no longer a front […]


  22. Posted by Tim on August 11, 2021 at 8:57 AM

    “It boils down to a false dichotomy, saying that Apple can either focus on user-facing features (like speed and battery life) or new web APIs, but it can’t do both.
    Other browser vendors, though, seem to be able to keep up with Google’s relentless pace”

    They do? Besides Apple, I haven’t found anyone else — even (or especially) Google — who can make a browser that gives me great battery life.

    There are areas where Chrome is ahead of Safari but I haven’t heard anyone propose that it’s good at battery efficiency.


Leave a Reply to esalija Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.