>[...] could do their work even after the page is closed, provided the user has given permission.
I'm really glad for the second half of that statement.
While I could imagine a few use cases, the last thing I want on my smartphone are arbitrary bloated sites draining my battery after closing them. I even consider it a feature of websites vs. native apps.
Service Workers are what Application Cache should have been first. Application Cache has a big flaw and that is, you can't control it much. You depend on browser to decide what to do when there is no Internet connection. With Service Workers you get to programmatically tell browser what to do with network requests and so on.
Classic configuration file vs. let me write actual code approach. I'm glad we have both now! Application Cache makes sense for a lot of static websites.
I tried playing with Application Cache, but my applications kept getting "stuck." The user would return online and the old version of the application would be shown and it wouldn't update the one cached either...
Only solutions I found required configuring the web-server. Which is fine in theory, but when you consider that an application is a self-contained blob of static data in this context (i.e. HTML, CSS, JS, and a manifest) you'll potentially need one web-server cache policy for legitimately static content (i.e. HTML with no manifest) and another for Application Cache (i.e. HTML with a manifest) just to make sure the Application Cache is flushed correctly.
I find it very telling Google web-pages don't use Application Cache (e.g. Gmail). In fact the only thing in chrome://appcache-internals/ is the new-tab page.
Perhaps I'm mistaken, but I recall that there is a way to tell the browser to 'flush' the application cache, but only once the user has loaded the old version of the application anyway; in other words, you can tell the browser that the next time they load the page, they should load the new version. Which seems odd.
The only way to force a reset is to query the manifest and receive a status not equal to 200. If your application is stuck to an old version, this is the only way to update it.
And Firefox is considering the manifest as a normal cache so you need to put a lot of http headers to prevent any normal cache otherwise Firefox will never check any updates.
While what the Financial Times has done with polyfills is pretty neat, it at least does not document any of the behavior mentioned in this article.
In fact, it seems very clear that they are making use of App Cache for their website, which the technology mentioned in this article effectively replaces.
They're related in the sense that service workers will replace some of the functionality that the app cache provides. The FT's work has to use hacks like iframes with app caches to gain greater control over caching - so it's not a polyfill of service workers, just a halfway ground between what app cache provides, and a small section of the functionality service workers will provide.
Polyfills emulate service workers as they were not actually implemented in any browser. So they have to fall back on App Cache. But now they can seamlessly use Chrome's native service workers while still relying on polyfills for other browsers.
Emulating service worker with App Cache sounds... very hard. Do you have more info on this specifically? I've got an app that's using app cache now and I'd like to gracefully transition it to using service workers as they become available.
It's possible I misunderstood it then. I was at a talk by an FT engineer. Here's his course that he referenced in his talk: https://github.com/matthew-andrews/workshop-making-it-work-o....
You're right that maybe he was talking about what it is possible not what they did.
I'm really glad for the second half of that statement.
While I could imagine a few use cases, the last thing I want on my smartphone are arbitrary bloated sites draining my battery after closing them. I even consider it a feature of websites vs. native apps.