Whitepaper The Modern Web Stack PDF

The Modern Web Stack
A Taxonomy of Front-End Technologies As An Aid To Decision Making
Summer 2014
Sencha, Inc.
Introduction
The two biggest drivers of change in business computing today are multi-device computing and cloud. Multi-
device and cloud are driving a rapid evolution in application architecture toward more powerful front-ends and
more flexible back-ends. Mobile devices are becoming important gateways to business data and applications.
And cloud back-ends – often implemented as rich API service points – are fast becoming the back-end
complement to this new wave of applications.
In the last five years, there has been an explosion of innovation in web and native technologies, with rapid
releases of libraries, frameworks and tools to help developers create applications for this new world. On the
back-end, Node.js, a stripped-down event machine written in JavaScript, has become the foundation for
developers adapting their server back-ends to the new multi-device world. On the front-end, there has been a
Cambrian explosion of new experimental libraries to help web and native developers create the next generation
of user experiences.
The New Architecture

Many organizations have spent enormous amounts of time and effort creating development processes and
building skills centered on traditional Java application servers. Sometimes, they find it hard to believe that these
investments are now entering obsolescence. In many people’s minds, the first question is “why do we need to
change?” Simply put, mobile computing requires a new architecture.
The great wave of desktop web applications built in the 2000s shared a common thin client architecture.
Heavyweight application servers like Oracle WebLogic served up complete pages to the browser, and all
application interaction was performed as page requests and responses. The entire application workload was
performed on the server-side: all the data management, all the integration, all the business logic and all the
HTML and CSS generation. While there was some page interactivity using JavaScript, it was minor. This was
for three good reasons: browsers were primitive page viewers with very slow JavaScript engines, desktop
browsers rarely went offline, and it was easier to think about security when everything happened on the server.
However, the shift to mobile computing and the rise of HTML5 browsers means that two out of three of these
reasons are no longer valid. Mobile apps need to work offline, and browsers (and native mobile OSes) have
become vastly more capable. In today’s state of the art applications, much of the business logic and data
handling that used to take place on the server, now takes place on the mobile device. And mobile application
experiences are vastly richer than anything that static page serving could ever accomplish.
1 1700 Seaport Blvd. Suite 120, Redwood City, CA 94063 1 (800) 212–2802 www.sencha.com @sencha
Yesterday Today
Browser Native &

Page Display User Interface
HTML 5
Interface
Management
Logic & State
App Server Data

Page Generation
Logic & State
Cloud
Data APIs
Integration Integration
Figure 1: Web 1.0 vs. Multi-Device Architectures
In today’s application architectures, a rich client – whether HTML or native – talks to a thin cloud back-end. The
mobile device talks to RESTful APIs in the cloud, sending and receiving JSON objects. This architecture shift is
behind the new generation of applications that are stateful and data-rich, with fast user response. These multi-
device applications run both on our new mobile devices, our existing desktop browsers and our new tweener
devices like keyboard-enabled tablets and phablets.
These applications have fast response to user interaction because they store large amounts of data locally,
either in memory or persistently in a local data store. This enables searching, sorting, filtering and grouping data
(e.g. database records) without having to make a round-trip to a server to fetch new data.
These applications are also far more stateful than Web 1.0 apps. They allow the user to navigate through
content and data presented across multiple screens and sub-screens and to engage in multi-step transactions
without requiring a new page to be requested from the server. What this means is that these applications are
extraordinarily data-rich, allowing the display and manipulation of large data sets in multiple ways – either
through classic data grids, or more advanced visualizations.
“Everyone, start your editors!”

