HTML5 Enterprise Application ArchitectureMarch 10th, 2013, Updated September 2018, by jeremy
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).
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.
2018 Updated: We now do not use Twitter Boostrap anymore, as CSSGrid is offering a transformative way to do layout natively to the browser, and Google Material is a modern and holistic design specification.
There are quite a bit of JS Templating, such as Mustache, Handlebars, and the newest addition coming soon out of alpha, JSRender.
There are quite a number of JS templating engines, such as Mustache, Handlebars, and the newest addition coming soon out of alpha, JSRender.
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).
2018 Update: In 2018, we now use mvdom Pub/Sub for data event notification (Daos belong to the app, not the framework).
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.
2018 Update: In 2018, we now use mvdom, a DOM Centric MVC famework, which could be described as brite.js next gen (very similar API), which ZERO dependency, provides full async view lifecycle, simple and powerful pub/sub api, delegate even binding, as well as some, and best of all, MVCOM is the smallest DOM MVC framework (15kb minimized, 7kb gzip). Smaller is smarter in the world of JS Framework.
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):
We use PostCSS for better css componentization, and nowdays (2018) we tend to use CSS Grid for a lot of component/view layout. ss 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.
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.