Safari and IE

Two weeks ago I attended EdgeConf in London. If there is just one thing you are allowed to say about EdgeConf I would say that interesting things always happen during EdgeConf. It was just a year ago, during the previous EdgeConf in London that Yoav Weiss launched his crowdfunding campaign for implementing the picture element. When you put that many smart people in one room the level of the discussions is just astounding.

The most interesting thing of this EdgeConf however didn’t happen during the conference itself, but a few days after. Nolan Lawson published the now famous Safari is the new IE article on his blog and all hell broke loose. Even Don Melton — the godfather of Safari — called him out. The only thing more impressive would be Steve Jobs coming back from the dead and punching Nolan in the face.

It certainly didn’t come as a surprise to me. This subject came up in one way or another in just about every panel and every conversation I had during EdgeConf. In fact I think this sentiment is pervasive among professional web developers who have become frustrated with the apparent lack of innovation coming from Safari. It certainly wasn’t the first time I was asked the question whether or not Safari was becoming the new IE6.

Sure, the title was a bit link-baity 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 runner. Nolan was just the one who wrote it down first.

The comparison to IE may be deserved — it may not be. In any case the fact that there is such a sentiment is sign of an underlying problem.

First of all I must state that I am an avid Apple user. I own a MacBook Pro and an iMac. I use an iPad and an iPhone 6 and I even own an Apple Watch even though it is not yet available in my country. And I use Safari as the default browser on my Macs and on my iPhone. So whatever I am going to say next — nobody can accuse me of being biased against Apple.

Internet Explorer 6 was a good browser

The bad name that Internet Explorer got is certainly deserved, but Internet Explorer 6 in itself was not to blame. It was a really good browser… in 2001. Thanks to DOCTYPE switching it was actually the first browser that got CSS box model right, while keeping compatibility with old sites. IE 5 and 6 pioneered many technologies that we still use today — because they got standardised or because the idea itself got standardised in a different way. Opacity and shadows? Sure, it used proprietary filters, but it lead the way for box-shadow and the opacity css properties. Remember VML? Internet Explorer had a resolution independent, vector based layout language long before SVG was implemented in other browsers. Even the idea of web components are not new, Microsoft already supported HTML components in Internet Explorer 6.

Personally, I loved IE 6. As a web developer it allowed me to do things I wasn’t able to do before. And the comparison to its main competitor — Netscape 4 — was just plain embarrassing for Netscape.

And then Microsoft stopped any meaningful development on Internet Explorer for 4 years.

After doing nothing for 4 years, Internet Explorer 6 certainly wasn’t a good browser anymore. In fact Microsoft lost so much momentum that when IE 7 was released in 2006 it too was not good enough compared to other browsers from that era. Every release of Internet Explorer since then has been about trying to make up that 4 years of neglect. And it is just now — 9 years after the release of IE 7 — with the release of Edge that Microsoft is able to tentatively say it is on par with other browsers.

Is Safari a bad browser?

Safari and its rendering engine WebKit certainly have been at the forefront for many years. Safari gave us the ability to programmatically draw in the browser using the Canvas element and many exciting new CSS3 technologies such as Gradients, Transforms, Transitions and Animations. The capabilities that Safari introduced became so important, that long after they became proper standards, other browsers like Edge and Firefox are forced to support the old prefixed syntax that WebKit used to use.

WebKit became the de-facto rendering engine for mobile and was not only used by iOS, but also Android, Bada, BlackBerry, FireOS, S40, S60, webOS and many, many others. Also Google used the WebKit rendering engine for their own Google Chrome browser.

Despite humble beginnings as KHTML, and then a secret project at Apple with a brilliant, but bare-bones engineering team, it grew into the rendering engine with the largest number of engineers working on it.

That changed in 2013. Google forked WebKit and now spends its considerable engineering resources on Blink instead. And other companies followed. That leaves just Apple and a small number of other companies working on WebKit.

Back in 2013 I wrote an article “Thoughs on Blink” and I asked this:

I can’t imagine Apple abandoning WebKit, but that will mean that they will have to invest far more resources into WebKit just to keep the same development pace. Will they?

It’s now two years later and I think we can safely say the answer to that question is “No”. The number of engineers that Google has working on Blink is far greater than Apple has on WebKit.

It certainly looks like the WebKit team simply does not have the resources anymore to be at the forefront and propose new standards and features. That role has been taken over by Google. Instead it has become a follower that only implements a specification once it has proven itself in the field. It just can’t afford to just implement everything and see how it goes.

Combine that with the fact that Safari always has been a bit more conservative with shipping features and it is still using a yearly update schedule, it means that web developers need to wait a long time before certain features are available on all browsers. That doesn’t mean Safari is a bad browser, but given the market share of Safari, it does mean it is slowing the web platform down as a whole. And that is bad.

And it is unnecessary, because we’re talking about Apple here. If there is one company that has the financial resources to push the web forward, it is Apple. And for a short while, Apple did. And that leaves us with an extra bitter taste. If only Apple would give the WebKit team more resources…

Web vs. Native

What I can taste from some reactions to Nolan’s article, but also from face-to-face conversions is that some web developers think Apple is neglecting the web on purpose. I think that is misguided and I think native and web are not opposites to each other. And I know Apple doesn’t think so too, because why would they otherwise build their entire Apple Music product as a web app. When you open Apple Music in iTunes or the Music app on your phone or tablet it is a web app that runs in a WebView. And Apple Music isn’t the only example.

But in a completely different way it does add to the problem. The WebKit team at Apple not only has to deal with the demands from the web community, but also from native developers that use the WebView. So in iOS 9 we get all kinds of features that make little sense for web developers, such as the Safari View Controller and capabilities such as Force Touch events and the blur backdrop filter — which only makes sense as a way to make your web app look and act like a native app.

Safari is the new IE

So no, the two situations are not the same. But in some ways it isn’t too far fetched either. Both were browsers at the forefront of the web platform. Both gave us capabilities that we didn’t have before.

The problem with Internet Explorer wasn’t the browser itself, it was the resources that were put into developing it. They stopped all meaningful development for 4 years. That hasn’t happened with Safari, and Apple will certainly not allow that to happen in the future. But is the amount of resources that Apple dedicates to WebKit enough?

Simply by looking at the release notes for Safari 9, I would say “No”.