While it can be exhilarating for a developer to simply crack open Eclipse or vi and start coding these applications
against this pattern immediately, it’s extremely valuable to stop and reflect on all the implications of this new
app model in the context of the applications that your development teams need to plan, architect and deliver.
This is particularly true if you’re managing more than just yourself. The average business has to create working
practices for managing the lifecycle of these applications with tens, if not hundreds of developers working on
hundreds to thousands of screens. Those screen experiences can be built on top of hundreds of thousands
of lines of code and millions of data records. It’s potentially an extremely serious undertaking (some Sencha
customers have five year migration timelines for upgrading their applications to the new architectural pattern).
So it’s a good idea to step back and simply think about all the moving parts that make up our next generation
runtime.
The Front-End Development Challenge
• Create appealing themes and styles for interactive elements

Interface • Present complex data using structured presentation elements like grids and charts
Elements • Create a standard visual vocabulary across apps
• and more…
• Dynamically lay out screen elements in response to different screen sizes and resizes
View • Detect and respond to touch gestures beyond simple taps
System • Swap in local language strings, handle RTL languages and keep everything accessible
• Animate content and more…
• Update the screen when data changes and vice versa

Logic & • Remember application states to enable undo/redo as well as navigation
Data • Search, sort, filter, group and validate data
• and more…
• Handle asynchronous calls to the server-side

Server i/o • Parse and convert serialized data
• Call out to server-side code
• and more…
Figure 2: Common Challenges in Front-End Development
Most multi-device applications have a set of common challenges that we can (somewhat arbitrarily) divide into
four separate categories.
1. Screen design: Creating and arranging the user interface – the look and the behavior of your application
content including widgets, charts and grids.
2. View management: Structuring and managing the view machinery such as the layout and interactivity of
your screen elements, as well as handling user requirements such as foreign language, or right-to-left
languages like Arabic. Plus, handle the core problem of multi-device – building applications that work on
both desktop screens with mouse input and mobile screens with gesture interactions.
3. Data and code management: Updating the screen when the data changes, and updating your data when
the user gives you input.
4. Communicating with the back-end and server-side.
Cutting across all these challenges is the need for modularity and encapsulation at multiple levels of your code,
so multiple developers and development teams can effectively collaborate – leveraging each other’s work
without stepping on each other’s toes.
A Front-End Taxonomy
Native development technologies have long provided solutions to these problems. Looking at native runtimes
like the Cocoa framework for Apple platforms, the Flex framework for Flash development, or Windows
Presentation Foundation for Microsoft platforms – we see a surprisingly similar set of solutions to the problem
of creating rich client applications. Each of these technology platforms offers similar kinds of capabilities in
similar chunks.
Basic Widgets Compound Widgets Visualizations

buttons, bars, text fields… trees, grids, gauges… charts, infographics
Interface
Elements
Containers Themes Styles
panels, cards, modals…
Layout Manager Interactions Drawing Theming

absolute, flexible gestures, drag & drop vector, bitmap computed styles
View
System
Templating Visual Effects Localization Accessibility
iterations, conditionals animations, filters… RTL, locale libraries focus manager, ARIA…
State Manager Data Binding Modularity Testing

history, undo, routes… 1-way, 2-way components, modules IOC, test hooks
Logic &
Data
Data Objects Data Models & Stores Persistent Data Mulitimedia
queues, hashtables group, sort, validate cache & sync 3D, audio, video
Server Calls
Server i/o asynch, conversion Server Method Invocation 2-Way Data Server Notifications
Base Services Rendering, DOM, fonts, parallelism, security, media decode, sensors, printing, network i/o…
Figure 3: Taxonomy of the Front-End Stack
Between the built-in capabilities of the system libraries and their frameworks, native platforms offer you a rich
basket of tools to help structure your application, automate common development tasks and make great
looking applications. In Figure 3, we show a generic model of the front-end stack. As a model, this is an
obvious simplification of the way that the real code is structured. For example, a module system isn’t strictly a
separate piece of code; it’s the way that all code is organized. Nevertheless, we’ve found it to be a helpful way
to organize front-end functionality and map out the capabilities of various front-end technologies.
Interface Elements


