6 ms·

Instant Loading Web Apps with an Application Shell Architecture

111 points by aleem 11y ago

daleharvey 11y ago
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.
jarnix 11y ago
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.
- pikzen 11y ago
  Let's get web apps' APIs up to par with native APIs first, then maybe we can talk. Oh, and let's get it up to par performance wise. Because right now, in both those categories, web apps are terrible. Until then, I'll keep my native apps thank you very much. (And I didn't even start on Javascript, because you can transpile. But the itch is present :^))
  - ashark 11y ago
    Especially stop Web/JS stuff from chewing through battery and shoving everything else on the device out of RAM. If you expect users to be in your "app" more than a couple minutes a day (and it is in fact an app, and not just information presentation), please use native.
- Joeri 11y ago
  The problem of web apps on mobile is not that they don't work offline. They've worked offline for years with appcache. The problem is three-fold: (1) performance is bad and not improving, especially (and paradoxically) on android, (2) lack of native controls produces an inferior ux and (3) you can't store more than 50 mb of data on iOS. I was gung-ho on the mobile web as app platform and was sure that it would beat out native on mobile as it did on the desktop, but the situation is different. Web apps have a worse install experience on mobile, taking away much of the reason to build for the web, and because there can't be competing browsers there is no competition between browser makers to improve the mobile web, keeping it in a pretty lousy place.
pfooti 11y ago
This process makes a ton 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. 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. 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".
- untog 11y ago
  I only wish there were some roadmap to see this on the iOS side. Yep. Actually, I'd love to see Microsoft aggressively adopting this for Windows Phone - it has a real lack of apps, and this could help. For the rest (i.e. the vast majority) of us that don't use Windows Phone, it would still be great to have another major player adopting it, and highlighting that iOS is the only platform left that doesn't adopt it.
  - rchaud 11y ago
    Mozilla has definitely been pushing these technologies, partially to support content development for Firefox OS.
- Joeri 11y ago
  AppCache works just fine on iOS. I know it's a bit of a pain, but i have used it to build offline web apps before and it does work reliably when used correctly.
StavrosK 11y ago
Isn't this just reinventing webpages? You're supposed to cache the CSS and JS for a long time and then deliver minimal content to style. Have a look at my blog: http://www.stavros.io/ http://www.stavros.io/ 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.
- vilmosi 11y ago
  I think you have an excellent point. Don't see the point of the original article.
- daleharvey 11y ago
  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/ 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.
  - StavrosK 11y ago
    Why is caching at the HTTP layer unreliable? With cache-busting URLs I've had no problems at all.
    - daleharvey 11y ago
      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.
joshfraser 11y ago
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.
jessaustin 11y ago
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.)
OldSchoolJohnny 11y ago
Once again Apple is the holdout. They seem to be bent on making web apps a substandard type of app by dragging their feet on html 5 in general.

111 points by aleem 11y ago

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.

jarnix 11y ago

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.

pikzen 11y ago
Let's get web apps' APIs up to par with native APIs first, then maybe we can talk. Oh, and let's get it up to par performance wise. Because right now, in both those categories, web apps are terrible. Until then, I'll keep my native apps thank you very much. (And I didn't even start on Javascript, because you can transpile. But the itch is present :^))
- ashark 11y ago
  Especially stop Web/JS stuff from chewing through battery and shoving everything else on the device out of RAM. If you expect users to be in your "app" more than a couple minutes a day (and it is in fact an app, and not just information presentation), please use native.
Joeri 11y ago
The problem of web apps on mobile is not that they don't work offline. They've worked offline for years with appcache. The problem is three-fold: (1) performance is bad and not improving, especially (and paradoxically) on android, (2) lack of native controls produces an inferior ux and (3) you can't store more than 50 mb of data on iOS. I was gung-ho on the mobile web as app platform and was sure that it would beat out native on mobile as it did on the desktop, but the situation is different. Web apps have a worse install experience on mobile, taking away much of the reason to build for the web, and because there can't be competing browsers there is no competition between browser makers to improve the mobile web, keeping it in a pretty lousy place.

pfooti 11y ago

This process makes a ton 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. 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. 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".

untog 11y ago
I only wish there were some roadmap to see this on the iOS side. Yep. Actually, I'd love to see Microsoft aggressively adopting this for Windows Phone - it has a real lack of apps, and this could help. For the rest (i.e. the vast majority) of us that don't use Windows Phone, it would still be great to have another major player adopting it, and highlighting that iOS is the only platform left that doesn't adopt it.
- rchaud 11y ago
  Mozilla has definitely been pushing these technologies, partially to support content development for Firefox OS.
Joeri 11y ago
AppCache works just fine on iOS. I know it's a bit of a pain, but i have used it to build offline web apps before and it does work reliably when used correctly.

StavrosK 11y ago

Isn't this just reinventing webpages? You're supposed to cache the CSS and JS for a long time and then deliver minimal content to style. Have a look at my blog: http://www.stavros.io/ http://www.stavros.io/ 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.

vilmosi 11y ago
I think you have an excellent point. Don't see the point of the original article.
daleharvey 11y ago
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/ 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.
- StavrosK 11y ago
  Why is caching at the HTTP layer unreliable? With cache-busting URLs I've had no problems at all.
  - daleharvey 11y ago
    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.

joshfraser 11y ago

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.

jessaustin 11y ago

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.)

OldSchoolJohnny 11y ago

Once again Apple is the holdout. They seem to be bent on making web apps a substandard type of app by dragging their feet on html 5 in general.