Until they come around, all iOS users are without service workers, because Chrome on iOS is backed by WKWebView [1]. AFAIK, any custom browser on iOS is required to use WKWebView.
> Never use the application cache (or service workers) unless you actually need offline features.
I disagree. Appcache is deprecated and you should never use it under any circumstances. On the other hand, service workers are cool and there are reasons to use them even if you don't need offline features.
Safari does not support Service Workers AT ALL, so not using AppCache effectively kills offline support for iOS (source: https://jakearchibald.github.io/isserviceworkerready/). Also, according to http://caniuse.com/#feat=serviceworkers, IE/Edge as well as Safari Desktop and Android 4.x do not support AppCache (compared to near-universal support for AppCache, http://caniuse.com/#feat=offline-apps). This means: use AppCache or lose offline on anything that's not FF/Chrome (on desktops, offline doesn't even matter that much!) or the newest Android.
Also, the Service Worker API just plainly sucks when compared with AppCache Manifests. It's a real pity that AC is going down the drain.
Since when is only testing in Chrome an acceptable way to develop web applications?
I wish the author had shown us some other browser results. I'm curious if the iframe changes affected Safari, Firefox, or Edge. (Others have noted that app cache is deprecated).
Lots of folks here like to compare Chrome's dominance with that of IE6 back in the day.
Unlike Chrome, IE6 was never popular because of merit. Unlike Chrome, IE6 held back progress on the web - Chrome is still pushing it forward. Until that changes, can we quit with this tired comparison?
Is its a point of view only in people that are to young to have lived the debacle of IE6 years ? Or do some senor devs actually think testing in chrome only is ok ? Cause I read it more and more, and I find it very alarming. If this becomes a trend, we are going to live in pain all over again.
> If this becomes a trend, we are going to live in pain all over again.
It's painfully obvious that we're heading that way.
In a way Safari[0] and Apple's tight-fisted control on iOS is a blessing because no matter how much developers gripe about Mobile Safari (for plenty of good reasons mind) they damn well have to test the sucker.
[0] despite being "the new IE" to people who have no understanding of what it actually was and why it was a problem.
I wonder how much that is distorted by the aggressive preloading that chrome does and by android (since testing chrome on desktop and mobile is not really the same thing)?
This article just displays the author's lack of knowledge of the subject matter he is developing with. Something tells me it was written just to get the company's name out there.
Did you know you can use Firefox Developer Tools to remotely debug mobile Chrome? It's still in heavy development, but I'm guessing it's easier than trying to quiesce browser activity and tease out network events manually. https://developer.mozilla.org/en-US/docs/Tools/Valence
Yeah I missed this completely as well. Two requests for each resource because of the two iframes ("main" and "fullscreen")? It seems to me there's a huge logical leap between "..we were unknowingly downloading much more content than was necessary" and the next paragraph - probably just my unfamiliarity with webdev.
In the image on the article, you'll see that I pointed at a duplicate loading of fullscreen.css. If appcache weren't loading this in parallel, it would only be loaded once (by the fullscreen iframe).
I noticed the duplicate downloads. After all, they're the entire premise behind the investigation. But why does appcache download already requested assets?
That it causes duplicate requests, and apparently more of them in chrome mobile than other browsers, is interesting though.