This document summarizes Jan Jongboom's presentation on building web applications for offline use. Some key points: 1. Only 2.5 billion people out of 7 billion have internet access, so mobile users often don't have a connection. Applications need to work offline. 2. Applications have two parts - the shell (code, UI, assets) and app content (dynamic data). The shell can be cached using the AppCache API to work offline. 3. App content is fetched via AJAX but can be stored in localStorage to serve offline. Path caching pre-fetches related data to improve performance. 4. While AppCache works today, the ServiceWorker API proposed by Google

1. Of!ine for web
Jan Jongboom
Frontend Dev Conf 2014

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

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

4. Internet is normal for western world, but big part of the world doesnt have it.
Click Only 2.5 billion people out of 7.

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

6. 4.5 billion people, all on mobile
These people are going to come online on mobile

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

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

9. Оффлайн
важна!
For years we have been developing with online in our heads, but we should stop treating like offline is
still a second class citizen

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

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.

22. AppCache
First 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.

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.

27. Writing AppCache !le
Store as currency.appcache
Appcache is a file on your server. Very easy.

28. Writing AppCache !le
Store as currency.appcache
Appcache is a file on your server. Very easy.

29. Writing AppCache !le
Store as currency.appcache
Appcache is a file on your server. Very easy.

30. Writing AppCache !le
Store as currency.appcache
Appcache is a file on your server. Very easy.

31. Tell the browser there is a cache file with attribute

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

34. Inspecting AppCache (FF)
Tools > Developer > Developer Toolbar
appcache clear
appcache validate http://your.appcache

35. Inspecting AppCache (Chrome)
chrome://appcache-internals/
Chrome has a similar thing under chrome://appcache-internals

36. Inspecting AppCache (Chrome)
chrome://appcache-internals/
Chrome has a similar thing under chrome://appcache-internals

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.

42. 250% speed bump
Not just for of"ine

43. Part II: App content
We talked about the shell, but what’s equally important is what the shell contains

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

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

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

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

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

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

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

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

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

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

54. Something in between to shake up the audience.

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:

69. ServiceWorkers
First request
Grabbing jan.com/index.html

70. ServiceWorkers
First request
Grabbing jan.com/index.html
For foo/* please consult me!

71. ServiceWorkers
2nd request
I need foo/blah
Javascript file acts as HTTP proxy now

72. ServiceWorkers
2nd request
I need foo/blah
Javascript file acts as HTTP proxy now

73. ServiceWorkers
2nd request
I need foo/blah
200 OK!
Javascript file acts as HTTP proxy now

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.

84. Thank you!
slideshare.net/janjongboom
Thank you!

85. slideshare.net/janjongboom
Questions?
Thank you!