Choosing the right HTML5 technologies for your Web and Mobile Application. (jQuery, Bootstrap,brite.js, Sencha, jQueryMobile, or Angularjs?)

• Keep things simple and HTML by using libraries and frameworks that help normalize and modularize HTML, CSS, and JavaScript into well-architected application parts rather than ones that try to provide heavy abstractions. Used the right way, the DOM can be a great foundation to build advanced applications; too many frameworks (especially MVC frameworks) try to bring native/widget patterns to HTML rather than rethinking the way the DOM environment can be extented into a MVC platform. Frameworks that shield the application code too much from HTML tend to make the application much more difficult to customize, enhance, and optimize down the road (i.e., easy to start, difficult to finish). A good understanding of HTML, CSS, and JavaScript is always required to build high-end HTML5 applications; thus, libraries and frameworks that embrace HTML are better than those that try too hard to shield you from HTML coding.

• Avoid touch or mobile only frameworks (i.e., avoid device-specific HTML5 frameworks) because having different technology stacks per HTML5 device type removes the core benefits of HTML5. Yes, an application might have a different façade or even behavior depending on form factor and input type (usually a mobile phone on one side, and a tablet/PC Web on the other), but it should not (must not) require two different tech stacks, let alone rewriting the application twice. Writing two applications, one for Touch and one for PC Web, does not make sense, especially when you consider that the appropriate split is often between a smart phone on one side and a tablet/PC on the other. In other words, Touch is just another input mechanism and should not be a factor in splitting the technology stack or application code.

Following these two main principles, here are list of good technologies to use versus riskier ones.

• jQuery (core) is a very mature and efficient way to query, access, and modify the DOM. jQuery is not a framework but more of a DOM DSL (domain specific language). Because jQuery is a lower level and well optimized, it works great for mobile, tablets, and PC HTML5.

• Bootstrap (formally Twitter/bootstrap) is a very well thought out HTML/CSS structure with default styling that is the perfect basis for starting small or large scale HTML5 applications. It also decouples HTML/CSS from JavaScript well, which allows implementation of completely custom behavior while re-using the bootstrap HTML element structure and style.

• lesscss or SASS are both efficient and flexible ways to componentize your CSS into reusable “macros.” It does so by extending the CSS language rather than replacing it. Bootstrap uses LESSCSS extensively, and for advanced applications, it is a great way to write advanced and reusable CSS directives while keeping the HTML structure clean and simple. Bootstrap also provides a very useful set of mixins in their “mixins.less,” which could be a great time (and bug) saver for common CSS3 directives. SASS is similar and is a good technology as well, but we are not using it because of its Ruby dependency and the fact that Bootstrap chose LESSCSS. LESSCSS is JavaScript-based, which is great for client-only development as well for Java Server integration (Snow supports .less automatic server side compilation and caching).

• brite.js is a lightweight DOM Centric MVC that turns the DOM environment into a simple and powerful MVC foundation. It has a similar approach to backbone.js, but it is more tailored to high-end applications as it provides a fully asynchronous view life cycle as well as a powerful and asynchronous DAO model.

Disclaimer: We are the creators of brite.js, which we have been using for the last 3 years to build high-end HTML5 applications. We finally had time to document it. If you have any question, feel free to drop a line below or on any of the brite pages; we always respond within a few hours.

On the other hand, based on our experience, here are the more high-risk HTML5 technology and JavaScript Frameworks:

• Sencha Touch or Sencha ExtJS: While both of these frameworks might look fancy and attractive, Sencha breaks both of our guidelines. First, both are mega-frameworks that redefine everything from UI, Layout, and even OO in JavaScript. Consequently, they remove the application code too much from HTML, CSS, and JavaScript. The result is a highly framework-dependent application code that can be very difficult to optimize and maintain overtime, even if it was fun at the beginning. Second, it also breaks the “avoid device-specific HTML5 framework” guideline. This is likely the most important reason why a developer should use caution in selecting this type of framework.

• jQuery Mobile and jQuery UI: Like the Sencha frameworks, these also break the “avoid device-specific framework” guidelines. Second, although they both seem more HTML-oriented than Sencha frameworks, their design relies on a heavy post- HTML processing and CSS class manipulation, which significantly impacts application performance as well as styling and customization. We also found that jQuery Mobile has some serious design flaws, such as the page model, which makes writing large-scale responsive applications very difficult.

• Ember.js and Angular.js: Both of this frameworks share the same “binding-aware templating” approach, and though we find them interesting, we think they actually promote bad patterns to build HTML5 applications for the following two reasons. First, this type of framework places too much responsibility on the templating side, which ends up commingling the responsibilities (e.g., Model, Data, Binding, and View) into one layer. Good code design is about good partitioning, and moving all the complexity from one side (JavaScript) to another side (templates) does not really solve the code complexity issue and can actually make it worse (templates become very difficult to read and maintain). Second—and this is especially true for Angular.js as it is a bigger framework—they tend to remove the application code far from the DOM, and while it might look attractive at first, we think a good understanding and control of the DOM is the crux of writing good HTML5 applications. It is one thing to have an application declarative UI language such as “Adobe Flex” in a Flash, native, or even Java environment, but bringing it to the DOM is like fitting a round peg into a square hole. You could make it fit, but it is not the most efficient way to go about it.