Offline of web applications
Upcoming SlideShare
Loading in...5
×
 

Offline of web applications

on

  • 2,087 views

Jan Jongboom @janjongboom

Jan Jongboom @janjongboom
"Offline of web applications"
on Frontend Dev Conf'14
www.fdconf.by

Statistics

Views

Total Views
2,087
Slideshare-icon Views on SlideShare
542
Embed Views
1,545

Actions

Likes
2
Downloads
9
Comments
0

2 Embeds 1,545

http://dev.by 1544
http://digg.by 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Offline of web applications Offline of web applications Presentation Transcript

    • Of!ine for web Jan Jongboom Frontend Dev Conf 2014
    • @janjongboom Jan, live in Amsterdam. Work for Telenor. Owns part of Vimpelcom. They pay me to work on Firefox OS.
    • @janjongboom Jan, 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 mobile These 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
    • Currency converter BYR -> EUR. Price of a beer. - It’s a website. Resources are on a server. - Data comes from Yahoo
    • 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 shell App content Let me introduce some basic concepts here. An application consists of two parts: 1. The shell 2. 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.
    • 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.
    • 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 cache Basically, list all files & put them in the cache.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • Writing AppCache !le Store as currency.appcache Appcache is a file on your server. Very easy.
    • Writing AppCache !le Store as currency.appcache Appcache is a file on your server. Very easy.
    • Writing AppCache !le Store as currency.appcache Appcache is a file on your server. Very easy.
    • Writing AppCache !le Store 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
    • Inspecting AppCache (Chrome) chrome://appcache-internals/ Chrome has a similar thing under chrome://appcache-internals
    • 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
    • Performance Also useful for performance. Because no need to hit the server. This is data from a web application I built. Pretty simple.
    • 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.
    • 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.
    • 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.
    • 250% speed bump Not just for of"ine
    • Part II: App content We 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.
    • 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)
    • A simple AJAX request This is how I get the data from the server (simple AJAX request)
    • 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.
    • We can store the result in localStorage. key/value store. If no internet, get data from LS.
    • We can store the result in localStorage. key/value store. If no internet, get data from LS.
    • We can store the result in localStorage. key/value store. If no internet, get data from LS.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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!
    • Then when getting the story when user clicks: get data from local storage. If no internet, always get it. Tah dah. Works offline!
    • 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 future Let’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:
    • ServiceWorkers First request Grabbing jan.com/index.html
    • ServiceWorkers First request Grabbing jan.com/index.html For foo/* please consult me!
    • ServiceWorkers 2nd request I need foo/blah Javascript file acts as HTTP proxy now
    • ServiceWorkers 2nd request I need foo/blah Javascript file acts as HTTP proxy now
    • ServiceWorkers 2nd 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: 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: 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.
    • 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.
    • 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 around https://github.com/slightlyoff/ServiceWorker It's testable, there is a polyfill available, but it's really for experimenting only.
    • 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.
    • Thank you! slideshare.net/janjongboom Thank you!
    • slideshare.net/janjongboom Questions? Thank you!