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 Socket.io. 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.
7-Multithreading
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.
10-Caching
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.
For developers, the most interesting thing is programming against a common API. By using this API they can:
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...
Comments
Post a Comment