Now that we have a good understanding of HTML5 for applications, we can jump right into the HTML5 application architecture. The most important aspect of a good architecture is the independence and integration of all the parts of the system (i.e., integration should not be a factor of dependence). In other words, we strongly recommend lightweight, modular frameworks or libraries that do one or two thing well over the do-it-all mega-frameworks (e.g., Sencha) that try to do too many things, often in their own way (and not the HTML/CSS/JS way).
So, in short, go lightweight and modular, and most of all, learn the HTML5 way and NOT the framework way.
Here is our recommended HTML5 application architecture (with some library recommendations).
From bottom to top:
2 DOM Access API
jQuery provides a very clean, powerful, and flexible API to access the DOM and does a great job of normalizing DOM access across browsers. jQuery has also some very good utility APIs, such as Deferred, that are critical for enterprise application development (more on that later).
jQuery library has become a de facto standard for good reason: because it does what it does better than any other libraries (by a long shot). Developers should not hesitate to use it in their mobile, tablet, and PC applications; it will normalize their DOM access as well as minimize a lot of boilerplate code to manipulate the DOM.
Kudos to John Resig for his novel approach to DOM access and manipulation. jQuery makes building DOM access concise, efficient, and even fun!
Note While jQueryMobile and jQueryUI sort of resulted from jQuery, their respective designs are far from exhibiting the quality level of the jQuery API (in our opinion). In fact, we think that jQueryUI and jQueryMobile, while they do have some nice UI styles, have a fundamentally flawed design for large- or even medium-scale applications (without mentioning that it does not make sense for any framework to be mobile- or PC-only). Thus, in short, developers should not think twice before using jQuery but should really be extremely careful about using jQueryMobile or jQueryUI. (Sorry for the bluntness of this note. It is nothing personal against the jQueryMobile or jQueryUI developers, but this site is about sharing our experience in building high-quality HTML5 applications, and for this, we decided to share our points of views in an unfiltered manner.)
Thus, our strong recommendation is to use jQuery for your mobile, tablet, and PC applications without a second thought.
3 UI Elements
Understanding the taxonomy of HTML UI elements in your application is probably the most important understanding for your architecture. This understanding can drive you the right way or the wrong way.
In short, there are two different approaches.
Therefore, our recommendation is to do the base UI element the HTML/CSS way (no JS required for display), and once you get those right, you will see that your applications will be much simpler and scale much better. Twitter/Bootstrap is a great starting point that will give you a first set of robust HTML/CSS UI elements as well as showing you how to build clean and flexible HTML/CSS application UI elements.
We like to use Handlebars.js, because it is mature, extensible, not as constrained as Mustache but still promote good coding practice, and has a way to precompile the templates that can be very useful for performance or Chrome App support (which does not support eval or new function).
On the data side, JSON is the data format to follow, as it is natively supported by the client and widely adopted in the various server environments. Beyond the data format, a well-architected HTML5 application needs a simple but robust data access layer that allows the decoupling of the views from the data, and this is exactly what an MVC, such as brite.js, should provide.
There are two important capabilities that any data access layer should provide:
- Asynchronous data access: This is a must for any real application. The application (views and logics) cannot assume that the data will be accessible in a synchronous manner. Many MVC frameworks make this mistake, and the application code needs to work around this oversight. A robust data access layer exposes all the CRUD API in an asynchronous manner. The brite DAO follows this pattern and uses the jQuery.Deferred model.
- Data eventing model: The next important point of any data access layer is its eventing model. This is usually well-understood by the framework maker. For example, brite has a simple but powerful event system with a jQuery type of selector (e.g., brite.dao.onDataChange).
6 LightWeight MVC
There are two ways to implement MVC in an HTML environment, the widget/desktop way, which consists bringing all the desktop MVC patterns to HTML – Sencha is a good example of this – or the "DOM Centric" way, which consists of using the DOM model as much as possible and just adding the missing MVC pieces.
At BriteSnow, we take the second approach, as we think it yields better and simpler application code, and greater performance, and optimized applications. We actually built over a year a lightweight, robust, and powerful DOM-centric MVC on top of a jQuery core, brite.js.
brite.js brings the following two missing pieces to the DOM/jQuery programming style:
- A view model that provides us with a well-structured and scalable view model for advanced applications.
- A DAO model access layer that provides a pluggable and asynchronous data access layer with a jQuery-like eventing model.
On the application side, the code needs to be well-structured and componentized, and developers should not hesitate to create some "application-specific layers" to enable cross-component application logic.
The following are some best practices we follow at BriteSnow (for more, see the brite documentation and the HTML5 application tutorial):
- o For larger projects, we often use cssless, as it allows better css componentization, and we usually import the boostrap mixins.less, as it has some very convenient macros/mixins. Even when using lesscss, we still use the final bootstrap.min.css and not the .less file except for the mixins.less file.
- Probably one of the most important code designs of an application is its event model. See Adding The Events from the building HTML5 applications tutorial.
- We usually build a custom DAO that is tailored to the application store needs following the CustomDAO best practice.
- o We tend to first use CSS3 animation, and then add jQuery animate if we need to support older browsers. This allows very smooth animations on mobile devices and tablets.