11. Currency converter BYR -> EUR. Price of a beer.
- It’s a website. Resources are on a server.
- Data comes from Yahoo
12. Currency converter BYR -> EUR. Price of a beer.
- It’s a website. Resources are on a server.
- Data comes from Yahoo
13. Currency converter BYR -> EUR. Price of a beer.
- It’s a website. Resources are on a server.
- Data comes from Yahoo
14. When no internet connection -> breaks. Oh noes. We want to fix it.
15. The shell
App content
Let me introduce some basic concepts here. An application consists of two parts:
1. The shell
2. App Content
16. 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.
17. 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.
18. 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.
19. 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.
20. 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.
21. List all !les, put them in cache
Basically, list all files & put them in the cache.
23. AppCache
First request
Grabbing jan.com/index.html
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.
24. AppCache
2nd 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.
25. AppCache
2nd 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.
26. AppCache
2nd 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.
32. 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.
33. Inspecting AppCache (FF)
Tools > Developer > Developer Toolbar
appcache list localhost
Dealing with appcache info, to debug
37. 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
38. Performance
Also useful for performance. Because no need to hit the server. This is data from a web application I
built. Pretty simple.
39. 1500 ms
Empty 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.
40. 820 ms
Subsequent reload
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.
41. 320 ms
Reload with appcache
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.
55. Path caching
You can use similar things to make your application perceivably faster for users via path caching.
Guess which way they go.
56. 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.
57. 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.
58. 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.
59. 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.
60. 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.
61. 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.
62. 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.
63. Then when getting the story when user clicks: get data from local storage. If no internet, always get it.
Tah dah. Works offline!
64. Then when getting the story when user clicks: get data from local storage. If no internet, always get it.
Tah dah. Works offline!
65. Then when getting the story when user clicks: get data from local storage. If no internet, always get it.
Tah dah. Works offline!
66. Part III: The future
Let’s take a peek into the future
67. AppCache
AppCache sounds pretty amazing right? Well, not everyone agrees... Jake Archibald, anyone heard of
this guy?
(Lists some key problems with AppCache)
68. 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:
74. 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
75. 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
76. 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
77. 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.
78. 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.
79. 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.
80. Spec & playing around
https://github.com/slightlyoff/ServiceWorker
It's testable, there is a polyfill available, but it's really for experimenting only.
81. OMGAWESOME
Want 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.