• Basic widgets include the essential display elements of an application including text areas, buttons,
form elements, progress and loading indicators, menus, etc.
• Compound widgets include complex display elements that display more than one data value or include
multiple sub-controls such as a data grid, a nested list or a multi-level file display.
• Visualizations include data-driven graphics elements such as charts, graphs, waterfall charts and other
diagrams.
• Containers act as holders for widgets and content and include scrollable displays like nested panels,
card-based displays like carousels and modal containers like alerts or wizards.
• Styles include font size, shadowing and other visual effects that are properties or attributes of the
content or widget set.
• Themes are collections of style, and graphics assets that give a coherent look and feel to the
application. They can be expressed in terms of a theming language or system that is distinct from the
style language.
View System


• Templating is a capability that converts placeholders into final content through the application of a rules
set. Complete templating systems allow simple or complex conditionals and iterations and even full
functions.
• Layout Manager applies a series of layout rules to determine the arrangement of screen elements in x, y
and even z space based on window size, device type and resolution.
• Interactions are a set of capabilities that help convert raw system events (e.g. touchstart) into gestures
that an app developer would like to use – e.g. a scroll gesture. We also put drag and drop enablement
into this category.
• Visual effects are an umbrella term for property animations and visual transformations such as blurring,
recoloring, desaturation, etc.
• Drawing APIs provide an abstraction above raw drawing primitives. If the platform’s primitives are rich
enough, they may be unnecessary. Compositing operations like clips, masks, blends, etc. may be
considered drawing APIs or could equally be considered visual effects.
• A theming system provides a way to apply a collection of styles and assets as a whole to an
application. It can also provide computed style properties.
• Localization capabilities allow text strings and application messages to be swapped based on the
application locale. Although we show localization as a separate brick, it’s usually baked into many
things across the stack. Thorough localization also implements localized data formats for time, date,
etc., as well as localized sorting rules for data and text and adjusts widget layout & composition based
on whether the language has right-to-left writing order.
• Accessibility is another capability that is baked into many items of the stack, and provides facilities such
as keyboard navigation, screen reader compatibility and high visual contrast themes for the visually
impaired.
Data & Logic


• State management facilities help application developers manage state consistency in applications that
lend themselves to a state machine model. Undo/redo facilities, navigation stacks, and transactional-
style all-or-nothing data commits fall into this category.
• Data objects such as collections, trees, queues and graphs are often provided to a sufficient level by
standard language libraries. But in cases where these are lacking, the front-end stack needs to supply
them, or the developer needs to write her own from scratch.
• Data binding provides easy change synchronization between in-memory data variables and the screen
elements that depict that data. It saves the developer from writing explicit change management code.
• Data models provide in-memory data structures that store the application’s working set. Well-featured
models provide database-style functionality for sort, search, filter, validate and group. They also can
provide help for serialization and deserialization from wire formats.
• Modularity is an umbrella term for the capabilities of the stack that help individual developers and
development teams to structure code and manage dependencies. It doesn’t refer to a single piece of
identifiable code, but it covers capabilities like object namespacing, architectural patterns like MVC,
component models and module/package systems.
• Persistent data are capabilities built on top of the raw file read-write that help store, cache and sync
application assets and data locally.
• Testing enablement includes capabilities that facilitate automated unit and system testing, such as error
logging, event replay and ensuring that all application events can be triggered by external scripts.
• Multimedia capabilities include the ability to embed and customize system video and audio playback
within an application and to control playback, read metadata and control captioning.
Server Communication
Server Calls Server Method Invocation 2-Way Data Server Notifications

