Top 10 + 1 HTML5 Concepts for HTML5 Application DevelopersNovember 7th, 2012, by jeremy
Front-end HTML5 developers have a lot to learn in order to build high-end HTML5 applications, and the learning process can quickly become overwhelming if not tackled the right way.
From a conceptual point of view, here are the 11 important HTML5 concepts that a good HTML5 front-end developer should understand:
1) HTML5 is HTML, with a momentum
Understand that HTML5 is HTML and that the same application model is applicable. So, no new magical development paradigm was brought with HTML5 (outside of Canvas/WebGL, which is totally new), it’s just that the browsers are more robust, much faster, and more capable.
The real HTML5 benefit is the momentum it managed to create among the top browser providers (Mozilla, Google, Apple, and Microsoft) that now compete on compliance and performance on a single specification and that alone create a huge set of long-term opportunities for developers.
2) Touch and Mouse should not require two different frameworks
Understand that while HTML5 applications might need different façades for type of devices (Mobile Phone, Tablet, or PC) devices, the point of bifurcation should NOT be at the tech stack (i.e. framework or library) level but rather at the application level.
HTML5 developers should use HTML5 frameworks and libraries that are designed to run on both Touch and Mouse devices, and they must make the appropriate user interface optimization (UI) optimization at the application layer.
Backbone, Brite, Angular.js, jQuery core, Twitter/Bootstrap, and many templating engines obey this non-device-specific HTML5 framework or library approach, and developers should evaluate those rather than lock their applications to particular device types because of their framework choices (e.g., Sencha Touch vs Sencha Ext or jQueryMobile vs jQueryUI).
From our experience, the right split is not between Touch and Mouse devices but rather between Mobile Phone and Tablet/PC, as the latter category shares more or less the same form factor. The application will have to handle Touch and Keyboard/Mouse for Tablet and PC, but this can be easily handled by the same application and should not require a different tech-stack. Therefore, Mobile or Touch-centric frameworks do not really make sense in a real HTML5 application scenario, as you would often want your next-generation Tablet Web application to also be your PC Web one (at least, you do not want your framework to tell you this cannot be done).
3) Pros and cons of JS vs. CSS3 animation
4) Benefits of asynchronous programming and Web Workers
5) Understanding Canvas vs. SVG
Understand the Canvas vs. SVG. This one is a tricky one, as there is a lot of "social-engineering" baggage behind the technical aspects. On the technical side, SVG is a DOM approach to vector graphics (and consequently a retained mode), whereas Canvas is a programmatic and immediate-mode approach. The catch is that sometimes it seems Canvas gets a little bit more "love" from the browser vendor developers, as SVG has always had a love-hate relationship with HTML from its beginning.
7) IE7 & IE8 can have HTML5 look (at extra dev. cost)
8) The power of HTML/CSS simplicity
Understand that the power of HTML and CSS for good element layout and styling is in its simplicity. Twitter/Bootstrap is a great (and probably the best) example of this. Combine simple HTML structure with simple CSS classes, and you can get some great reusable UI elements.
SASS or LESSCSS (used in Bootstrap) are also great tools that bring componentization to CSS, thus allowing for clean and simple HTML/CSS application code, which, in turn, facilitates customization and performance optimization.
9) Decoupling UI layout/style (HTML/CSS) from behavior (i.e. JS)
Following on point #8, understand that decoupling UI layout/style from behavior (i.e. JS) brings a great deal of performance and flexibility.
This approach allows you to take full advantage of the browser’s ever faster rendering time performance as well as its delegation model by allowing lightweight DOM elements to be rendered in bulk and activated only when the user interacts with them (using delegation and such event models).
10) Understanding the need of a MVC
Web application developers (not Web page developers) must have a good understanding of the principle and benefits of a Model-View-Controller (MVC) architecture.
In short, building any type of application, desktop, native, Web 1.0, Ajax, or HTML5 always requires a good partitioning of the data and the views. The two need to be integrated but kept independent at the same time. The architecture and pattern that allow this to be accomplished is often referred to as MVC.
11) Understanding the benefits of a DOM-centric MVC approach
Okay, this is an architecture approach based more on our experience than on fact, but I think that to develop a high-end and scalable HTML5 application, developers do not need to (and actually should not) bring the full desktop/native/widget-centric MVC patterns to the DOM, but rather they should start from the DOM and see what is missing to have a strong MVC in the DOM way.
The DOM-centric MVC approach is the one we took at BriteSnow, and we have materialized this approach in a lightweight DOM-centric MVC framework called brite.
So, here it is—a quick view of some important HTML5 concepts for front-end HTML5 application developers to understand (or even to disagree with).