Towards a HTML5/JavaScript-based framework

Usage of JavaScript MVC framework is the real game changer. We need a new approach to templating and bi-directional data binding in a powerful and easy way to use.

The balance is undeniably moving from traditional server-side templating to JavaScript templating. We need getting objects and data back from intermittent RESTful or WebSocket connections, which are automatically bound to the UI through the client-side, JavaScript framework. Moreover,  applications  must have the ability to occasionally synchronize data and the power to function offline.

So, the JavaScript frameworks give us a nice way to organize and structure the app code, we must deal with browser APIs that expose hardware-level access, such as Geolocation or Web Workers, on our own.

The HTML5 framework has been planned as a piece of engineering with a strong emphasis on management, versatility and code quality. Furthermore, even promoting  better practices for the entire JavaScript ecosystem. Given the quality and novelty of this programming trend, it is not surprising to see that many developers are attracted to the bunch of frameworks and tools in the JS ecosystem, creating a very vibrant and supportive community around them, which contributes to its growing popularity. This is a guarantee for future evolutions and support. We mean, we are in the right way!

The conclusion is, we need a faster way to develop client-side applications including support of HTML5 as well as many other features. I would like to include here some of the most important aspects among them:

1-BaaP: The Browser as a Platform
The main factor in mind has been the browser as the platform where the applications run.
The web browser is becoming, or already is, an additional platform for new  complete application stacks. HTML5, the Open Web, and mobile devices have helped  push the browser-as-a -Platform forward, giving browsers the capabilities of storing  data and running applications in an offline state. So, the browser is now the scope and the space where applications are working, exploiting the HTML5 features as well as the ECMA6 / V8 JavaScript engines depending on the browser engine where the app is being runned.

2-Cross Browser Compatibility
Applications must run fine on all known browsers. The crucial aspect here is the list of available features and how the application is actually doing through the Framework’s Common API. Considering the browser panorama, the main purpose of this API is do whay is possible be done, and never fail.

4-Device Detection / Feature Detection
The first step in delivering new HTML5-based features to developers is actually
detecting what the browser supports. The framework needs to communicate with the browser to check what it supports before the page is rendered. In common applications we must detect
and parse the—sometimes unreliable—browser userAgent (UA) string and then assume
we have the correct device. Today, such libs as Modernizr.js or just simple Java‐
Script, help us detect client-side capabilities at a much more finely grained level.
Which detection method is best?

·         Client-Side Feature Detection
·         Client-side userAgent Detection
·         Server-side userAgent Detection

Anyway, device detection in modern developments is mandatory. The Framework’s Common API handles the style components, views and layouts to obtain the best adaptation to the detected device.

5-Real Time communication
Current requirements often include server push features. The user must be continuously updated with changing data from backends. So, the Framework’s Integratin Layer provides the application with a robust efficient websocket client. The fallback is based on different flavours of Reverse AJAX based on Definitively, graceful degradation is mandatory in order to guarantee real-time comm in oldest browsers.

6-Graceful Degradation.
This concept consists of the process of falling back to use older technologies  within the browser if the most appropriate option is not supported. It is a common concept in the Framework conceptualization.

It is mandatory for new web applications the overcoming of the old constraints due to limits of the oldest browsers (e. g. Internet Explorer 7 and 8). The framework automatically includes conditionals in views in order to respond to each specific browser and version.  Libraries as Modernizr are fully integrated in the common API and included as dependency in the package list. So, a graceful degradation of features is possible without any additional action by developers. The Framework selects certain ways depending on the, type of browser and version as well as available browser features. Then, the way the application implements the given functionality is depending on those factors.

Basically implemented by using webworkers, the framework’s Common API generates components basd on them to implement code in a multithreaded mode.

The Web Workers interface handles operative system  threads, allowing the data are passed back and forth between any given thread (or worker). Furthermore, because communication points between threads are carefully controlled, concurrency problems are rare.  
The framework generates worker scripts as external files with the same scheme as their calling page (we could not load a script from a data URL and an HTTPS page cannot start worker scripts that begin with HTTP URLs).

8-Asynchronous programming
Understanding the asynchronous JavaScript event model is a must in the most of JavaScript-based projects. The common API solves this issue by encapsulatirng in custom directives the handling of events.

