Update: This post represents my views before I joined the Microsoft Edge team, and before I got involved with browsers or web standards in general. I leave it up as a historically interesting artifact.
Last weekend I attended EdgeConf, a conference populated by many of the leading lights in the web industry. It featured panel talks and breakout sessions with a focus on technologies that are just now starting to emerge in browsers, so there was a lot of lively discussion around Service Worker, Web Components, Shadow DOM, Web Manifests, and more.
EdgeConf’s hundred-odd attendees were truly the heavy hitters of the web community. The average Twitter follower count in any given room was probably in the thousands, and all the major browser vendors were represented – Google, Mozilla, Microsoft, Opera. So we had lots of fun peppering them with questions about when they might release such-and-such API.
There was one company not in attendance, though, and they served as the proverbial elephant in the room that no one wanted to discuss. I heard them referred to cagily as “a company in California” or “a certain fruit company.” Their glowing logo illuminated nearly every laptop in the room, and yet it seemed like nobody dared speak their name. Of course I’m talking about Apple.
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. (Correction: actually, they have.) When you start browsing caniuse.com, the list goes on and on.
Even when Apple does implement newer APIs, they often do it halfheartedly. To take an example close to my heart, IndexedDB was proposed more than 5 years ago and has been available in IE, Firefox, and Chrome since 2012. Apple, on the other hand, didn’t release IndexedDB until mid-2014, and when they did, they unveiled a bafflingly incompetent implementation that was so bad, it’s been universally derided as unusable. (LocalForage, PouchDB, and YDN-DB, the major IndexedDB wrappers, all ignore Safari’s version and fall back to WebSQL.)
Now, after one year, Apple has fixed a whopping two bugs in IndexedDB (out of several), and they’ve publicly stated that they don’t find much value in working on it, because they don’t see “a huge use.” Well duh, nobody’s going to use IndexedDB if the browser support is completely broken. (Microsoft, I’m looking at you too.)
It’s hard to get insight into why Apple is behaving this way. They never send anyone to web conferences, their Surfin’ Safari blog is a shadow of its former self, and nobody knows what the next version of Safari will contain until that year’s WWDC. In a sense, Apple is like Santa Claus, descending yearly to give us some much-anticipated presents, with no forewarning about which of our wishes he’ll grant this year. And frankly, the presents have been getting smaller and smaller lately.
In recent years, Apple’s strategy towards the web can most charitably be described as “benevolent neglect.” Although performance has been improving significantly with JSCore and the new WKWebView, the emerging features of the web platform – offline storage, push notifications, and “installable” webapps – have been notably absent on Safari. It’s tempting to interpret this as a deliberate effort by Apple to sabotage any threats to their App Store business model, but a conspiracy seems unlikely, since that part of the business mostly breaks even. Another possibility is that they’re just responding to the demands of iOS developers, which largely amount to 1) more native APIs and 2) Swift, Swift, Swift. But since Apple is pretty good at keeping a lid on their internal process, it’s anyone’s guess.
The tragedy here is that Apple hasn’t always been a web skeptic. As recently as 2010, back when Steve Jobs famously skewered Flash while declaring that HTML5 is the future, Apple was a fierce web partisan. Lots of the early features that helped webapps catch up to native apps – ApplicationCache, WebSQL, touch events, touch icons – were enthusiastically implemented by WebKit developers, and many even originated at Apple.
Around that same time, when WebSQL was deprecated in favor of IndexedDB, you’ll even find mailing list arguments where Apple employees vigorously defended WebSQL as a must for performant web applications. Reading the debates, I sense a lot of bitterness from Apple after IndexedDB won out. The irony here is that Apple nearly gave us the tools to undermine their own proprietary platform, but by rejecting WebSQL, we gave them an opportunity to rethink their strategy and put the brakes on any new progress in web APIs.
I find Application Cache, which will probably soon be deprecated in favor of Service Worker, to be a similar story. It gained wide browser support at a time when Apple was still interested in the web, but unfortunately it turned out to be a rushed, half-baked solution to the problem. I worry that Service Worker might suffer the same fate as IndexedDB, if Apple continues to lag behind the pack.
At this point, we in the web community need to come to terms with the fact that Safari has become the new IE. Microsoft is repentant these days, Google is pushing the web as far as it can go, and Mozilla is still being Mozilla. Apple is really the one singer in that barbershop quartet hitting all the sour notes, and it’s time we start talking about it openly instead of tiptoeing around it like we’re going to hurt somebody’s feelings. Apple is the most valuable company in the world; they can afford to take a few punches.
So what can we do, when one of the major browser vendors is stuck in the 2010 model, and furthermore has a total monopoly on iOS (because no, “Chrome for iOS” is not really Chrome), showing a brazenness even beyond that of 90’s-era Microsoft? I see three major coping mechanisms:
- Stick with what worked in 2010, and use polyfills to support Safari. This is a strategy I highlighted in my opening talk for the frontend data panel, where I showed that you can get nearly the same features as Service Worker by using AppCache and PouchDB (which falls back to WebSQL on Safari). This approach should appeal to the vast majority of web developers, who tend to hit the snooze button on new technologies until they’re available cross-browser. On the other hand, it’s also a good way to coddle Apple and give them no incentive to step up their game.
-
Use technologies like Service Worker that don’t work on Safari, and consider it a progressive enhancement. Alex Russell made a great point about this during the “installable webapps” breakout, arguing that if we create a large body of free webapps that use Service Worker, and which work fabulously well on Android but only meh on iOS, then it will be in Apple’s interest to suck it up and support the API. Unfortunately, while this would be the best outcome for the web community as a whole, it’s going to be hard to convince developers to write code that only reaches half their audience.
-
Contribute to WebKit. The core of Safari is still, after all, an open-source project, so there’s no practical reason why anyone with the C++ chops couldn’t roll up their sleeves and implement the new APIs themselves. (The absurdity of giving free labor to the richest company on earth isn’t lost on me, but we’re talking desperate times here.) The major problem I see with this approach is that WebKit is not Safari, and Apple could still decide to not deploy WebKit features to their flagship browser. To circle back to IndexedDB again, it was fully implemented by Google well before the Blink fork, and for several years, Apple could have just flipped a bit in their build script to include Google’s implementation, but instead they decided to waffle for a few years and then replace it with their own broken version. (Update: see note on IndexedDB below.) There’s no guarantee they wouldn’t do the same thing for other outside contributions.
So in summary, I don’t know what the right solution is. I’ve engaged many of the WebKit developers on Twitter, and I’ve even done the hard work of writing reproducible test cases and trying out their beta software so I can give them early warning. (Yes, I fork over $200 a year to Apple, for the privilege of testing their own software for them.) And frankly I’ve grown bitter, because most of the bugs I’ve reported have languished, with little response other than a link to their internal Radar tracker.
I appreciate the work that many of the WebKit developers have been doing (Brady Eidson has been particularly patient and helpful), but at this point it seems to me that the best strategy toward Apple may be the stick rather than the carrot. So I’m inclined to take up Alex Russell’s solution outlined in #2 above, and to start promoting the adoption of new web technologies – Safari support be damned.
If we can start building a vibrant ecosystem of web applications where Apple is not invited, then maybe they’ll be forced to pull a Microsoft and make their own penitent walk to Canossa. Otherwise we’ll have to content ourselves with living in the web of 2010, with Safari replacing IE as the blue-tinged icon that fills web developers with dread.
Update on IndexedDB: I’m told by Ryosuke Niwa at Apple that Google’s IndexedDB was not so easily usable in Safari, even pre-fork. So it wasn’t a build flag. However, in a private discussion with a Google employee, I’m told that the IPC layer was abstracted to a degree that it shouldn’t have been too difficult for Safari to use. In any case, it’s true that Apple had something close to a fully working implementation years before they shipped their inferior version.
You can comment on Hacker News, on Ars Technica, and on Twitter. Thanks to Jan Lehnardt, Dave Myers, Beckie Choi, and Julian Applebaum for providing feedback on a draft of this blog post.
Posted by tobielangel on June 30, 2015 at 6:15 AM
In the title: s/Safari/Mobile Safari
Posted by Nolan Lawson on July 3, 2015 at 2:12 PM
Heh. :)
Posted by Andrew Rondeau on June 30, 2015 at 6:15 AM
I think you’re missing the point. The browser is a document viewer, not an application delivery platform. Back in 2005 we all thought that web-based applications were going to take the world by storm, but now that we have slick application stores on all major platforms, this isn’t the case.
If you need functionality like you describe, ship a native application via an app store. It’s a much better experience than web development.
Posted by chris portscheller on June 30, 2015 at 6:25 AM
People still use computers…
Posted by foljs on June 30, 2015 at 6:39 AM
Increasingly less.
Posted by Paul on June 30, 2015 at 8:25 AM
…as do companies. I don’t see many native apps being used in the corporate environment. If it doesn’t work in a browser, and if fact, if it’s not certified to work in a browser, then it’s a big problem for us.
Posted by Me on June 30, 2015 at 8:36 AM
For some reason I can’t reply to the “Increasingly less” comment, but this point that people keep trotting out is so irritating. Yes, fewer people use traditional desktop computers now than five years ago, and the decline corresponds to an increase in the use of mobile devices like tablets and smartphones. But this does not mean that this trend will continue forever. Equilibrium will be reached at some point (barring another revolution in technology hitherto unforeseen), and when it is there will still be a vast number of traditional PCs in use, not least in business. Deciding to stop fully supporting applications on desktop browsers now because, in this moment, desktop PC usage is falling as mobile device usage is increasing would be ludicrously myopic.
Posted by ronnykaram on June 30, 2015 at 2:17 PM
I fail to understand the approach where people decide that computers are used less than before. Well, smartphones and tablets are the new comers and yes their numbers increased significantly, but that doesn’t mean that people who use computers dropped them completely in favor of handhelds.
There are more people accessing the internet through their smartphones, true, but when you want to do actual work you’re not gonna struggle with your iPad or smartphone to fill a 2 pages Excel sheet.
But that is also not the debate here.
It’s Safari… not implementing Web APIs as fast as they should (or sometimes not at all) because they’re being lazy, or maybe have other plans in mind. And that’s breaking Web developers backs.
Posted by Carlin Scuderi (@carlinscuderi) on June 30, 2015 at 6:26 AM
I disagree. HTML5 in of itself was built with applications in mind, and I’ve seen numerous web applications that, when used, are not different from their native counterparts in terms of performance and features. There’s also technology on the horizon that is going to push this even further.
Posted by robotlovesyou on June 30, 2015 at 6:36 AM
This whole “The web is for documents, apps are for everything else” position is based upon a false dichotomy. There is a whole spectrum of functionality between a dumb web document with a couple of hyperlinks and images in it and a super slick iOS UI coded in swift or ObjC and a more homogeneous and performant web helps us, as developers, deliver it.
Posted by Dennis on June 30, 2015 at 8:44 AM
It is a nonsense line of logic that has everything only ever being useful for its original purpose, ignoring enormous changes that have happened since. The “for documents” line being a particularly dumb one.
Posted by mherchel on June 30, 2015 at 6:42 AM
wut?
Posted by Alex on June 30, 2015 at 6:45 AM
Ahhh shit, you’re right. Someone should tell these people that the browser is just a document viewer. They seem to be wasting their time.
https://www.khronos.org/webgl/wiki/Main_Page
https://github.com/WebAssembly
https://developer.mozilla.org/en-US/docs/WebSockets
https://angularjs.org/
http://backbonejs.org/
http://emberjs.com/
http://d3js.org/
http://www.isogenicengine.com/
http://webcomponents.org/
Oh, and Brendan Eich. That guy’s a TOTAL idiot.
Posted by Arielext on June 30, 2015 at 7:36 AM
ignorance is bliss
Posted by Me on June 30, 2015 at 8:20 AM
A native app doesn’t necessarily give a better experience (or it needn’t), and often a native app is just overkill. In any case, I don’t want to live in a world where I have to choose an operating system that has satisfactory versions of the greatest number of apps that I want to use available in its app store. I want to have applications that run on any platform I choose, be it Windows, iOS, Mac OSX, Chrome OS, etc., and this achieved by web applications running in browsers available on all of those platforms.
Moving away from web standards and web apps towards native apps in walled gardens is so glaringly obviously a retrograde step. It’s annoying enough as a consumer when choosing a mobile OS, but it could be crippling for a business if required Native App A is in one company’s app store and required Native App B is another company’s.
Posted by Scott Stawarz (@scottstawarz) on July 1, 2015 at 8:12 AM
@Andrew Rondeau
I think you and whole bunch of commenters are missing the point. Safari usage is quite high thanks to mobile safari iOS and Safari is lagging behind the other browsers in api functionality. If apple doesn’t keep up with chrome, firefox, and IE, then their browser will eventually become obsolete. Right now Web App Developers and website developers, have to choose whether to implement the new API’s.
Not every situation needs a native app.
Posted by joelhandwell on June 30, 2015 at 6:25 AM
I think Apple needs to hire you.
Posted by mherchel on June 30, 2015 at 6:41 AM
Good post. I’ve been saying this for a while now, too.
I think the crux of this comes down to motivations. Apple has a financial interest in selling as many apps as possible. If the web continues to evolve, it has the real potential to include functionality that is now only possible in apps. If this happens, companies will naturally cut out the middleman – who is Apple.
Microsoft did the same thing in the early 2000’s with IE6. They saw the potential of web apps taking over the Windows runtime. It’s scummy.
Apple is the new Microsoft.
Posted by Harvey Lubin on June 30, 2015 at 8:02 AM
“Apple is the new Microsoft”
Yes, Apple has taken over Microsoft’s position as the most valuable company in the world.
Apple and Microsoft also have something else in common… Neither of them is in the business of invading your privacy and collecting personal information about you, the way that Google does.
(͡° ͜ʖ°)
Posted by mherchel on June 30, 2015 at 8:50 AM
What does this post have to do with Google? Why are you drawing ASCII faces? Are you 13? Why are you attempting to defend Apple so much?
Posted by Harvey Lubin on June 30, 2015 at 9:39 AM
I am very sorry that you are offended by “ASCII faces” (text emoticons), but as the saying goes, you can’t please all of the people all of the time.
“Why are you attempting to defend Apple so much?”
My comment was NOT to defend Apple in particular, just to point out the hypocrisy. Your comment that it was all about “defending” Apple (as if they needed defending) is just a non sequitur, and may be indicative of your own thinking.
Posted by Luv Duv on June 30, 2015 at 10:06 AM
“Neither of them is in the business of invading your privacy and collecting personal information about you, the way that Google does.”
This statement discredits any viewpoint you may have on this topic.
Posted by JKoehn on June 30, 2015 at 12:37 PM
Harvey is a far too obvious troll trying to get everyone riled up with stupid irrelevant comments. Ignore the pathetic neckbeard.
Posted by Stefan on August 18, 2015 at 12:04 AM
Actually, they do.
Posted by Dennis on June 30, 2015 at 7:05 AM
“but a conspiracy seems unlikely, since that part of the business mostly breaks even”
I actually may have missed the humor, but that four year old link wasn’t even valid then (Apple’s sense of “barely breaks even” was estimated to be around $200 million in profit, which is enormous for most companies), and is certainly untrue now — Apple is making a gross $6-$7 billion per year from their cut of the app store. Running it takes money, of course, but in no imaginations does that cost even withing billions of Apple’s take.
The App Store has turned into the sort of enormously profitable venture that most organizations could only have fantasy dreams about. I’m not trying to support any conspiracy notion (the malaise about Safari is not likely someone weighing the two), but it is a misrepresentation.
Posted by eoghanmurray on June 30, 2015 at 7:49 AM
The ‘app store … mostly breaks even’ source is from 2011
Posted by Safari is the new IE | The WordPress C(h)ronicle on June 30, 2015 at 8:00 AM
[…] visit Read the Tea Leaves […]
Posted by Eugene Bujak on June 30, 2015 at 8:18 AM
1) offline storage is available on safari — https://developer.apple.com/library/safari/documentation/iPhone/Conceptual/SafariJSDatabaseGuide/Introduction/Introduction.html
2) push notifications are available in safari — https://developer.apple.com/notifications/safari-push-notifications/
3) “installable” webapps have been since iOS1, it’s called “add to home screen” — http://www.cellcode.com/news/how-to-add-iphone-icon-to-your-website/
4) App Store mostly breaking even — was pointed before me.
Posted by Kroc Camen on June 30, 2015 at 8:29 AM
I wrote something very similar in nature five years ago!
“I do so hope that I will be wrong, but my gut feeling says that Safari will be the next IE6. Not in terms of being out of date (or ever reaching 99%), but in terms of being the elephant that will move for no man but Steve Jobs.” – http://camendesign.com/not_the_web
Posted by beaniiman on July 1, 2015 at 7:18 AM
Nailed it!
Posted by Laurie Ingriss on July 30, 2015 at 6:49 AM
It’s not going to be moving very far now then.
Posted by Pierre on June 30, 2015 at 8:57 AM
Having to add special code to handle Safari, when everything works flawlessly in all other browsers (even IE!) has led me to the same conclusion. Safari still does NOT validate HTML5 form (eventhough it does have all the plumbing in place), it still requires -webkit- prefix for features that are now standardize everywhere else… Ugh.
Posted by Spence Wetjen (@wetjen) on June 30, 2015 at 9:04 AM
I use Safari because its the most energy efficient browser for the mac. My battery life is about twice as long with Safari vs. Chrome. The downside to supporting every new thing will be energy consumption.
Posted by JKoehn on June 30, 2015 at 12:38 PM
Sorry but that’s just idiotic. You are obviously clueless about computers. No wonder you had to buy Apple.
Posted by mherchel on June 30, 2015 at 1:25 PM
Safari hater here. You’d think this is idiotic, but it’s not. I’m a completely remote dev, and whenever I use Google hangouts it runs way better in Safari (meaning my fan doesn’t turn on, computer slow down, etc). It’s very counterintuitive, but it’s 100% true.
I use Safari for two things: 1) Debugging crappy Safari issues and 2) Google Hangouts (so my MBP doesn’t slow to a crawl).
Posted by lattimorethomas on June 30, 2015 at 2:09 PM
I do the same as Mike. When I run any CPU intensive process like Google Hangouts or watch video, I do it in Safari. It handles these far better than Chrome or Ff.
Posted by Ben on June 30, 2015 at 8:08 PM
Google Chrome is designed around a very heavyweight sandbox centric model. They have the Pepper Plugin API and NaCl environments that can be taxing on resources. These are then in turn activated by things that Google installs with Chrome by default like the PPAPI based Adobe Flash and Google’s Search by Voice NaCl module. Adding these sandboxes into Safari probably would increase the energy use of Safari as well. However, none of these are standards from the W3C and will never appear in the list of items on caniuse.com
The idea that supporting the W3C standards will lead to a downside of higher energy consumption is likely flawed. As stated earlier by the article, one of the common ways to address browsers that lack native implementations of W3C standards is to polyfill. That means that functionality which should have already been installed and run as native code is now downloaded as javascript and run as interpreted code. Hence, the polyfill will have it’s own additional energy (and performance) overhead.
If the W3C is writing standards where there is a more energy efficient way of doing it, then Apple should be calling attention to that during the drafting process. After all, the W3C is an open forum. As far as I know, Apple has never claimed battery use as a problem to any of the standards that they currently provide either no implementation or a buggy implementation.
Posted by Laurie Ingriss on July 30, 2015 at 6:42 AM
If energy efficiency is your drive, there are computers that are far more efficient at saving energy than any Apple laptop device. The reality is, most people are not that bothered about energy efficency beyond “will my battery work on the train journey home?” If it will, they are happy, with or without Mac.
Posted by Jacob on June 30, 2015 at 9:52 AM
Surfin’ Safari used to be something I read on a regular basis. I don’t remember when it died for me, I think it just kind of faded off into the sunset.
Posted by Mike Bell on June 30, 2015 at 9:57 AM
Nolan Lawson blog post… aka how to lose little credibility some jackoff had.
Posted by John Bacon on June 30, 2015 at 12:14 PM
What is wrong with you?
Posted by JKoehn on June 30, 2015 at 12:39 PM
He’s proving how easy it is for a jackoff like him (Mile Bell) to lose credibility with one single sentence.
Posted by Piotr Lenczowski on June 30, 2015 at 1:09 PM
Man, those Apple fans get angry quickly.
Posted by Matthew Fabb on June 30, 2015 at 10:28 AM
I wonder if one of the reasons Apple is dragging behind with Safari is the fact that they lost one of their biggest contributors to WebKit, when Google forked it for Bink. Back when the fork first happened, some people made graphs out of the WebKit repository showing that Google contributed to about half of the code of WebKit, with Apple being responsible for 1/4 and the last 1/4 being made up with various other 3rd parties who use WebKit. That means Apple would have to triple their output on WebKit to keep up. Looks like they haven’t and are slowly but surely falling behind.
Posted by Nolan Lawson on July 3, 2015 at 2:13 PM
Have a link? I saw that same article, but can’t seem to find it now. #lazywebs
Posted by Vimarsh (@VimarshApi) on June 30, 2015 at 1:07 PM
I think it’s an amazing post where someone has the balls to talk about what they feel. I respect his opinion. It is about the Web and the things that should matter in a Browser. It isn’t about Apple vs “Any other Company”.
Posted by Tyler on June 30, 2015 at 2:09 PM
Option 4: Leave Safari behind and just start developing without it. If it’s the new IE, let it be so, with disclaimers that “this site will only work in modern browsers. Please use a different browser or switch to a device that supports one.” That’s the only way to put pressure on a company Apple’s size.
Also, regarding the “these days” paragraph: “Chrome is pushing the web about as far as it will go” is putting it nicely; in reality Chrome is busy introducing as many rendering bugs and regressions as it can.
Posted by Mikael on June 30, 2015 at 2:43 PM
It seems to me that most of the functions you list is WD? and only Chrome and Opera is supporting them.
Posted by Michael Tsai - Blog - Safari Is the New IE on June 30, 2015 at 3:02 PM
[…] Nolan Lawson (comments): […]
Posted by Alex on June 30, 2015 at 4:06 PM
What is the problem in providing good native client interface?
I personally enjoy using native apps unless it is a bad Cordova implementation and I have to have a good network Connection in my packed train which never happens….
Posted by Anonymous Coward on July 1, 2015 at 2:45 AM
The problem with providing good native client interfaces is cost – I don’t mean money per se, I mean developer time. It takes at least twice the time to do the same interface natively vs in HTML5, on both Android and iOS, IME.
There’s a reason for this. Browsers were historically developed to be increasingly powerful and flexible layout engines, since layout was their primary purpose for a long time. Native app development tools were at best developed to support the creation of highly OS-integrated, branded applications. However, in many modern applications looks are what takes up a disproportionate amount of time – not because it is important to users, but because it is important to sales and marketing. This simply makes browsers/HTML5 a more convenient development environment for most applications.
Yes, for businesses the higher development effort translates to money, but it also translates to a higher opportunity cost, which is the actual important cost. They get new products or improvements to existing products out the door in double the time – in software development, adding developers to a project doesn’t increase speed linearly.
Sure enough, neither native nor HTML5 guarantees a quality product. Therefore, I wouldn’t blame the technology for a product’s quality or lack thereof, neither would I automatically ascribe bad quality to a non-native application.
But not providing a standards-compliant browser for developers surely makes development for that platform slower, more error-prone and less speedy. By doing this, at least on iOS HTML5 apps are clearly discriminated against. Which makes sense, in a short-sighted commercial way: why would Apple support developers in their effort of creating cross-platform applications?
Long term, as cloud, IoT, mobile and desktop become more integrated, both from a user’s and a developer’s point of view, this would isolate Apple from the bigger market, but given its current market share that’s not an actual concern for them, I think. Right now, they can afford to trample on user’s and developer’s best interest to maximize their profit – and they do it. This is, IMO, what makes them the new MS, and what drives Safari to be the new IE.
Posted by Barry Johnson on June 30, 2015 at 4:16 PM
Regarding the “conspiracy” aspect – in addition to the changed economics of the store today, thinking about app store revenue alone misses the second-order revenue (and margin) sources: selling apple developer certs and apple hardware (and the additional fees from licensed accessories, etc for said hardware) to developers, both of which are effectively required to produce apps for iOS.
Posted by Jay Maynard on June 30, 2015 at 6:08 PM
I’d cheerfully switch away from Safari on OS X if there was another browser that actually acted like an OS X application and failed to suck. Sadly, neither Chrome nor Firefox satisfy the former condition, and Firefox doesn’t satisfy the latter, either.
Fitting the OS application design rules is much more important to me than whether it supports the latest APIs.
If you want to improve Chrome uptake, get the OS X version to be a good OS X application.
Posted by Anonymous Coward on July 1, 2015 at 2:29 AM
You could always get rid of OSX altoghether … just saying: http://devopsreactions.tumblr.com/post/63903759786/shall-we-buy-macbooks-to-look-cool-but-install
On a more serious note, I don’t find OSX acceptable for heavy computer use. I find KDE a lot more usable and customizable – both usability and customizability being hard, measurable properties, not influenced by taste.
On yet another note: you can make KDE look and behave almost 100% like OSX. Only, you’re not limited to just that.
Posted by Jay Maynard on July 1, 2015 at 4:20 AM
I have a Linux system next to the Mac on my desktop. The problem with Linux, for me, is that I have to spend far more time fiddling with it than I do OS X; if you can customize it, you have to customize it.
My computer is there to get work done, not to give me something to fiddle with.
There’s also the simple problem that one tool I use a lot is Photoshop. I find the GIMP damned near unusable.
Posted by bgallia on July 1, 2015 at 5:34 PM
I don’t think anyone is advocating switching away from Safari. The days of websites having “optimized for Netscape” are behind us and hopefully will never come back.
Also, looking at the desktop browser usage across NetApplications, StatCounter and Wikimedia, Safari (as a desktop browser) only accounts for about 5%. Even if improvements on Mac OS X for Chrome and Firefox could convince 20% of those users to switch away from Safari, that changes things by only 1% in the desktop area.
This still doesn’t address the issue that when you also include mobile browser usage, then Safari’s use jumps to around 20%. It has already been brought up that Chome for iOS does not improve the problem since it is still using Apple’s rendering engine and javascript.
Advocating for W3C standards should reduce the need for another browser war, not create another one.
Posted by Madhu Rakhal Magar (@madhurakhal) on June 30, 2015 at 7:58 PM
Haha….. I don’t care about Safari…. I only care about Chrome and IE…
Posted by ekdikeo on June 30, 2015 at 11:05 PM
Webkit is circling the drain.
Posted by chad on June 30, 2015 at 11:22 PM
Meanwhile, I just did another round of personal tests, and Safari is both faster and much more power-efficient than Chrome or Firefox for me. It also has at least two important-to-me features those two don’t, but that’s secondary.
Posted by Jon Tseng on June 30, 2015 at 11:44 PM
@Harvey Lubin
I’ll let people draw their own concluisions…
Posted by Anonymous Coward on July 1, 2015 at 2:23 AM
Two things:
1) Apple is not a fruit company, it’s a fashion company
2) What do you expect, after the fashion company it became already at Jobs’ time was taken over by an accountant?
Posted by Amanda Downie (@aadownie) on July 1, 2015 at 5:55 AM
All I see with this post is one perspective. Being primarily a front-end dev, I’ve found that IE still lacks most of the support that I would like to see, while Safari has had very few problems with what shouldn’t even be “cutting edge” CSS anymore. I prefer using CSS over JS whenever possible, and found that a lot of effects such as clip-path, various filters, shapes/canvas effects I could pull off in Chrome, FF, and Safari without a hitch, but according to Caniuse even Edge doesn’t support these yet.
My point being, for those who read for the sake of a point and not finding something to attack, is it’s all a matter of perspective. Yes, for some things Safari may be behind. I had more problems with FF than I did Safari in my endeavors, for example. But for my purpose, IE still remains to be lagging behind the most, and causing me to find alternative heavier solutions.
Posted by Alastair Houghton (@al45tair) on July 1, 2015 at 8:38 AM
It’s perhaps notable that the example you cite, Service Workers, only works on Chrome and Opera. Not on IE, for instance. http://caniuse.com/#feat=serviceworkers
Certainly Chrome supports more than Safari, but I’m not sure that makes Safari the new IE.
Posted by bgallia on July 1, 2015 at 6:37 PM
If you check that page again carefully, you will find the following special note that “partial support can be enabled in Firefox with the dom.serviceWorkers.enabled flag.”
I don’t think the point of the article is if W3C standards work today as much as if they are on the roadmap for tomorrow. As such, it isn’t just about what appears on the pages of caniuse.com but also what appears on the following web page:
https://edgeconf.com/2015-london/schedule
Take note of the 10:25 panel on the serviceworker cache api where there is members from Google, IBM, Facebook, Squarespace and Mozilla.
But this isn’t about any single specific conference either. Apple just is not stepping up to the plate in any open forum on this. It also seems unlikely that Apple is saving this for the wow factor of announcing it at a future WWDC. And we shouldn’t reduce the set of W3C APIs that work across all major browsers (and for the mobile platform, Safari is very much a major browser) to only the APIs which can get a wow factor after uttering the words “one more thing.”
Some of the most important APIs seem boring at first glance. Can you imagine what the world would be like if the success of adoption of AJAX depended on if Apple decided it would produce enough “wow” at WWDC?! When the concept was first introduced, most developers I knew didn’t get it right away and were far from saying “wow” even when they did kind of get it. Now it is an expected part of “Web 2.0.”
While the title of the article may seem a little click-bait’ish, I think you are missing the point about what would make Safari the new IE. In the narrow scope of how the browser is revised, the responses (and lack of response) given by Safari’s official development team seem very similar to what web developers were used to hearing from the IE team.
It used to be Microsoft would include in regression testing a test of the Alexa top 500 visited websites. However, these tend to be websites that would be coded with IE users in mind. Hence, it became a circular environment where the top sites where only using what IE provided and IE developers used that as proof no future W3C standards where in actual use. Putting it another way, the question of if the chicken or the egg came first was transformed into the question of what came first of IE support or web developer use. The answer for top 500 sites was neither came first and new W3C standards were being ignored.
It is only recently with project Spartan and the Edge browser that IE developer suddenly claim “the tail of the web matters!” They then go on to explain what the tail is (sites outside of the Alexa top 500) and why it matters. I doubt I was the only one that felt like yelling “yeah duh, we been tell you that for years.”
But the philosophy of only providing or fixing things when the need comes about seems to be living on. Not at Microsoft but now at Apple. Having to explain to answer the impossible question of if the chicken or the egg should come first for yet another company with an unheard of amount of resources and wealth is taking place again. However, it is right to say the Safari is not the new IE. It is far worse than that. If Microsoft required Trident/MSHTML to be the only rendering engine on their own OS, the European Commission would have started issuing fines every single day. Apple is getting away with making a broken and out of date rendering the engine the only “option” for iOS.
I don’t think it is unfair to expect a company with a stock market value of $700 billion to do a little better.
Posted by Alastair Houghton (@al45tair) on July 2, 2015 at 10:44 AM
I’m sorry, but enabling a developer flag really doesn’t count here. You might as well say that someone could just use the WebKit nightly instead of Safari to get some new feature. All it tells us is that Mozilla is adding support for Service Workers to Firefox, but it isn’t there yet. We don’t know about Apple or Microsoft.
As for iOS, there’s nothing stopping you using a different rendering engine on iOS if that’s what you want to do. About the only objection is that you can’t use your own Javascript implementation if you want it to be fast, because of the restriction on executing data; but you can certainly use the JavascriptCore framework, which has pretty decent performance, and build on top of that.
Posted by bgallia on July 5, 2015 at 11:59 PM
Actually, I can’t think of any strong show of public interest in supporting W3C standards than to have already started implementing it. So, yes, enabling a developer flag does count here.
If you can provide a link to a nightly build of Safari which show the same level of commitment to future W3C standard, feel free to post it.
As far as the claim that “there’s nothing stopping you using a different regndering engine on iOS” there is still App Store Review Guideline 2.17 which states: “Apps that browse the web must use the iOS WebKit framework and WebKit Javascript.” That statement seems to clearly indicate they are stopping. If you have been able to publish an app to iOS (jailbreak does not count here) which uses it’s own HTML rendering engine, please provide a link to it as I would like to try your’s out.
Posted by Scott Wilson (@ScottWLovesYou) on July 1, 2015 at 8:44 AM
Apple needs to hire more engineers and less rappers and fashion designers.
Posted by Rhys Morgan on July 1, 2015 at 8:50 AM
Safari’s had push notifications for a long time.
Posted by Nolan Lawson on July 3, 2015 at 2:17 PM
They’re not the official spec, and they only work on Apple hardware: https://twitter.com/jaffathecake/status/615863799522832385
Posted by mp on July 1, 2015 at 10:18 AM
Safari is far from the new IE, it might be lagging behind the edge technology but it has NEVER been a virus and worm magnet like IE always was.
Harvey’s comment about Apple vs. Google open source, while true, is not relevant, since this was an article about browser technology, not tech in general.
Totally agree about OS X being the platform for getting work done vs. twiddling and fiddling.
Posted by Joakim Hedlund (@Sleavely) on July 7, 2015 at 7:45 AM
By that logic, Chrome and Firefox – both allowing extensions – are both worm magnets; they both allow custom extensions to be installed and to access your data on sites you visit. I don’t think it’s relevant to this discussion though, since the comparison is about the features they provide and how IE used to and Safari now causes headaches for developers.
I never cared much about the UI or security of IE, but I did care whether my standards-compliant code ran properly on it. The UI and security are merely reasons why I personally didn’t use IE, but that doesn’t mean my website visitors wont. Same thing goes for Safari – I like giving away my data to Google (dem clouds be cray), so I use Chrome, but I can relate to users who just want to browse the web without doing a survey to find the best and shiniest browser that suits their needs, and I will still attempt to cater to that audience assuming the browser they end up with isn’t a relic from darker times.
Posted by Safari the new IE? | Matt Mullenweg on July 1, 2015 at 11:28 AM
[…] “In recent years, Apple’s strategy towards the web can most charitably be described as ‘benevolent neglect.'” Nolan Lawson throws the gauntlet down by asking Is Safari the new Internet Explorer? […]
Posted by Mark Kelley on July 1, 2015 at 3:25 PM
Ya know, Apple might just be getting ready to reinvent the Web and wreck hackers in the process….. Just sayin…………..
Posted by Pilu on July 1, 2015 at 3:57 PM
The main problem lies elsewhere. Use of browser perse is dwindling at least here in countries of SE Asia like BD, India etc. More of next gen is using apps which being walled gardens sort of kills the concept of internet we knew with http and www. Some very large companies are becoming app only, and kids and youths no longer download WordPress or Joomla ( or Drupal) to make their own sites – many companies have only facebook pages and no www address. While there were movements like SOPA no one is trying to bring back the Browser itself – what can be done by Apps can be done by browser also. If Browser is not as nifty as apps it should be made so. But then the world enslaved by FB is not looking at all these. So first we need to resurrect the http, www and the Browser itself. It looks like a distant (if not impossible) dream
Posted by prafuitu on July 1, 2015 at 11:08 PM
What people tend to forget (or maybe didn’t even knew it in the first place) is that IE6 was one of the best, if not the best, browser of its time. It had the broadest support for CSS 2 (despite all the crazy bugs like double margin on floated elements) when launched, support for XHR, webfonts (EOT), CSS filters (through DirectX) and even custom elements. Hell, some of those were even available in IE 5. Yes, sure, they didn’t follow any standard but their owns, but that’s not much different than all the goodies WebKit offered with their prefixed CSS properties and non standard syntax that helped it take the lead in the web space…
So yeah, Safari had its moment, just like IE had, but right now it looks like a serious contender for the most dreaded browser “award”!
Posted by The Cost of Compatibility | spriteCloud on July 1, 2015 at 11:50 PM
[…] at spriteCloud, we discussed how Safari is the new IE, meaning that of the major browsers, Safari seems to lag further and further behind in providing an […]
Posted by ben on July 2, 2015 at 6:26 AM
any negative opinions expressed about safari should consider the fact that no other browser competes with it on an apple product. let’s benchmark yep… FF is overbloated, chrome just asks you to login to him. please guys c’mon
in the end, all you want to do is an iOS app, as it will run equally everywhere (sorry for android… but admit it, too many devices type kill the norm, making it maybe worst than the desktop browser world)
Posted by Kerby on July 6, 2015 at 2:46 AM
“too many devices type kill the norm”.
It’s called choice. I know it frightens most apple cult members buy some of use enjoy making a decision for ourselves.
Posted by Jay Maynard on July 6, 2015 at 4:20 AM
Fragmentation is a real thing. I have four Android devices, and there are more than a few apps that refuse to run on one or more – and the lowest Android version on any of them is 4.1.1.
The Android car stereo is a great thing, but I really wish the SiriusXM app would install and run on it…
Posted by Safari è il nuovo Internet Explorer? | Bicycle Mind on July 2, 2015 at 10:16 AM
[…] Safari è il nuovo Internet Explorer? […]
Posted by seb on July 2, 2015 at 2:52 PM
Safari is the new IE
OS X is the new Windows
Apple is the new Microsoft
LOL, so much bitter, hard to take these articles seriously.
Posted by Richard Boyle on July 2, 2015 at 5:55 PM
I use Mozilla’s Firefox instead of IE. It’s much better than IE once you get used to its particular differences. No complaints here.
Posted by Concerned Citizen on July 2, 2015 at 6:41 PM
I ran into this recently when building my own company website and using webkit within a standard WordPress theme:
.entry-header
{
display: -webkit-flex;
display: flex;
-webkit-flex-direction: row
flex-direction: row;
-webkit-justify-content: flex-start;
justify-content: flex-start;
flex-wrap: wrap;
}
.entry-title
{
order: 1;
}
.entry-thumbnail
{
order: 2;
margin-left: 25px;
}
.entry-meta {
order: 3;
}
.entry-header {
margin-bottom: 15px;
}
.single-post .entry-meta .date
{
display: none;
}
All of this works great in ALL browsers BUT Safari in iOS, OSX, and WIN. Disappointing for sure.
Posted by Mats Svensson on July 23, 2015 at 11:09 PM
WIN?
You still test things on Safari 5?
Posted by bfredit on July 3, 2015 at 12:56 AM
What happened to these comments? All the fanboyism and sheer ignorance of some people… are actual developers answering or just the kids from Xbox Live??
Posted by Mike on July 3, 2015 at 5:25 AM
Read This: http://www.imore.com/safari-isnt-new-ie-its-user-centric-web
Posted by Bruce Lawson’s personal site : Reading List on July 3, 2015 at 8:27 AM
[…] Safari is the new IE writes Nolan Lawson after Edge Conference: “we in the web community need to come to terms with the fact that Safari has become the new IE.” […]
Posted by Article Roundup - Hoverboard Studios on July 3, 2015 at 3:59 PM
[…] Safari is the new IE […]
Posted by Is Safari the new IE? | Rob Fahrni on July 4, 2015 at 11:02 AM
[…] Nolan Lawson: “It’s tempting to interpret this as a deliberate effort by Apple to sabotage any threats to their App Store business model, but a conspiracy seems unlikely, since that part of the business mostly breaks even. Another possibility is that they’re just responding to the demands of iOS developers, which largely amount to 1) more native APIs and 2) Swift, Swift, Swift. But since Apple is pretty good at keeping a lid on their internal process, it’s anyone’s guess.” […]
Posted by someone on July 4, 2015 at 11:26 AM
It’s a pity. RIP my old friend.
Posted by dtriny on July 4, 2015 at 4:46 PM
HTML has become a religion.
Posted by Steve on July 5, 2015 at 9:14 AM
So well written.
Posted by Safari is the new IE 2: Revenge of the Linkbait | Read the Tea Leaves on July 5, 2015 at 11:45 AM
[…] « Safari is the new IE […]
Posted by Safari è il nuovo Internet Explorer? | Edit - Il Blog di HTML.it on July 6, 2015 at 12:03 AM
[…] | Read the Tea Leaves_ajaxurl_ = "http://blog.html.it/wp-admin/admin-ajax.php";var tag = 'noalert';var […]
Posted by Bookmarks for July 5th from 09:05 to 22:44 : Extenuating Circumstances on July 6, 2015 at 1:01 AM
[…] Safari is the new IE – 30 Jun Posted June 30, 2015 by Nolan Lawson in Webapps. Tagged: apple, web platform. 126 Comments Last weekend I attended EdgeConf, a conference populated by… […]
Posted by Safari and the User Centric Web | Assorted Nerdery by Daniel Andrews on July 6, 2015 at 7:47 AM
[…] keeping up with this small-scale drama, Nolan Lawson wrote an article about a week ago about how Safari is falling behind other browser vendors. This led to a pretty large outcry from the Apple faithful (which, honestly, I typically consider […]
Posted by Apple and Safari | Chris Bateman on July 7, 2015 at 8:44 PM
[…] 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 […]
Posted by Church Tech Snack Pack #079 - ChurchMag on July 10, 2015 at 9:01 AM
[…] Safari is the new IE Yup. It’s true. […]
Posted by HTML5test - How well does your browser support HTML5? on July 11, 2015 at 6:41 AM
[…] 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 […]
Posted by Victor on July 25, 2015 at 7:07 PM
Why are we attacking the browsers and not the webpages. Modern website are a fucking mess. They scatter resources all over the web, and load up files form up to 10 sources instead of hosting everything on the same server as the website. Should we blame Microsoft for Word when trying to open a document filled with pictures, hyperlinks, inactive source files and loads of text effects?
Isn’t it better to teach (or force) coders to clean up their mess before publishing rather than have developers cope with everybody’s mistakes. I know it’s impossible to control the habits and knowledge of so many people, but when you see code that’s being made 5 times longer just to address an issue that could’ve been dealt with 2 lines, only if they did their research and kept up to date with changes and implementation, you start to think differently.
Posted by Browser Trends July 2015: Stalled Safari? on July 30, 2015 at 7:31 PM
[…] Lawson’s recent article “Safari is the new IE” had a contentious title but raises several interesting points. Apple hasn’t abandoned Safari […]
Posted by Le liens de dimanche – Disruption[s] on August 1, 2015 at 11:41 PM
[…] à documenter le problèmes et disparités des navigateurs sur le web. dans le débat — Safari est le nouveau IE [en train de retarder le développement sur le Web] — il propose que l’ensemble des […]
Posted by Safari isn't the new Internet Explorer, Google Chrome is. on August 7, 2015 at 5:15 AM
[…] have been discussions recently that badmouth Safari for being a bit behind on web technologies. I agree that Safari needs […]
Posted by The Evergreen Web - Scott Hanselman on August 10, 2015 at 11:53 PM
[…] needs to get on board (coughSafari) and move […]
Posted by How about we make ES6 the new baseline? | Christian Heilmann on August 17, 2015 at 12:59 AM
[…] This sounds familiar and brings back terrible memories of an Internet Explorer monoculture as explained by Nolan Lawson in Safari is the new IE. […]
Posted by Safari is Not the New IE, But... -Telerik Developer Network on August 19, 2015 at 4:11 AM
[…] the butt of the joke. And increasingly, with the popularity of articles like Nolan Lawson’s “Safari is the new IE”, developers’ new target is becoming Safari. As someone who speaks to a lot of web developers […]
Posted by That’s just not what “is the new” means · kbps on October 8, 2015 at 11:42 AM
[…] I’m the last and probably least significant person to weigh in on this, but this “Safari is the New IE” article that I didn’t read when it came out three months ago has been tucked away in the […]
Posted by Ankit Khatri on October 28, 2015 at 5:02 AM
Great Article! Web is the future and if Apple doesn’t implement the new APIs seriously, they will suck big time!
Anyways, but until Apple change their strategies, I would go with your points 2 and 3 based on what I am developing.
If its a small internal tool for an intra-company purpose, I would go with 2. with a label, “Not Compatible with the f**ked up Safari shit.”
If its an open source library like PouchDB, obviously, I have no option but 3. I will try my two cents to contribute and may be the lazy guys at Apple will wake up to see it.
Posted by Cloudane on November 3, 2015 at 1:22 AM
I agree with you for different but related reasons, having come here as a user on a slightly frustrated Google of “Safari is worse than IE6”
Okay, that’s exaggerating a bit.
But it’s becoming more and more frequent now that I come across a website that just doesn’t work properly on Safari. Menus that don’t respond, entire sites that don’t appear, sites that think the desktop version is a mobile browser and so on. I keep thinking of ranting about this and predicting the backlash of “everything works for me! You must just go on bad sites!” and deciding against it. I keep thinking “it must be a one off, badly designed site” and coming across another one that does something broken on it. Time and time again I find myself breaking out Firefox or Chrome as a “one off” to get something working.
I’m a long time user of Apple products and want to use it – in an ideal world I’d use everything of these since it all integrates so well. It syncs perfectly with the mobile version and iCloud, is battery efficient on my laptop etc. But it seems to me that Safari has now (since around Yosemite) adopted the old IE6 crown of “special snowflake browser that web developers have to test individually and code in workarounds for, and if they don’t it’ll probably be broken”.
To be honest this “it almost works, but I need third party software so I can do x” is becoming commonplace on the Mac now. Photos is almost suitable for my needs (RIP Aperture) but not quite, so I have to use Lightroom. iCloud Numbers almost has what I need but is painfully slow to sync and doesn’t have trend lines on graphs, so I have to use Google Sheets. Shortcomings… shortcomings everywhere! They fix ONE shortcoming per year (to a great cheer and applause from the crowd at WWDC) then that’s your lot, come back next year. Once a piece of software is finally feature-complete and everyone loves it, they scrap it and rewrite it from scratch and it’s back to square 1 with another 10 years of re-adding missing features, rinse and repeat over and over. Anyway, I’m getting on a tangent. Getting a bit jaded with Apple – fortunately for them they’re still the best at certain perks that keep me using them, like being able to type text messages in the OS and send them through the phone (VERY useful).
Posted by 10 Web Predictions for 2016 on January 6, 2016 at 3:15 PM
[…] I don’t necessarily agree Safari is the new IE, it’s fallen noticeably behind other browsers — including those from […]
Posted by Forever Backwards Compatible on February 3, 2016 at 8:58 AM
[…] all the talk about the web not evolving fast enough to catch native UIs, the silver lining is that the web will transcend generations of devices and […]
Posted by chatterkat on March 5, 2016 at 6:26 PM
safari really IS worse than IE in a lot of aspects. I am constantly finding CSS cross browser issues, an important form part on the UPS website does even work at all in safari.
dealing with safari is a damn nightmare all around. i really hope everyone abandons this useless browser.
i am too the point if a browser just can not stay current with development, and standards, and just too many cross browser issues popping up then i really no longer care. my opinion is stop worrying about them, let these junk browsers FADE AWAY..
when no websites will work on them, then people will stop using – or the developers will be forced to do something
Posted by marco on April 19, 2016 at 4:29 AM
My words echo to the title of this blog post, totally agree?
Posted by File Upload Regression in Safari for iOS | vcolavin on May 19, 2016 at 2:15 PM
[…] does a great job of implementing and supporting modern web standards. I don’t buy into the Safari is the new IE thing. Also, a friend of mine works on that team and I don’t want to malign […]
Posted by Why I’m Not Crazy for Making Safari my Default Browser – BirchTree on July 8, 2016 at 7:30 AM
[…] you’ll say. It’s faster, you’ll say. You might get a little snarky and tell me Safari’s the new IE. If you want to appeal to my developer side, you’ll probably tell me that Chrome’s […]
Posted by Jēkabs Kārkliņš (@cyberprodigy) on August 14, 2016 at 2:43 AM
I can tell you for sure that 7 years ago while doing web development you always needed to make tricks and special solutions for IE 6.
These days doing responsive websites no one cares about IE6, however it’s place has been taken by iPhone 4/4S Safari browsers. Many people has it, so you are forced to hack your solutions though.
Posted by John on September 10, 2016 at 7:37 AM
I don’t get Safari either? It used to be so aggressive in gaining user traction. Even going so far as to port to Windows OS. But of late, it seems overly focused on mobile web with the iPhone and that’s it. Even most stuff pertaining to OS X now Mac OS is directly linked to working better with mobile. It’s as if the Mac is a after thought or rather a accessory to the iPhone. It’s probably why Mac users don’t use Safari but Chrome. Safari’s only success is mobile because IOS forces any browser to use the Safari engine. Yeah you think your using Chrome but it’s really Safari. I didn’t think Safari would end up being ignored by Apple like Microsoft did to IE. But it sure looks that way to me.
Posted by Martijn van Halen on January 9, 2017 at 9:49 AM
Funny how almost nothing has changed. Each iOS release we hope for changes. But what is happening now is that Android is the bigger part of the market now. So option 2 makes way more sense now. So hopefully Apple will learn and change
Posted by bgallia on January 9, 2017 at 7:07 PM
I disagree that option 2 make more sense now. I think who is to blame for lack of Service Workers adoption has changed since this article was written. Also, because of that you need to re-evaluate how to respond.
Back around at the end of June 2015, the W3C had just released the working draft for Service Workers. It seem clear at the time the W3C Web Applications Working Group had a clear roadmap for moving forward with the specification and that Google, Mozilla Foundation and Microsoft all had expressed interest in how the specification could fit into their roadmap. Apple, at the time, seem like the clear hold-out from discussing the future of Service Workers on their carefully wall gardened platform.
But the road map issues seem to extend beyond Apple today. Coding to stick it to Apple for still not supporting what remains a working draft seems to ignore the fact it’s adoption is a larger industry issue than just Apple at this point.
First, there is the road map for the W3C itself. The Web Applications Work Group in the W3C which had been working on the specification closed in October 2015. The group that now is supposed to be progressing with the specification is the Web Platform Working Group (WPWG) which seems to be looking over everything from HTML 5.2 to Gamepad API to DOM UI Events. It seems like the WPWG has a lot on it’s plate. For Service Workers, WPWG was targeting a Candidate Recommendation specification following TPAC 2016. But, TPAC 2016 came and went back in September 2016 so it seems unclear what the ETA for the WPWG for a CR version of Service Workers will be.
However, even if a CR specification where to come out today, there is product lifecycle issues from both Microsoft and Google which will impact how quickly the CR specification is supported by the default OS rendering library.
For Microsoft, Windows 8.1 is listed as still being in mainstream support for another year. Microsoft has stated that mainstream support includes additional features to keep the product current. However, Microsoft then has made it clear that applications that use the mshtml.dll on Windows 8.1 will never have Service Workers support and neither will IE.
Android WebView library didn’t support Service Workers WD until Android L (Lollipop). According to Google’s own statistics, 39% of Android device still in active use have a version of Android previous to Lollipop. This is largely due to the fact that several devices only 18-24 months old can’t be updated to the latest version of Android. Hence, it seems like it will be another year before over 80% of Android devices will have a WebView that support Service Workers or at least the Working Draft version of them. If the CR comes out today, it probably won’t be until Android O is released that support for Service Workers CR is baked into the firmware which provides WebView. It may then be another three years from now until over 80% of actively used Android devices support the Services Workers CR.
So, while Apple seems to still not support the Working Draft, if the CR came out today and Apple decided the next versions of Mac OS X and iOS will support the CR specification, the life cycle Apple provides seems to indicate they will have the largest percentage of their user base that will get updated to have that support. Currently, Macs built since 2010 can be updated to the latest Mac OS X and iPhones since fall of 2012 can be updated to the latest iOS.
So, I think the focus today should be less on why Apple still doesn’t support a working draft and more one why the W3C still doesn’t have a Candidate Recommendation. Then the next concern should be, how soon will the CR specification be available on all of your target platforms.
But taking Option 2 to try to force Apple’s hand doesn’t seem like the right next step. I don’t think it is as clear that Apple is the weak link in this specific area.
Posted by Safari and IE – Hello my name is Niels Leenheer on October 23, 2017 at 12:18 PM
[…] 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 […]
Posted by Things I’ve been wrong about, things I’ve been right about | Read the Tea Leaves on January 1, 2019 at 3:45 PM
[…] “Safari is the new IE” is probably my most-read post of all time, since it got picked up by Ars Technica. Unfortunately I’ve learned a lot about how the browser industry works since I wrote it, and nowadays I regard it with a bit of embarrassment. […]
Posted by Reminder: Safari is not an evergreen browser - Jeffery To on July 10, 2019 at 3:25 PM
[…] brings us to Safari. I am nowhere near the first person to say that Safari is the new IE, but consider this: Out of all of the major browsers (Firefox, Chrome, and let’s include Edge […]
Posted by Is Safari the next Internet Explorer? - LogRocket Blog on December 23, 2020 at 6:00 AM
[…] IE is very close to becoming a relic of internet history, some people have claimed that Safari is the new IE. Let’s consider the similarities and differences between the IE and Safari situations to see how […]
Posted by Browser Trends July 2015: Stalled Safari? — SitePoint on December 15, 2023 at 1:30 AM
[…] Lawson’s recent article “Safari is the new IE” had a contentious title but raises several interesting points. Apple hasn’t abandoned Safari […]
Posted by 10 Web Predictions for 2016 — SitePoint on December 19, 2023 at 11:31 AM
[…] I don’t necessarily agree Safari is the new IE, it’s fallen noticeably behind other browsers — including those from […]
Posted by An Abridged History of Safari Showstoppers - Webventures on October 8, 2024 at 12:41 PM
[…] the major IndexedDB wrappers, all ignore Safari's version and fall back to WebSQL.)Nolan Lawson, Safari is the new IE, […]