Instant Loading Web Apps with an Application Shell Architecture | Hacker News Reader

Instant Loading Web Apps with an Application Shell Architecture

medium.com

111 pointsaleem31 comments

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

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.

Mozilla has definitely been pushing these technologies, partially to support content development for Firefox OS.

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.

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 long time and then deliver minimal content to style. Have a look at my blog:

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.

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.

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.

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 :^))

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.

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.

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.

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

Reply on news.ycombinator.com