Enterprise application development over the decades has been a pendulum swinging back and forth between terminal and mainframe, between client and server. In the 1980s, business logic was largely pushed to the server by "dumb terminals" or "thin clients" which did very little except act as a middleman between the user and the server. Beginning in the 1990s, logic started to swing to the client with "fat clients" bearing the processing burden. With the introduction of the World Wide Web in 1991, a new breed of thin client emerged. The pendulum swung once again. Or did it?

The shift between client and server has largely been driven by cost and power. Early on, investment was made in powerful, costly servers. As PCs became more powerful in terms of memory and processing ability, as well as lower in cost, it became possible to build applications that could be distributed more easily, allow for offline capabilities, and best of all require less powerful (and less costly) server infrastructures. However, maintaining, upgrading, and deploying "fat clients" created a new burden.

Web-based applications eventually emerged to solve the problems of cost, power, and maintainability. At first, they appeared to be much like their "thin client" predecessors: merely middlemen between users and servers but without the deployment overhead. However, with the introduction of technologies such as Java and JavaScript, the "thin client" began to put on a little weight. Before long, the processing burden began to bleed to the client as applets, scripts, and plugins became more commonplace and with them the maintainability problem reappeared. Rather than managing distributions of applications, the problem shifted to managing distributions of applets, scripts, and plugins.

The situation was bifurcated by the introduction of "rich clients". Business logic became tiered. A separation of concerns became the norm. Let the server deal with server stuff. Let the client deal with client stuff. The problem with this, however, is that the client took some time to be able to handle the client stuff the world needed of it.

When Tim Berners-Lee introduced his World Wide Web browser to his CERN colleagues in 1990, only a glimmer could be seen of what it would one day become. Marc Andreessen would introduce Mosaic and graphical browsing in 1993 and Netscape would soon follow in 1994. After that, Microsoft jumped in with Internet Explorer in 1995. Pretty soon, the first browser wars would come and go with Internet Explorer emerging as the victor and the remnants of Netscape coalescing around Mozilla and Firefox, which was released in 2002. In the 2000s, Apple released Safari and Google released Chrome.

Web browsers however have seldom held parity with one another. The existence of web standards and a governing body called the W3C notwithstanding, browser makers have nevertheless played to their own tunes. In the beginning, implementations of HTML varied widely and the trend continued through HTML 4.0, XHTML, CSS, and JavaScript. The variance in implementations and behavior made web development difficult and time consuming.

To combat the limitations and inconsistencies of the web browser, technologies based on plugins such as Adobe Flash began to flourish continuing where browser-based technologies such as HTML, CSS, and JavaScript left off. For years, many websites consisted mostly—and sometimes entirely—of technologies such as Flash; such plugins even afforded better performance. The notion of Rich Internet Applications (RIAs) prevailed as the pendulum swung back to fatter clients.

The inclusion of plugin-based technologies became a red herring for the promise of the World Wide Web. While connectivity of content was a hallmark of the original principles of HTML, content was represented by tags such as embed, object, and applet where application modules are embedded onto a web page constituted black boxes that hid content from the semantic web.

Web browsers nevertheless evolved. JavaScript frameworks such as jQuery emerged to abstract browser differences and offer up richer interactivity. CSS techniques emerged to overcome the limitations and inconsistencies between the browsers. Newer browsers emerged with better support for web standards.

However, something was missing. Even though applications were being developed using browser-based technologies, many application features were left out of the browser. Consistent mechanisms to add video/audio playback, offline capabilities, and even browser history management were missing. Flash was still looked upon as filling in the missing pieces of the web.

Finally, browser development coalesced around HTML5 in 2009 when XHTML 2.0 was abandoned in lieu of something more backward compatible with earlier versions of HTML. HTML5 sought to address two major areas in the browser: the need for a more consistent, semantic markup language and the demand for more natively-supported browser features. When it was introduced in 2004, it heralded a set of APIs to make the browser into a true application development platform and thus more semantically amenable.

With modern browsers' increasing support for HTML5, reliance on plugin-based technologies is starting to give way to browser-based implementations. With the APIs that allow for better control of the experience, the client is finally beginning to catch up to its promise. Mobile web browsers have especially become a catalyst for this. Since Adobe Flash is not supported on devices such as the iPhone and iPad, and since implementation of HTML5 features on Safari have grown, HTML5 is quickly becoming a standard for mobile web application development. However, if this trend is to continue, browser makers and application developers must adhere to the developing standards for HTML5, which brings us back to the logo. To right the wrongs of the past, HTML5 must have collective agreement on implementation. In order to inculcate this, there is a burgeoning movement to enforce standards in web browsers and applications, and speed up implementation as adoption looms. The HTML5 logo is emblematic of that effort.

HTML5 makes an attempt to codify information on the web in a more cohesive way than before. With previous versions of HTML, content is structured based on how it should be displayed rather than its inherent meaning. The div tag is often used, but what does a div tag really mean? To get around this, application developers have broken up their content using id attributes based on standards and best practices of web presentation.