asynch, conversion
• Provides applications with server-side communication facilities for request/response, full-duplex, and
server push data communication. Typically server communications are provided by system libraries,
but in the special case of web technologies, raw socket communication is prohibited by the browser
sandbox model and only higher level facilities like XHR and web sockets are provided.
This taxonomy doesn’t include capabilities that are normally provided by the operating system such as font
rendering, threads or sensor APIs, so their browser analogs (web fonts, web workers, geolocation, etc.) are
not included in the taxonomy either.
Applying the Taxonomy to the Web Platform
When we take this taxonomy and apply it to the web platform, the results are quite enlightening. In particular,
when we look at the pre-HTML5 web platform, we can see how few capabilities it offered. In pre-HTML5
browsers, if you wanted solutions to practically any problem, you had to build almost everything from the ground
up or use non-browser plugins for capabilities like graphics, video and full duplex server communications.

Interface
Elements

View
System

Logic &
Data
Server Calls
Server i/o asynch, conversion Server Method Invocation 2-Way Data Server Notifications
The Pre-HTML5 web platform offered a limited set of widgets, some styling and layout capabilities, and request/
response http calls. That’s it. It’s amazing to think that the entire first generation of web applications was built
on such a tiny foundation of browser capabilities.
With the recent arrival of HTML5 browsers, the platform offers many more capabilities:
• Canvas, WebGL and SVG have given us 2D and 3D graphics, bitmap and vector
• HTML5 inputs give us range sliders, color pickers and expanded date/time inputs
• CSS animations and transitions have given us motion graphics
• Web sockets provide full-duplex server communication
• And many more capabilities
Range, Color Picker, Date/Time, Compound Widgets Visualizations
Progress, Telephone trees, grids, gauges… charts, infographics
Interface
Elements
Containers Themes Gradients, Border Radius
Theming
Flexbox, Multicolumn Drag & Drop SVG, Canvas computed styles
View
System
Templating Animations & Transitions, Localization WAI - ARIA
iterations, conditionals Filters RTL, locale libraries
Data Binding Modularity

History Push State Web Timing API
1-way, 2-way components, modules
Logic &
Data
Data Objects Data Models & Stores Local Storage, Indexed Video, Audio, WebGL
queues, hashtables group, sort, validate DB, App-cache
Server i/o XHR2 Server Method Invocation Web Sockets Notifications
Figure 4: HTML5 Capabilities in our Front-End Taxonomy
Although HTML5 has given us many new things, as we can see from Figure 4, the front-end web stack remains
incomplete compared to native platforms. We won’t go into an exhaustive list of platform gaps in raw HTML5,
but here are just a few examples:
• Layout Management: HTML5 introduced Flexbox, which provides comprehensive one- dimensional
layout. However, its implementation is slightly different in older webkit browsers, Internet Explorer 10
and current Chrome and Safari. Gridlayout, a 2D layout manager is still only implemented in Internet
Explorer. HTML5 also introduced Multicol, which allows text to be columnated automatically, but only in
columns of equal width.
• Interactions: HTML5 introduced support for recognizing touch events, but this was implemented
differently in Internet Explorer (pointerEvents) and other browsers (touch events). In addition, while
HTML5 added a drag and drop API, it is based on the Internet Explorer 5 Microsoft drag and drop
API which has too many events, plus defaults that always have to be overridden and very noisy event
bubbling among other problems.
• Data Binding: HTML5 did not add support for any kind of data binding (although a very basic form of
data binding was introduced in Internet Explorer 4 and later scrapped).
While some browsers have added features to fill some of these gaps, these features have not been adopted
widely. For example, Chrome’s web components proposal includes partial support for templates and a basic
(if somewhat convoluted) component model. Chrome also, uniquely, has support for files and directories per
application domain. And Adobe’s Regions proposal for complex cross-element text flow is partially available in
Internet Explorer and Safari, but not Chrome. In summary, as of mid 2014, there are significant gaps remaining
for a development team that wants a complete front-end development stack. And there is little expectation that
these gaps will be filled in the near term.
JavaScript to the Rescue
Fortunately, since JavaScript first shipped back in 1995, scripts, frameworks, libraries and preprocessors have
been developed to augment and expand browser functionality. And with the rise of code sharing sites like
GitHub, the explosion of libraries and frameworks has continued apace, not just for JavaScript but now for
CSS as well. As of Spring 2014, GitHub had over 1.2 million public JavaScript repositories.
The new problem for development teams is not finding a library to fill a gap, but which library to use. And most
important, choosing a front-end strategy that suits their app portfolio, their skill base and their deployment
requirements. One of the major decisions for a development team manager is whether or not to self-support:
98% of GitHub repos are never updated after their first anniversary, which makes self-support a fact of life for
teams choosing to use a collage of public resources.
Assessing The Landscape

