Archive for July, 2015

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.

Conclusion

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.