Programming HTML5 Applications

Chapter 1. The Web As Application Platform

HTML5 makes the Web a first-class environment for creating real applications. It reinforces JavaScript’s existing tool set with key extensions to the browser APIs that make it easier to create applications that feel (and can be) complete in themselves, not just views on some distant server process.

The Web began as a way to share files, stored on a web server, that changed only occasionally. Developers quickly figured out how to generate those files on the fly, taking the first big step toward building applications. The next big step was adding interactivity in the browser client. JavaScript and the Document Object Model (DOM) let developers create Dynamic HTML, as the “browser wars” raged and then suddenly stopped. After a few years, Ajax brought these techniques back into style, adding some tools to let pages communicate with the server in smaller chunks.

HTML5 builds on these 20 years of development, and fills in some critical gaps. On the surface, many of HTML5’s changes add support for features (especially multimedia and graphics) that had previously required plug-ins, but underneath, it gives JavaScript programmers the tools they need to create standalone (or at least more loosely tethered) applications using HTML for structure, CSS for presentation, and JavaScript for logic and behavior.

Adding Power to Web Applications

HTML5 raises the bar for web applications. While it still has to work under security constraints, it finally provides tools that desktop developers have expected for years:

Local data storage

It can store up to 5 MB of data, referenced with a key-value system.

Databases

Originally a SQLite-based API, the tide seems to have shifted to IndexedDB, a NoSQL system that is natively JavaScript.

Files

While applications still can’t freely access the filesystem (for obvious security reasons), they can now work with files the user specifies and are starting to be able to create files as well.

Taking it offline

When a laptop or phone is in airplane mode, web applications are not able to communicate with the server. Manifest files help developers work around that by caching files for later use.

Web Workers

Threads and forks have always been problematic, but JavaScript simply didn’t offer them. Web Workers provide a way to put application processes into separate spaces where they can work without blocking other code.

Web sockets

Hypertext Transfer Protocol (HTTP) has been the foundation of the Web, despite a few updates over time. Web sockets transform the request-response approach to create much more flexible communication systems.

There’s much more, of course—from geolocation to audio and video to Canvas graphics to a wide variety of minor new tags—but these provide the foundations for building industrial-strength applications in HTML5.

Developing Web Applications

In the old days, a complex web application might be a catalog, which would be static pages derived from a database, or a JavaScript loan calculator. But no one would have dreamed of doing complex applications in JavaScript. Those required Java or maybe a dedicated client/server application written in C or C++. Indeed, in the days before the DOM and Ajax, developing complex applications in JavaScript would have been pretty much impossible. However, Ajax introduced the ability to interact with the server without reloading the page, and the DOM allowed the programmer to change HTML on the fly.

In 2007, Google introduced Gears, a browser extension that gave the developer a lot more power than had been there before. Gears allowed the browser to work offline, to enable users to store more data in the browser and have a worker pool to offload long-running tasks. Gears has since been discontinued, as most of its features have migrated into HTML5 in modified forms.

The modern Web features a full range of sites, from things that are still effectively old-style collections of documents, like Wikipedia, to sites that offer interactions with other people, such as Facebook, YouTube, and eBay, to things that can serve as replacements for desktop applications, such as Gmail and Google Docs. Many formerly standalone applications, such as mail clients, have become part and parcel of the web experience. In the modern Web, the line between applications and pages has blurred. The difference at this point is only in the intent of the site.

Running an application in the browser has some major advantages for both the user and the developer. For the user, there is no commitment to the application: you try it out, and if you don’t like it, you can move on to the next page with nothing left behind to clutter up your disk. Trying new applications is also reasonably safe, in that they run in a sandboxed environment. New versions of the application are automatically downloaded to the browser when the developer updates the code. Web applications rarely have version numbers, at least public ones.

For the developer, the case is even stronger. First of all, the things that are an advantage to the users are also good for the developers. There is no installation program to write, and new versions can automatically be sent to the users, making small, incremental updates not only possible but practical. However, there are other bonuses as well.

The Web is cross-platform. It is possible to write a web page that will work on Windows XP, Windows Vista, Windows 7, Mac OS X, Linux, the iPhone/iPad, and Android. Doing that with a conventional development tool would be a monumental task. But with the Web and some forethought it almost comes for free. A web application built on standards with a library like jQuery will be able to run on major browsers on all those platforms and a few others. While at one point Sun hoped that its Java applets would define the Web as a platform, JavaScript has turned out to become the default web platform.