We often see blogs or tweets on the subject of “what’s the best framework” or whether a developer should use
library x or y. But experienced development teams know that these are misconceived questions. We believe
that the right question for development teams to ask in all of these cases is:
• Given the kinds of app experiences we want to build…
• And the language and skills of our development teams…
• And our app’s maintenance lifetime…
• And the browsers we need to support…
• And the size of our development teams…
• And whatever additional requirements we may have...
What is the best framework and library for this app portfolio and for this development organization?
For certain kinds of application experiences, for example, a pure content application targeting modern browsers
written and maintained by a solo developer, the answer may be that no framework is needed at all. On the
other hand, for a portfolio of complex and interdependent apps developed by a large and changing team, the
answer may be to standardize on a single framework across the organization.
With those thoughts in minds, next we take a look at how the most popular frameworks and libraries stack up
compared to our front-end taxonomy. With a good map to the framework capabilities, it’s easier to answer the
question of what is the best framework for your teams.
A Quick Overview of Framework and Library Stereotypes
Below is a selection of the most visible frameworks and libraries with high visibility in the web app development
community.
Name Description
Bootstrap + Plugins CSS framework for responsive web sites
Backbone + Underscore Minimalist architectural framework + utility data classes
Angular JS HTML-based architecture package for modern browsers
Ember + Handlebars Highly structured architecture framework
jQuery + jQueryUI Easily learned, unstructured UI libraries
Ext JS + Deft.js Highly structured, full stack framework
Figure 5: Major Development Frameworks and Libraries
• Bootstrap is a CSS framework that provides interface elements and some view management
capabilities like theming and layout. It’s become very popular for websites that primarily display content.
• Backbone.js is a minimalist MVC package with some data manipulation capabilities provided by
Underscore. It provides no interface elements or view management capabilities.
• AngularJS describes itself as a toolkit for creating frameworks. It provides an MVC structure with a rich
HTML-based templating system that allows widgets to be created declaratively using markup.
• Ember is an opinionated MVC package that provides object and data binding and a full component
model.
• jQuery + jQueryUI is a classic combination that provides interface elements and some view
management capabilities, but without any architectural or data handling capabilities
• Ext JS + Deft JS is a full front-end JavaScript development stack with the Deft JS library providing
inversion of control capabilities to enable easier testability.
Apart from Ext JS, each of these frameworks or libraries tackles a piece of the development stack front-end.
AngularJS, for example, assumes that something else will be providing the interface elements and most other
elements of the view system. And Backbone.js assumes that most of the stack will be coming from somewhere
else. In fact, when we compare each of these frameworks and libraries to our front-end taxonomy, it becomes
far more clear what each provides and what each is missing. Below in figure 6, for example, we show where
Bootstrap provides functionality.
Interface
Elements
Containers & Windows Themes Styles
Layout Manager Theming

Drag & Drop SVG, Canvas
responsive grid computed styles
View
System
Templating Visual Effects Localization WAI - ARIA
iterations, conditionals animations, filters locale support

