This process makes a <i>ton</i> of sense, once you start thinking of websites as online applications (and not just a bunch of page content, but even then sometimes it's worth thinking about page content as an application). It's also surprisingly simple, given the tooling that's already provided by the browser and the sw-precache and sw-toolbox libraries.<p>I only wish there were some roadmap to see this on the iOS side. I get that android has a lot of market share, especially in developing (slow 3g / 2g network) countries, so this is still a great idea (and totally worth the effort, given the payoff). But if there was some word from apple that this was feasible in the near future, I wouldn't be worrying about writing a native iOS app, or figuring out how to use cordova to deploy a hybrid webview app.<p>And that's why I somehow doubt apple is in a hurry to get this working on iOS. Watching the service worker presentations at the recent chrome summit, I couldn't help but think, "wow, app-like behaviors, straight from a webpage, pinned to the home screen".
Perceived performance (showing something) is more important to users than the ultimate load time. So prioritizing your assets so the critical stuff loads first is a good strategy. Keep in mind that JavaScript blocks rendering, so you want to make sure that you're still delivering the CSS and primary HTML content first. I don't want to wait for your massive JavaScript library to load and execute before I can read the text on the page.
Isn't this just reinventing webpages? You're supposed to cache the CSS and JS for a <i>long</i> time and then deliver minimal content to style. Have a look at my blog:<p><a href="http://www.stavros.io/" rel="nofollow">http://www.stavros.io/</a><p>The first load should be moderately slow (still, only about two seconds), and any subsequent load of one of the posts should be near-instantaneous.
It's really great to see that Android (and Firefox OS obviously) is going this way. Maybe soon we can forget the native apps (that remind me of the multimedia CD ROM era from 1995) for a lot of apps that do not need access to the system's API.
I am pretty excited about the idea of having a web framework that works equally well in service workers and nodejs, so the first page load serves up nice full html and subsequent page loads are handled by service workers and render immediately on the client side. Its pretty much the dream since I started working on PouchDB since this whole idea is made vastly easier when your data api is identical local and remote.
I think this would dovetail well with the strategy of keeping user data out of URLs by having generic pages and then xhr'ing to fill in the data reactively. (There is probably a nifty marketing name for that strategy but I don't know it.)