offline for web - frontend dev conf minsk 2014

Of!ine for web

Jan JongboomFrontend Dev Conf 2014

@janjongboomJan, live in Amsterdam. Work for Telenor. Owns part of Vimpelcom. They pay me to work on Firefox OS.

Internet is normal for western world, but big part of the world doesnt have it.

Click Only 2.5 billion people out of 7.

4,500,000,000

Internet is normal for western world, but big part of the world doesnt have it.

Click Only 2.5 billion people out of 7.

4.5 billion people, all on mobileThese people are going to come online on mobile

Don’t break their experience!

Mobile users don’t always have an internet connection! Don’t break their experience, build with offline in mind!

37%Western world, last year. Netherlands already 37% of all traffic is mobile. Will only increase. It’s ALREADY an issue!

Оффлайн важна!

For years we have been developing with online in our heads, but we should stop treating like offline is still a second class citizen

Let’s do it!Let’s do something about it!

Currency converter BYR -> EUR. Price of a beer.- It’s a website. Resources are on a server.- Data comes from Yahoo

When no internet connection -> breaks. Oh noes. We want to fix it.

The shellApp content

Let me introduce some basic concepts here. An application consists of two parts:

1. The shell2. App Content

The shell

• All assets

• Distribution through:

• App store

• Publish on web server

• Changes are costly

The shell are all assets that make up your application. Code files, the user interface, images. It's the part that you would distribute through an app store, or the application that you put up on a web server. The shell hardly changes, and if you want to make a change it's a costly one. You would need to re-release your product.

App content

• Everything your app serves up

• Pushed down from server

• Highly volatile

• Changes are cheap

The app content is everything your app serves up. News items; the facebook feed. Most of the times it's pushed down to the client via HTTP requests, it's generally short lived and very cheap to update.

Ergo: We need to distinguish between these two types is because they require different caching strategies and techniques, but you can't make an application available without either of these two.

Part I: The shell

So we have a website, it has HTML/CSS/JS and now we want to cache it. There is a technique called appcache. Already in all major browsers, even IE. So you can use it today.

List all !les, put them in cacheBasically, list all files & put them in the cache.

AppCacheFirst request

Grabbing jan.com/index.html

manifest.appcache

On first request it looks like this. Browser fetches your HTML page. If it has appcache, it fetches that file and loads all resources. No initial performance penalty.

AppCacheFirst request


Please cache all these !les manifest.appcache

On first request it looks like this. Browser fetches your HTML page. If it has appcache, it fetches that file and loads all resources. No initial performance penalty.

AppCache2nd request

I need foo/blah

Browser Cache

Second request, if the requested file is already in appcache? OK! No waiting time anymore. If not, go to server.

AppCache2nd request

I need foo/blah

200 OK! Browser Cache

Second request, if the requested file is already in appcache? OK! No waiting time anymore. If not, go to server.

Writing AppCache !leStore as currency.appcache

Appcache is a file on your server. Very easy.

Tell the browser there is a cache file with attribute

currency.appcache

JavaScript !le

Browser will ALWAYS show cached version. Updates go by updating the version number in the manifest. Downloads in background.

Javascript APIs available, downloading/progress/noupdate.

Inspecting AppCache (FF)Tools > Developer > Developer Toolbar

appcache list localhost

Dealing with appcache info, to debug

Inspecting AppCache (FF)Tools > Developer > Developer Toolbar

appcache clear

appcache validate http://your.appcache

http://your.appcache

http://your.appcache

Inspecting AppCache (Chrome)chrome://appcache-internals/

Chrome has a similar thing under chrome://appcache-internals

Shit you will do wrong

• Setting wrong MIME type

• Have one !le 404

• Not realizing user will always see old version !rst

• Expiration headers on appcache

• Develop with appcache enabled(tip: set wrong MIME type in dev)

Some stuff you will do wrong

PerformanceAlso useful for performance. Because no need to hit the server. This is data from a web application I built. Pretty simple.

1500 msEmpty cache

On my home internet connection (60 Mbit, 105 ms. ping to the server) this page renders (including executing all javascript):

And that's on a very simple page that is already highly optimized. As we all know, **speed** is the most important aspect of a web page. Having tools to increase the speed of already highly optimized pages by 250% is insane.

820 msSubsequent reload



320 msReload with appcache



250% speed bumpNot just for of"ine

Part II: App contentWe talked about the shell, but what’s equally important is what the shell contains

App content, comes from server. This is calculated using the textbox and data from a server that has currency exchange data.

A simple AJAX request

This is how I get the data from the server (simple AJAX request)

We can store the result in localStorage. key/value store. If no internet, get data from LS.

Something in between to shake up the audience.

Path caching

You can use similar things to make your application perceivably faster for users via path caching. Guess which way they go.

Example, BBC is list-detail example. On the left list of news stories. User can click through. We don’t want to wait when we click.

When laoding the front page. Make separate calls to get the data, let it expire. Dont do calls twice. Cache images via normal Image JS thing.

Then when getting the story when user clicks: get data from local storage. If no internet, always get it. Tah dah. Works offline!

Part III: The futureLet’s take a peek into the future

AppCache

AppCache sounds pretty amazing right? Well, not everyone agrees... Jake Archibald, anyone heard of this guy?

(Lists some key problems with AppCache)

Give developers !ne-grained control about caching,

without breaking the web

So a new proposal popped up written by Google (and backed up by Mozilla since then). Originally known under `NavigationControllers`, and currently under `ServiceWorkers`. Main goal:

ServiceWorkersFirst request


ServiceWorkersFirst request


For foo/* please consult me!

ServiceWorkers2nd request

I need foo/blah

Javascript file acts as HTTP proxy now

ServiceWorkers2nd request

I need foo/blah

200 OK!

Javascript file acts as HTTP proxy now

Example: registering

Runs in separate thread just like normal worker. Easy feature detection, no support? no registration, nothing happens. This also means that you can *just* build for ServiceWorkers.

This is for the whole domain

Example: use cache

It’s like an HTTP proxy all written in client side javascript. It also doesn’t break HTTP, because your code will still do normal AJAX requests etc. If there are no service workers enabled, this code won’t run and we’ll consult the server.

Spec & playing aroundhttps://github.com/slightlyoff/ServiceWorker

It's testable, there is a polyfill available, but it's really for experimenting only.

https://github.com/slightlyoff/ServiceWorker

https://github.com/slightlyoff/ServiceWorker

OMGAWESOMEWant to see Firefox OS?

OMG AWESOME SHIT. Now you know how to make offline web apps. I know that there will be a bunch of ppl that want to know more about FFOS. Meet me afterwards. I also have devices with me.

Now ONE MORE THING... This is too good not to show. A commercial from Movistar about Firefox OS to get you excited about that.

Thank you!

slideshare.net/janjongboomThank you!

slideshare.net/janjongboom

Questions?

Thank you!