This is a review of the third course in the HTML5 learning path on Pluralsight. The previous course is HTML5 Fundamentals, which is also by Craig Shoemaker.

Whereas the HTML5 Fundamentals course was updated to a 2nd edition, unfortunately this course hasn’t been. There is still a lot of relevant and useful information in this course. I will warn you about the areas that have out of date information.

Offline Applications

The first module is on Offline apps. This works using a combination of two technologies:

Browser events and Application Cache.

According to Mozilla Developer network, application cache is deprecated and using it is highly discouraged. This article recommends using Service Workers instead.

However at the time of writing, Service Workers have not yet been approved as a standard and according to Can I Use no browser fully supports this yet.

Service Workers should not be confused with Web Workers which are covered later in this course. The first draft of the Service Workers spec came out in May 2014, (almost 3 years after this course came out). Broadly speaking, Service Workers aren’t yet supported at all by Safari or Edge browsers so be aware that this won’t work for all of your users.

A Personal Cautionary Tale

I had a business requirement for an offline application recently (3rd May 2016). This needed to work on older browsers as well, so using a Service Worker wasn’t a viable option.

As this was just a proof of concept, I decided take the lazy option: I downloaded Sandeep-Thakur’s sample HTML5 Offline Application with ASP.NET MVC 5 and deployed into onto a web server.

Not long after, my boss came over to me saying it doesn’t work! He showed me on his iPhone: turn off internet connection, hit refresh, and it just displays a “There is no internet connection” message.

This lead to all sorts of faffing around with changes aimed at getting it to work. I kept battling with 404 errors in Chrome because if there is any error in the manifest you only see a generic error with no indication as to where the problem might be.

I read various advice saying the manifest needed to be named cache.appcache  or cache.manifest etc, but none of these things fixed the problem.

I found that Craig Shoemaker has also written the article Build an HTML5 Offline Application with Application Cache, Web Storage and ASP.NET MVC. The advice to use the mime type text/application-manifest disagrees with the latest work in progress (and suspended) offline draft specification.

Finally I decided to try out html5demos.com/offline

I knew that Remy Sharp would have gotten this right, but I got the same problem!

So there were many issues but we eventually managed to get it working. My advice is to start off very simple with only a couple of cached files and only one fallback html page.

I have found that on the latest version of Chrome or Firefox, Google’s Service Worker Demo works as you would expect when you refresh the page offline, although it will not work in any browser from Microsoft (as at May 2016).

And now back to the course review:

Course Module for Offline Applications 

In this module we see a journal application that will remember your entries whether you are connected to the Internet or not.

A defining feature of Offline apps is the manifest attribute, which appears inside the HTML tag, e.g.

manifest=”myManifest.aspx”

The anatomy of an offline application clip gives an example of what a cache manifest looks like. There are 4 sections:
CACHE MANIFEST, CACHE, NETWORK, and FALLBACK.

You must be careful with the files you list in the CACHE section because if there is a problem with one of those files, none of those files will work!

The NETWORK section lists areas of your website that you never want to be cached.
The FALLBACK section is a list of redirects to occur in the event of the application going offline.

Also important is some JavaScript to set the Online Awareness status.

Craig explains the difference between browser caching and application caching: the latter groups the list together in the manifest. Craig warns not to use meta tags to prohibit browser caching because often browsers ignore meta tags.

Mixing browser caching and application caching is a gotcha.

Geolocation

This API is not considered part of HTML5 anymore, rather a separate API, but that’s just a classification detail.

The good news is this API is supported by all modern browsers, as well as some older ones:

Chrome 4+
Firefox 3.5+
Opera 10.6+
Safari 4+
Internet Explorer 8+

Craig explains how to reset location permissions for each browser so that you can see that the permission confirmation messages appear at the right time and work correctly.

He then runs through the jQuery code for fetching a user’s coordinates and displaying them on a map. You can fetch statistics such as heading, speed, timestamp, altitude and even accuracy.

As well as getting the user’s position via a one time event, the API also supports watching the user’s position. This uses navigator.geolocation.watchPosition, and this course runs through the jQuery code for this demo.

Also covered is how to fine tune the positional information with different positional options.

Web Storage

There are two types of Web Storage (a.k.a. DOM storage) – Local and Session.

Session based storage disappears at the end of a session, whereas Local storage is more like good old cookies, but with a whole lot more space available: 2-10MB as opposed to just 4kb.

The other advantage of Web Storage over cookies is the information is not sent back to the server with every request.

Web Storage is well supported by all modern browsers: see can i use

Craig demonstrates a shopping cart for buying futuristic Internet-enabled contact lenses, using jQuery and JSON.stringify.

The API is the same whether you are doing local or session storage, and it is easy to use.

Internet Explorer 9 supports the Web Storage Event, and Craig demos this. This doesn’t appear to be supported by other browsers.

Later we see a demo of what happens when the storage limit is exceeded:
DOM Exception QUOTA_EXCEEDED_ERR (22)

Web Workers

There are two types of Web Workers: Dedicated, and Shared. This module covers Dedicated Web Workers because Shared workers weren’t implemented by any browsers when the course was recorded in 2011.

Shared Web Workers are still not supported in Microsoft Edge or Apple Safari however there is now wide support across modern browsers for Dedicated Web Workers.

There’s a nice demo of calculating Fibbonaci numbers where we first see it done without Web Workers: when the amount of calculation gets too much, the UI freezes up and the Chrome browser asks the user whether or wait or kill the page.

Once the code is updated to use a Web Worker, we no longer affect the UI thread and the user can continue to work elsewhere on the web page while the calculation happens in the background.

Another good bit of news is that there are very minimal code changes required to use Web Workers.

In the clip on controlling workers, we learn that you cannot tell a worker to stop once its started, only either terminate or close it. Close gives the worker a chance to finish what its doing first, rather than being terminated immediately.

In the summary, Craig mentions generating 3D images using Ray Tracing. This is now entirely possible to do in JavaScript, for a demo see threejs

Web Sockets

A great article on Web Sockets that Craig references can be found here:

http://www.websocket.org/quantum.html

Craig introduces Fleck, a C# implementation of Web Sockets written by Jason Staten.

There are many others. There is a Comparison of WebSocket implementations available on Wikipedia.

Web Sockets is now well supported by modern browsers: see caniuse.com

I also found Autobahn interesting.

If you find Web Sockets interesting and use .NET, I recommend learning about SignalR.

Craig demonstrates a Hello World app and then a Stock Ticker app using Fleck. Also check out this SignalR based Stocker Ticker

Microdata

Microdata is a new technology for a more semantic web, allowing metadata to be nested into pages so that they can be easily read by both humans and machines.

This technology never made it all the way to recommendation due to nobody volunteering to be the editor of the spec. Therefore this appears to be another lame duck technology – probably not worth your time learning.

Finally

This course has covered a lot of ground. I know that I certainly learned a lot from it. However, there are many more important JavaScript APIs available to use today.

For information on ALL of the JavaScript Web APIs (there are a lot), visit Mozilla Developer Network – Web APIs