State Manager Web Timing API
Logic &
Data
Server Calls
Server i/o asynch, conversion Server Method Invocation Sockets Server Notifications
Support Key None / HTML5 Partial Complete
Figure 6: Bootstrap Functionality Map
When we map out functionality for the other popular frameworks (on the following pages), we see that all of
them concentrate mostly on structuring application logic rather than managing the interface. Most of them
assume that you’ll be writing your view management and interface elements yourself.
An alternative approach is to assemble the full stack from various libraries. While this provides the most
customized solution, there are a number of problems with this strategy. Without a common architecture or
coding style, testing and maintaining the stack becomes difficult. Each library can bring a subtly different
interpretation of ostensibly similar functionality. And most important, the development team will face multiple
release cycles that are unsynchronized with each other. Not to mention the risk that a vital piece of the stack
will be abandoned by its maintainer.
With AngularJS applications that want to use d3 for visualization, for example, developers face a completely
different data binding approach, lack the ability to share a theme, and have no common object model or class
system, making it extremely difficult to synchronize changes in grids and charts. It’s easy to see how such
solutions can become franken-frameworks.
Interface
Elements

View
System

Logic &
Data
Server Calls
Figure 7: AngularJS Functionality Map

Interface
Elements

View
System

Logic &
Data
Server Calls
Figure 8: Backbone.js functionality map
Interface
Elements

View
System
iterations, conditionals animations, filters RTL, locale support focus manager, ARIA…

Logic &
Data
XHR
Figure 9: jQuery + jQueryUI Functionality Map

Interface
Elements

View
System

history, routes 1-way, 2-way components, modules IOC, test hooks
Logic &
Data
XHR
Figure 10: Ember Functionality Map
The Ext JS Stack
Compared to the libraries and toolsets we’ve just seen, Ext JS provides a more complete framework. It offers
a very broad selection of basic and compound widgets (over 150), a high level visualization package as well
as a lower level drawing API; a rich package of containers and themes, and a well-thought-out view system. It
also offers an architectural package for MVVM and MVC, ARIA support, RTL support and more, all with a single
coding style. Field-proven in the enterprise and ISV markets over the past five years, all these capabilities are
engineered and tested to work together, professionally maintained and updated in a synchronized fashion, and
backed by a customer support team.

Interface
Elements

absolute, flex… gestures, drag & drop vector, bitmap computed styles
View
System

history, routes 1-way, 2-way components, modules IOC, test hooks
Logic &
Data
Data Objects Data Models & Stores Persistent Data Multimedia
queues, hashtables group, sort, validate extension 3D, audio, video
Server Calls Sockets

Server i/o asynch, conversion Server Method Invocation extension Server Notifications
Figure 11: Figure 11: Ext JS Functionality Map
In fact, in the few places where Ext JS lacks functionality, the framework enables your development team to
extend it in ways that allow your code and the framework code to work together. For example, if the built-in
layouts don’t cover your design case, you can write new layouts, and the new layouts will behave exactly as a
built-in layout. Also, there are a wide variety of themes, compound widgets and other extensions available from
Sencha partners on the Sencha Market website. Whether you use standard components, extend the standard
components yourself, or use extensions from Sencha Market, you always get predictable results, and this
makes application development, testing, and maintenance much simpler.
It’s also worth pointing out a few areas where alternatives really don’t provide good options. Ext JS offers a great
selection of data classes like key-value stores and hashmaps. Ext JS also provides good state management at
the data level, allowing transaction-like behavior through the session class. Ext JS not only helps developers to
manage application data, but also gives them powerful tools for enabling users to interact with data to make
timely business decisions. For example, the Ext JS data grid is a best-in-class compound widget for high
performance, sortable, filterable presentation of large datasets in a tabular format. These data management
and presentation capabilities are especially important in organizations that build data-centric applications for
users, such as highly expressive analytical applications and reliable transaction processing systems.
Areas for Growth and Development

