The web app developer’s lament

The ‘Safari is the new IE’ rhetoric highlights the pipedream at the heart of the universal web app vision.

• To be universal you need to deal with browsers even less capable than Safari (Opera Mini, the various Android WebKits that are still floating around). The only way you get to ignore Opera Mini and the Android WebKits is if you are treating the universality that is the core selling point of the web as an optional extra.

• To supplant native apps you need to match them in features and integration while still maintaining community consensus, which is clearly impossible. Native platforms vary too much for you to easily standardise integration and behaviour.

• To merely catch up with native apps you need to iterate faster than native platforms while, still, maintaining consensus and without descending into a spiral of bugs and instability, which is, again, impossible. Browsers are coming up from behind and native platforms aren’t standing still. Browsers have fewer app development features and less comprehensive APIs than native platforms and in many ways some of the basic features of the web platform (like layout) just don’t work that well for apps.

I said this here thing on Twitter yesterday (edited for clarity):

Not a day passes without a WebView, Safari, or Chrome tab crashing on one of my devices. Usually it happens several times a day. The core problem with visions of a future ruled by web apps is that, of all the platforms I regularly use, the web is the least usable and the least stable.

Speed, stability, features—pick one. If you want to make code more stable you stop adding features and prioritise correctness over speed.

And we’ve known this at least since the seventies, when Fred Brooks wrote The Mythical Man Month.

(You all should read The Mythical Man Month. That it is, still, one of the best books written on managing software development and project management should terrify you.)

It doesn’t matter whether I’m on iOS, Mac OS X, or Android. It doesn’t matter which browser I use. The web is the biggest source of day to day software instability in my work and my life.

Browser vendors are entirely to blame for consistently prioritising new features, new APIs, and performance over bugs and stability. All browsers suck.

Instead of talking about how to improve the overall stability (and thus viability) of the web app platforms, people prefer to slate Apple for a couple of crap Mobile Safari releases. (And it really has been just a couple of releases: iOS 7 and 8.)

The ‘Safari is the new IE’ is a lazy rhetorical tactic for implying that Apple is maliciously holding the web back without having to back it up with any facts.

The funniest part of all this is that web developers seem to have been living in a cave for the past year because they keep missing the likeliest explanation for Safari’s problems: the entirety of iOS 8 is a bit of a lemon.

The simplest explanation for a crap Safari release is that Apple has been having problems maintaining software quality in general.

Safari is likely to be hit hard by this since it’s a large and complex project—tightly integrated with the rest of the platform—that uses a lot of the OS’s APIs.

What to do?

Casting Apple as the villain trying to kill the web and spinning conspiracy fantasies isn’t productive.

Instead there are more constructive things we can do to improve the web. (You don’t need to browse far to see that people are already doing all of these things.)

• Document the bugs and flaws in how browsers implement web specifications. We can’t fix problems or work around them if we don’t know that they are broken.

• Never stop explaining why this or that new API is important for the web. Developer feedback helps vendors prioritise features.

• Establish a universal baseline of functionality in our web projects and then build up richer interactions using feature detection (otherwise known as progressive enhancement). Best part: we can define for ourselves what ‘universal baseline’ means for our projects. It doesn’t have to be ‘all browsers, even those with JavaScript disabled’. If our projects need a higher baseline, we can set a higher baseline. We just need to make sure it’s realistic.

• Be much more conservative in the features and APIs we use in our projects. It’s irresponsible and unprofessional to turn our customers and paying clients into guinea pigs for standards that are still in development. Many of the features that Safari hasn’t implemented are standards we shouldn’t be using because they are still experimental.

• Don’t base our product roadmaps on a browser or standards roadmap. These things change and they can change quickly. Chrome can pull support for CSS regions. Vendors can end up changing important details of larger projects like the web components effort. They can change important syntaxes even after a feature has been widely deployed.

Finally, and I’ve had to learn this the hard way¹, don’t develop an antagonistic relationship with platform vendors. Doing so makes people defensive and shifts their attention away from the problems with their platform.

Consider this analogy:

Your son, otherwise a sensible and well-meaning lad, has gotten himself a total moron for a boyfriend.

If you point out that the idiot your son is screwing is indeed an idiot, your son will take it as a personal attack and his attention shifts away from the dumb boyfriend and onto you. “Why are you always so mean?! I hate you!” ::slams door::.

If you go the passive aggressive route of subtle criticisms and jibes you create friction in your relationship with your son and you push them away. It has the same effect as pointing out the obvious, albeit slower, filled with more bitterness, and leading to higher therapy bills in the future.

The only path you can take is to trust your son. Consistently give the best advice you can give and behave with integrity yourself. Your offspring will eventually get over the fact that the boyfriend gives great head and the boyfriend’s idiocy will begin to grate on him.

And, most importantly, you need to keep open the possibility that there isn’t anything wrong with the boyfriend and that it’s you who is being an idiot.