Understanding HTML5 can be a bit overwhelming at times, especially when reading all the buzz and articles about it. The starting point to correctly understand HTML5 is that HTML5 is HTML, and its biggest value for application developers is the fact that all browser providers (e.g., Google, Apple, Mozilla, and Microsoft) are now competing on compliance and performance on a single set of specifications (e.g., HTML5 and CSS3).
The consequence of this healthy but furious competition is that browsers are improving and converging faster that they ever have, making HTML, CSS, and JavaScript the best technologies for building cross-platform/device applications that can be distributed as Web or packaged applications.
From a feature point of view, www.html5rocks.com site has a very good list of all the new HTML5 goodies.
However, to further understand the impact of HTML5 on application architecture, we need to first take a look at the HTML flow chart. Any Web user interface, from single-page to multi-page, with Ruby/Rails, Java/JSP, or PHP, has the following HTML flow, one way or another.
- First, data exists 1 in databases, file systems, or even Web services.
- Upon a specific request, data logic 2 extracts and organizes the data needed to serve the request into a data model 3 to be rendered to the user.
- Then, the model 3 is combined with a template 4 (e.g., JSP, Freemarker, PHP, Mustache, or JsRender) to generate the HTML 3 that the browser will ultimately display to the user.
- Before and/or after the content is displayed, behavior logic 6 is "attached" to the HTML document.
- Upon user interaction 7, the behavior logic 6 handles the interaction by eventually updating all or part of the application by restarting the flow entirely or partially.
What HTML5 and the continuous browser innovation bring to application developers, besides fancy filters and effects, is how much more they can do on the client side vs. having to do it on the server. Here is a simple visualization of the capability evolution from Web 1.0 to Web 2.0/AJAX to HTML5.
- Web 1.0: At the beginning of the Web content and “application” era, browsers were designed to support lightweight scripting on the client side, and many user interface behaviors had to be done on the server side, which required round trips and heavy server state management.
- Web 2.0/AJAX: With the avenue of AJAX, which allows an application to request more content without refreshing the page, application developers had the ability to put more logic on the client side to start building a "desktop-like" experience in a browser.
- HTML5: With HTML5, the DOM (HTML, CSS, JS) is becoming a full application container, with offline workers, file API integration, and operating system integration. Now, with HTML5, it is possible to write full applications in HTML5/CSS3/JS with no server if one desires to, although a combination of client and server often offers the best value to the users. It is important to note that HTML is a living specification
Is it true that early HTML5 features can sometimes be little inconsistent between browser providers as they mature; however, this is part of the extremely iterative and dynamic nature of the Web specifications, which has become, for the better, implementation-driven over specification-driven. Developers should not be afraid of this process and, rather, embrace it by relying on well-documented and supported HTML5 features and learning upcoming ones by experimentation.
In short, understanding HTML5 for applications is understanding that HTML5 is HTML, that HTML5 is a living specification, and that, thanks to the momentum and ecosystem behind HTML5, HTML has become the only fully cross-device (and cross-distribution) environment allowing developers to build rich applications for PC, mobile devices, and tablets and distribute them via the Web or application stores. Best of all, we are just at the beginning!
In other words,
HTML5 = (HTML4 + 1) + (CSS2 + 1) + SVG = Rich Experience + Cross Platform + Web + App Store