It’s worth noting that no framework currently offers good support for management of audio and video playback
or server notifications, relying instead on the basic HTML5 capabilities in these areas. In addition, although
there are a small number of WebGL libraries available for 3D graphics rendering (including PhiloGL from Sencha
Labs), mainstream offerings have given little attention to this functionality.
One important area not covered in our framework functionality maps is browser support. Many frameworks
have an “evergreen” support model for only the most modern browsers. This clearly makes it easier for open
source projects and vendors to build and test their products, but for many organizations, support for only the
most recent versions of browsers is entirely inadequate. In contrast, Ext JS supports the broadest range of
browsers of any framework, including support back to Internet Explorer 8.
“The Right Technology Stack”

Your choice of front-end technology stack depends on the type of applications you want to build and the
nature of your organization – whether a one-person freelance shop or a Fortune 500 development organization.
Although not perfect, we hope that this taxonomy of front-end technologies has shed light on the various
building blocks of a front-end development stack, and illuminated where some of the most popular alternatives
provide functionality and where they lack. If you found this information useful and would like to discuss your
alternatives with Sencha, please contact us. We’d be happy to discuss your choices.
Learn More
For more information about how Sencha can help you leverage HTML5, visit www.sencha.com. You can also:
• Talk with other web developers and Sencha experts on our developer forums www.sencha.com/forum
• Sign up for training sessions on our frameworks and tools to jump-start
development www.sencha.com/training

Whitepaper The Modern Web Stack PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Whitepaper The Modern Web Stack PDF

Uploaded by

Copyright:

Available Formats

The Modern Web Stack

A Taxonomy of Front-End Technologies As An Aid To Decision Making

The New Architecture

Browser Native &

Logic & State

App Server Data

Logic & State

Figure 1: Web 1.0 vs. Multi-Device Architectures

“Everyone, start your editors!”

The Front-End Development Challenge

• Create appealing themes and styles for interactive elements

• Update the screen when data changes and vice versa

• Handle asynchronous calls to the server-side

Figure 2: Common Challenges in Front-End Development

Basic Widgets Compound Widgets Visualizations

Layout Manager Interactions Drawing Theming

State Manager Data Binding Modularity Testing

Figure 3: Taxonomy of the Front-End Stack

Basic Widgets Compound Widgets Visualizations

Containers Themes Styles

Layout Manager Interactions Drawing Theming

Templating Visual Effects Localization Accessibility

Data & Logic

State Manager Data Binding Modularity Testing

Data Objects Data Models & Stores Persistent Data Mulitimedia

Server Calls Server Method Invocation 2-Way Data Server Notifications

Basic Widgets Compound Widgets Visualizations

Layout Manager Interactions Drawing Theming

State Manager Data Binding Modularity Testing

Data Binding Modularity

Server i/o XHR2 Server Method Invocation Web Sockets Notifications

Figure 4: HTML5 Capabilities in our Front-End Taxonomy

Assessing The Landscape

Figure 5: Major Development Frameworks and Libraries

Layout Manager Theming

Data Binding Modularity

Support Key None / HTML5 Partial Complete

Figure 6: Bootstrap Functionality Map

Layout Manager Theming

Data Binding Modularity

Support Key None / HTML5 Partial Complete

Figure 7: AngularJS Functionality Map

Basic Widgets Compound Widgets Visualizations

Layout Manager Theming

Data Binding Modularity

Support Key None / HTML5 Partial Complete

Figure 8: Backbone.js functionality map

Layout Manager Theming

Data Binding Modularity

Support Key None / HTML5 Partial Complete

Figure 9: jQuery + jQueryUI Functionality Map

Basic Widgets Compound Widgets Visualizations

Layout Manager Theming

State Manager Data Binding Modularity Testing

Support Key None / HTML5 Partial Complete

Figure 10: Ember Functionality Map

Basic Widgets Compound Widgets Visualizations

Layout Manager Interactions Drawing Theming

State Manager Data Binding Modularity Testing

Server Calls Sockets

Support Key None / HTML5 Partial Complete

Figure 11: Figure 11: Ext JS Functionality Map

Areas for Growth and Development