For example, application developers use tags such as the following:

<div id="header">
<div id="footer">

The obvious problem is that what gets used for the id attribute need not follow a standard. One application developer could use id="header" while another uses id="head". In order to standardize structure based on semantics, HTML5 introduces a set of new tags that takes the vagaries out of the process.

HTML5 introduces a set of new top-level tags, which can be broken down into the following categories: content, language, layout, and format.

<div itemscope itemtype="http://mysite.com/Movie">
    <h1 itemprop="title">Your Favorite Movie</h1>
    <p itemprop="summary" >
      A summary of your favorite movie.
    </p>
</div>

Now that we know many of the new tools for building a page in HTML5, let us dive into what a page looks like.

<!DOCTYPE html>

<!doctype html>
<html lang="en">
<head>
  <title>My First HTML5 Page</title>
  <meta charset="utf-8">
  <meta name="description" content="My first HTML5 page.">
  <meta name="author" content="Me">
</head>
<body>
</body>
</html>

For much of this book, we will be building a mobile web application that illustrates many of the features of HTML5. The application is called MovieNow, and will be a one-stop shop for finding, reviewing, and booking movies near you. The features we will develop in this book are as follows:

In the following chapters, we will build a variety of features of HTML5 into our MoveNow enterprise application.

Chapter 1, HTML5 Starter Kit: Compatibility, discusses support of HTML5 features across multiple web browsers and devices as well as ways to skirt the deficiencies of these browsers. The main driver for supporting multiple browsers is ensuring access to enterprise web applications across multiple devices while maintaining a consistent user experience.

Chapter 2, HTML5 Starter Kit: Useful Tools, provides a guide to getting started with HTML5 enterprise application development including available tools, their installation, and their use. A comprehensive evaluation of the business drivers for selecting tools will be discussed.

Chapter 3, The App: Structure and Semantics, walks you through setting up the boilerplate for the MovieNow enterprise application. We will set up the overall page structure, discuss semantic tags in depth, and talk about microdata.

Chapter 4, The App: Getting Movies via Geolocation, begins the MovieNow enterprise application by introducing geolocation. We will walk you through the geolocation API and how to use it to implement useful features.

Chapter 5, The App: Displaying Movie Data via CSS3, covers layout and features of CSS3 including some interesting CSS3 effects. We will also cover best practices in defining standard styles across web applications and devices including media queries and compatibility considerations for CSS3.

Chapter 6, The App: Trailers via HTML5 Video, introduces the video and audio tags and their use within an HTML5 enterprise application. We will talk about manipulating the playback of multimedia content via JavaScript as well as backward compatibility with browsers that do not support the HTML5 video and audio tags.

Chapter 7, The App: Showing Ratings via Canvas, walks through HTML5 canvas and using the drawing API to display graphics in your enterprise applications. We will use the drawing API to create ratings charts for our MovieNow application.

Chapter 8, The App: Selection UI via Drag-and-Drop, covers the drag-and-drop API. We will implement the drag-and-drop functionality in the MovieNow enterprise application demonstrating event delegation and the publish-subscribe pattern.

Chapter 9, The App: Getting the Word Out via Twitter, discusses forms and form validation in HTML5 by integrating with the Twitter API. We will implement posting of tweets from within the MovieNow application.

Chapter 10, The App: Consuming Tweets via Web Workers, demonstrates Web Workers and the power of external APIs to bring social elements to enterprise application. We will integrate tweets near you into the MovieNow application.

Chapter 11, Finishing Up: Debugging Your App, talks about ways of debugging HTML5 enterprise applications. We will discuss the browser console and HTTP proxies.

Chapter 12, Finishing Up: Testing Your App, covers tools for testing HTML5 enterprise applications. We will cover functional test suites and automated tools.

Chapter 13, Finishing Up: Performance, discusses performance, which is a crucial topic for any HTML5 enterprise application. We will talk about strategies and tools and walk through profiling your HTML5 application.

You will need prior knowledge of web application development as this book introduces developers already familiar with the basics of the web including HTML, CSS, and JavsScript to the advantages of HTML5 and CSS3.

This book is primarily aimed at application developers who have some experience developing applications for the web, and want to extend their knowledge to the latest developments in HTML5 and CSS3. Upon completion of this book, readers will have a thorough understanding of the toolset that HTML5 provides to develop enterprise applications.

In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.

Code words in text are shown as follows: "Copy html5shiv.js from the dist folder to your JavaScript folder".

A block of code is set as follows:

<div class="geolocation-available">
  Congrats! Your browser supports Geolocation!
</div>
<div class="no-geolocation">
  Your browser doesn't support Geolocation :(
</div>

New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "Click on the GENERATE! button".

Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.

To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.

If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or e-mail <[email protected]>.

If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.

Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.

Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.