It's more of an extension to the cache philosophy. Service Workers let you handle caches more directly and describe what your site looks like when you have no internet at all. In a lot of cases that doesn't really make sense, but if you have some critical content that all your users need, even offline, you can make sure it's always there. You could also do stuff like: prevent all images from loading unless the user requests them, show a handy offline page (instead of the dinosaur), and importantly if you're using the app shell model, users can seamlessly pin your site to their homescreen, providing a very app-like feel (splash screen, no browser url bar, first-class switcher status).

This is also a particularly big deal in countries where wifi and LTE are less prevalent, or where users regularly switch to airplane mode to conserve data. According to Tal Oppenheimer's talk [0] at the recent Chrome Dev Summit, an hour of minimum-wage work in India would pay for about fifteen web pages' worth of data cap. In that regard, being aggressive in how and what you cache makes a lot of sense.

0: https://developer.chrome.com/devsummit/sessions/emerging

It is basically reinventing caching but correctly, caching at the http layer does not handle updates properly, preloads very well at all and is entirely unreliable.

For example load http://pouchdb.com/, first page load may be a little slow but the rest will be very fast aside from the api page which has some slow JS (if the rest of the pages didnt load instantaneously we would probably never notice how JS slows that page). Turn your internet connection off while you browse, its all fine.

The above is using AppCache, but a big part of ServiceWorkers is learning from the AppCache mistakes and having a more flexible / powerful framework for them.

Why is caching at the HTTP layer unreliable? With cache-busting URLs I've had no problems at all.

Turn your internet connection off and try to reload this page, or even with your internet connection on look at how many pointless http requests are made that slow the page down on every reload.

HTTP Caching does not have explicit guarantees about the availability of things in its cache, ServiceWorkers and AppCache do.

Why is having the shell being able to load offline when the XHR'd content won't be able to load a plus? It makes sense for productivity apps like Google Docs, where you're writing the content, but not for a majority of apps.

I'm tired of web 2.0 ajax sites where you scroll through content, click a link, then you try to go back, and you have to scroll through the same things you didn't care about again. Or in Facebook newsfeed's case even reorders things.

It honestly feels like "Ooh look at this shiny new tech. Let's use it! Why? Because we need to improve 'usability'! proceed to throw other usability concerns into the trashcan"

Imagine an RSS reader (which Facebook, Twitter, etc. basically are.) 99% of the time, an RSS reader doesn't need internet connectivity; it just has a database of synced feed-items and you can peruse them. When you pull-to-refresh it, it goes online and actually retrieves updates for its feeds, then (crucially) finishes and is now offline again.

There's no reason such an app can't be implemented as a plain-old-webapp pinned to your iOS springboard or whatever else. You open it, you get RSS items. You try to refresh, it says "no internet, sorry", and the refresh is cancelled. Every other part of the functionality continues to work just fine.

There's actually something that does exactly this: visiting the Gmail website on iOS will build a local database of your mail, and let you continue to interact with it, search through it, write emails and "send" them (they stay in your outbox) when you don't have internet connectivity.

It might help to think of this paradigm as "streaming apps". Instead of downloading apps and having them on your home screen, you go to a URL and it behaves like any other app--it will render its own app shell and then say "Sorry, can't get content. Check network connection".

This is not true. 1) When devtools are opened in chrome - caches are disabled by default 2) Even when requesting to server - chrome show it as request 3) Manifests works like a charm. You can open app completely offline. For example, you can check telegram web app (our project disabled this feature during development). 4) Manifests easily handle updates of web apps - just re-requesting manifest once 20 min +

This doesn't reinvent HTTP caching: you should still set far-future expires headers on your JS and CSS. What HTTP caching doesn't solve for is caching markup in dynamic pages: HTTP caching is entire-file or nothing.

With Service Workers you can cache the static parts of your templates (e.g the UI chrome) and render them immediately via JS rather than waiting for the initial document load. You then grab the rest of the dynamic content via an AJAX call. This leads to improved perceived performance, since you can immediately begin painting rather than showing a blank screen waiting for the document load.

Even with great HTTP caching, skipping the initial document load will always be faster (assuming that the document is dynamic, and thus can't be cached via HTTP caching). For plain static pages, of course, the existing web works super well, since that's what it was designed for.

I don't think it's quite the same. As you point out CSS and JS are cached for a long time, such that the browser doesn't even have to make a request.

My understanding of this "application shell" is that even the HTML response is given a cacheable / far-future expiration header.

Is that even possible? It would be cool, if so. If you type "foo.com" in your address bar, could your browser say "ah, I've already got this response cached, here you go, here's your HTML, CSS, and JS"? That would literally be an instantaneous load with no network round trip at all. Then the JS could kick in and fill in the shell with whatever the actual dynamic content is.

That's different from a normal webpage which just caches the assets, since it still has to make a full request to get the HTML. Especially on phones, even if the response is small in size, the latency of the request/response cycle can be somewhat long (almost a second).

Edit: After further playing around with app-shell.appspot.com and your site, I see where you're coming from. Both of them respond to a refresh in <10ms (my browser takes the content from the cache). app-shell loads from the web worker, your page loads from the browser's cache (why? It has a no-cache header).

However, I guess the difference is the app-shell one is able to load dynamic content into its shell, even with the instantaneous from-cache load of the outer shell. I think the perceived performance will be about the same (since the browser paints the shell immediately), but it is able to be dynamic.

Yes and no. The key here is that it isn't a webpage, it's a webapp. So it can do things like preload resources that aren't used in the current page but will be used in the next screen. And preload the HTML for those screens.

You can do that with HTTP too, check out the cache manifest.

I know. This is an extension of that idea into something that isn't awful.

Cache manifest has been deprecated in favor of app cache

The cache manifest is part of app cache.

I didn't see anything slow. I middle clicked your link, went to change tabs, by the time I had done that the page had already loaded. If you are making that slower with javascript and third-party servers then yu are doing it wrong.

That's my point, that you can already serve your CSS and JS when the user first accesses your site and then just deliver the content, which should be minimal.

I think you have an excellent point. Don't see the point of the original article.