
Instant Loading Web Apps with an Application Shell Architecture - aleem
https://medium.com/@addyosmani/instant-loading-web-apps-with-an-application-shell-architecture-7c0c2f10c73#.anv85ievd
======
pfooti
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
_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
Mozilla has definitely been pushing these technologies, partially to support
content development for Firefox OS.

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

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

~~~
daleharvey
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
Why is caching at the HTTP layer unreliable? With cache-busting URLs I've had
no problems at all.

~~~
daleharvey
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.

~~~
bsuh
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_ "

~~~
derefr
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.

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

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

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

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