You can even run web applications on mobile devices, at least the ones that today are called smartphones. With a wrapper like PhoneGap, you can create an HTML5 app and package it for sale in the App Store, the Android Market, and more. You might create an application that interacts heavily with a web server, or you might create a completely self-contained application. Both options are available.

The real place that the Web, prior to HTML5, traditionally falls short is that a web application, running on a computer with gigabytes of memory and disk space, acts almost like it is running on an old VT320 terminal. All data storage must be done on a server, all files must be loaded from the server, and every interaction pretty much requires a round-trip to the server. This can cause the user experience to feel slow, especially if the server is far away from the user. If every time the user wishes to look up something there is a minimum response time of 400 milliseconds before any actions can be taken, the application will feel slow. From my office in Tel Aviv to a server in California, the round-trip time for an ICMP ping is about 250 ms. Any action on the server would be extra and slow that down even more. Mobile device communications can, of course, be even slower.

JavaScript’s Triumph

Though JavaScript has been a key component of web development since it first appeared in 1995, it spent a decade or so with a bad reputation. It offered weak performance, was saddled with a quirky syntax that led to mysterious bugs, and suffered from its dependence on the DOM. Browsers kept it locked in a “sandbox,” easing users’ security concerns but making it very difficult for developers to provide features that seemed trivial in more traditional desktop application development.

Scripting culture created its own problems. Although providing a very low barrier to entry is a good thing, it does come with costs. One of those costs is that such a language often allows inexperienced programmers to do some very ill-advised things. Beginning programmers could easily find JavaScript examples on the Web, cut and paste them, change a few things, and have something that mostly worked. Unfortunately, maintaining such code becomes more and more difficult over time.

With the Ajax revival, developers took a new look at JavaScript. Some have worked on improving the engines interpreting and running JavaScript code, leading to substantial speed improvements. Others focused on the language itself, realizing that it had some very nice features, and consequently developing best practices like those outlined in JavaScript: The Good Parts by Douglas Crockford (O’Reilly, 2008).

Beyond the core language, developers built tools that made debugging JavaScript much easier. Although Venkman, an early debugger, had appeared in 1998, the 2006 release of Firebug became the gold standard of JavaScript debuggers. It allows the developer to track Ajax calls, view the state of the DOM and CSS, single-step through code, and much more. Browsers built on WebKit, notably Apple’s Safari and Google Chrome, offer similar functionality built in, and Opera Dragonfly provides support for Opera. Even developers working in the confined spaces of mobile devices can now get Firebug-like debugging with weinre (WEb INspector REmote).

The final key component in this massive recent investment in JavaScript was libraries. Developers still might not understand all the code they were using, but organizing that code into readily upgradeable and sometimes even interchangeable libraries simplified code management.

jQuery

If anything can be described as the gold standard of JavaScript libraries, it would have to be John Resig’s jQuery library, which forms a wrapper around the DOM and other JavaScript objects such as the XMLHttpRequest object, and makes doing all sorts of things in JavaScript a lot easier and a lot more fun. In many ways, jQuery is the essential JavaScript library that every JavaScript programmer should know.

To learn jQuery, see the jQuery website or a number of good books on the subject, such as Head First jQuery by Ryan Benedetti and Ronan Cranley or jQuery Cookbook by Cody Lindley, both published by O’Reilly. Many examples in this book are written using jQuery.

ExtJS

Whereas jQuery forms a wrapper around the DOM, Sencha’s ExtJS tries to abstract it away as much as possible. ExtJS features a rich widget set that can live in a web page and provide many of the widgets, such as trees, grids, forms, buttons, and so on, that desktop developers are familar with. The entire system is very well thought out, fits together well, and makes developing many kinds of applications a joy. Although the ExtJS library takes up a lot of space, the expenditure is worthwhile for some kinds of application development.

One nice feature of ExtJS is that many of its objects know how to save their state. So if a user takes a grid and reorganizes the columns, the state can be saved so that the same order appears the next time the user views that grid. Using localStorage in ExtJS will show how to use the HTML5 localStorage facility with this feature.

Google Web Toolkit, etc.

Tools such as GWT allow the programmer to write Java code, which is then compiled down to JavaScript and can be run on the browser.