9-Network Type Detection
Client-side application development gets extremely sensitive to online/offline modes and connection speed. Enter the Network Information API. With it, we can get extremely valuable information for a  multi-device web app:
·         Provides offline access through applicationCache
·         Detects if bookmarked and offline
·         Detects when switching from offline to online and vice versa
·         Detects slow connections and fetches content based on network type

So, the framework adapts its features according to the detected network and its capabilities. This type of adaptative features are very important for mobile environments.

We want a concurrent, asynchronous approach when fetching and caching pages. Because it is well supported in the most of devices, we would need to use localStorage, which unfortunately isn’t asynchronous. Furthermore, it is size limited.
Unfortunately, because localStorage uses UTF-16 for character encoding, each single byte is stored as 2 bytes, bringing our storage limit from 5MB to 2.6MB total. Fetching and caching these pages/markup outside of the application cache scope allows you to take advantage of all the storage space provided by the device.
The common API makes an abstraction of the different cache options (they can be pre-selected or not ) by checking, for example,  if web storage is supported. In this case, it abstracts the web storage support by hiding or not the inclusion of this feature.

2-Working Areas

The framework involves a lot of considerations and aspects to be included as an esential part of the tools to be designed and developed.
The below diagrams try to reflect the different roles and areas to develop:

All of these working areas are the target and scenario of the framework development. The next section tries to explain the overall architecture regarding of considered architectural components and integration ways.

3-The Proposed HTML5 Framework Plan

It is time to consider the real nature of the components to be integrated in the HTML5/JavaScript Framework, towards the creation of a development environment as complete as possible.
The main part of this environment is AngularJS. Its main features makes it the most appropriate MVC. Dependency Injection, directives , transclusion, etc are good factors that makes AngularJS an excellent candidate.

In the above diagram some discordances can be appreciated. For example, someone could say “AngularJS is a an MVC Framework while JQM handles concerns related to direct UI manipulation”. It is really true.  In this case the objective is include Mobile features in AngularJS. We will talk about this issue below, but we shoud consider three fundamental factors before:

A-The HTML5/JavaScript API
But the main issue is the Common API. This is a custom JavaScript API whose main features are focused on abstraction for an easier development:

·         Abstraction of HTML5 features support.
·         Abstraction of multithreading through the construction of webworkers.
·         Abstraction of the integration layer, discoupling the application code from the components that actually are concerned to communicate to backends.

B-Project Management
Moreover, the framework is not only pieces of code. It uses specific methodologies based on:

·        Dependencies Management with NPM
·        Package Management with Bower
·        Build Process with Grunt
·        Code Review wuith JSHint
·        Testing environment with Karma, PhantomJS and  Jasmine.

Regarding of testing, it is mandatory the full integration of test frameworks to eradicate the absence of testing in this type of projects. The framework needs an orchestration of the test components (the components that test the application components) as well as allowing TDD practices during the development. This means we need to test our components directly in several types of browsers, manage other types of unit testing as Jasmine or Qunit, it must be able to work on a CI server and injected as dependency in whichever component. The chosen solution has been Karma. Karma is fully integrated in the generator.

Moreover, it is remarkable the role of NodeJS as a true site testing environment.

C-How to glue all these different parts?

The Glue: the Framework’s Custom Common API, based on several pillars:
1.       Injection of behaviors in Views -> Custom AngularJS Directives
2.      Using the custom common API  -> Injecting them as dependencies (AngularJS DI) + Transclusion
3.       Package and dependencies management system. External (Third Party and Custom) libs are included in the project scope by including them in the package management configuration.

The most used way of using them together is create custom reusable directives that will add "JQM nature" to views, for example. In this case, we can create a directive that will convert a standard UL element  to a more adapted JQM list. The good thing about doing this in directives and not within your view is that the UI code is separated in separate modules and not intermingled with business logic.

For developers, the most interesting thing is programming against a common API. By using this API they can:

  • Programming for all modern browsers. No more browser-specific code.
  • Use the API's injected objects to implement encapsulated features like multithreading, asynchronous processing, web storage, server push, etc. The framework will adapt the code to each given scenario considering browser type, the device and the network.
  • Easily importing third-party or other custom libraries by modifying the package configuration file.
  • And many other things...