Whitepaper the Modern Web Stack

5/24/2018 Whitepaper the Modern Web Stack

1/16

The Modern Web StackA Taxonomy of Front-End Technologies As An Aid To Decision Making

Summer 2014

Sencha, Inc.


2/16

1 1700 Seaport Blvd. Suite 120, Redwood City, CA 94063 1 (800) 2122802 www.sencha.com @sencha

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 andmore exible 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 ve 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 nd it hard to believe that these

investments are now entering obsolescence. In many peoples minds, the rst 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 ofine, 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 ofine, and browsers (and native mobile OSes) have

become vastly more capable. In todays 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.


3/16


Figure 1:

Page Display

Page Generation

APIs

User Interface

Logic & State

Integration

InterfaceManagement

Data

Logic & State

Integration

Data

Browser

Yesterday Today

Native &HTML 5

App Server

Cloud

Web 1.0 vs. Multi-Device Architectures

In todays 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, ltering 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, its extremely valuable to stop and reect 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.


4/16


This is particularly true if youre 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. Its potentially an extremely serious undertaking (some Sencha

customers have ve year migration timelines for upgrading their applications to the new architectural pattern).

So its 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

Figure 2:

Interface

Elements

Create appealing themes and styles for interactive elements

Present complex data using structured presentation elements like grids and charts

Create a standard visual vocabulary across apps and more

ViewSystem

Dynamically lay out screen elements in response to dierent screen sizes and resizes

Detect and respond to touch gestures beyond simple taps

Swap in local language strings, handle RTL languages and keep everything accessible

Animate content and more

Logic &Data

Update the screen when data changes and vice versa

Remember application states to enable undo/redo as well as navigation

Search, sort, flter, group and validate data

and more

Server i/o

Handle asynchronous calls to the server-side

Parse and convert serialized data

Call out to server-side code

and more

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.


5/16


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 others work

without stepping on each others 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.

Figure 3:

Server i/o Server Method InvocationServer Calls

asynch, conversion2-Way Data Server Notifcations

Base ServicesRendering, DOM, fonts, parallelism, security, media decode, sensors, printing, network i/o

InterfaceElements

Compound Widgetstrees, grids, gauges

Basic Widgetsbuttons, bars, text felds

Visualizationscharts, infographics

Containerspanels, cards, modals

Themes Styles

ViewSystem

Interactionsgestures, drag & drop

Layout Managerabsolute, exible

Drawingvector, bitmap

Themingcomputed styles

Templatingiterations, conditionals

Visual Eectsanimations, flters

LocalizationRTL, locale libraries

Accessibilityfocus manager, ARIA

Logic &Data

Data Binding1-way, 2-way

State Managerhistory, undo, routes

Modularitycomponents, modules

TestingIOC, test hooks

Data Objectsqueues, hashtables

Data Models & Storesgroup, sort, validate

Persistent Datacache & sync

Mulitimedia3D, audio, video

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 simplication of the way that the real code is structured. For example, a module system isnt strictly a

separate piece of code; its the way that all code is organized. Nevertheless, weve found it to be a helpful way

to organize front-end functionality and map out the capabilities of various front-end technologies.


6/16


Interface Elements

Compound Widgets

trees, grids, gauges

Basic Widgets

buttons, bars, text felds

Visualizations

charts, infographics


Themes Styles

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 le 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 nal 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 platforms 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, its 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.


7/16


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 sufcient 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 applications working set. Well-featured

models provide database-style functionality for sort, search, lter, 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 doesnt refer to a single piece of

identiable 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 le read-write that help store, cache and syncapplication 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 Method InvocationServer Calls


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 doesnt 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.


8/16


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.




InterfaceElements





Themes Styles

ViewSystem





Templatingiterations, conditionals Visual Eectsanimations, flters LocalizationRTL, locale libraries Accessibilityfocus manager, ARIA

Logic &Data









The Pre-HTML5 web platform offered a limited set of widgets, some styling and layout capabilities, and request/

response http calls. Thats it. Its amazing to think that the entire rst 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


9/16


Figure 4:


Server i/o Server Method InvocationXHR2 Web Sockets Notifcations

InterfaceElements


Range, Color Picker, Date/Time,Progress, Telephone



Themes Gradients, Border Radius

ViewSystem

Drag & DropFlexbox, Multicolumn SVG, CanvasTheming

computed styles


Animations & Transitions,Filters


WAI - ARIA

Logic &Data


History Push StateModularity

components, modulesWeb Timing API



Local Storage, IndexedDB, App-cache

Video, Audio, WebGL

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 wont 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 ll some of these gaps, these features have not been adopted

widely. For example, Chromes web components proposal includes partial support for templates and a basic

(if somewhat convoluted) component model. Chrome also, uniquely, has support for les and directories per

application domain. And Adobes Regions proposal for complex cross-element text ow is partially available in

Internet Explorer and Safari, but not Chrome. In summary, as of mid 2014, there are signicant gaps remaining

for a development team that wants a complete front-end development stack. And there is little expectation that

these gaps will be lled in the near term.
http://www.quirksmode.org/blog/archives/2009/09/the_html5_drag.htmlhttp://www.quirksmode.org/blog/archives/2009/09/the_html5_drag.htmlhttp://www.quirksmode.org/blog/archives/2009/09/the_html5_drag.html


10/16


JavaScript to the Rescue

Fortunately, since JavaScript rst 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 nding a library to ll 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 rst 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 whats 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 apps 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, its easier to answer the

question of what is the best framework for your teams.


11/16


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.

Figure 5:

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

Major Development Frameworks and Libraries

Bootstrap is a CSS framework that provides interface elements and some view management

capabilities like theming and layout. Its 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 gure 6, for example, we show where

Bootstrap provides functionality.


12/16


Figure 6:

Support Key


asynch, conversion

None / HTML5 Partial Complete

Sockets Server Notifcations

InterfaceElements




Containers & Windowspanels, cards, modals

Themes Styles

ViewSystem

Drag & DropLayout Managerresponsive grid

SVG, CanvasTheming

computed styles



Localizationlocale support

WAI - ARIA

Logic &Data


State ManagerModularity





Video, Audio, WebGL

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 youll 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 difcult. 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 difcult to synchronize changes in grids and charts. Its easy to see how such

solutions can become franken-frameworks.


13/16


Figure 7:

Support Key


asynch, conversion



InterfaceElements





Themes Styles

ViewSystem


SVG, CanvasTheming

computed styles




WAI - ARIA

Logic &Data







Video, Audio, WebGL

AngularJS Functionality Map

Figure 8:

Support Key

Server i/o Server Method InvocationServer Callsasynch, conversion



InterfaceElements




Containers & Windowspanels, cards, modals Themes Styles

ViewSystem


SVG, CanvasTheming

computed styles




WAI - ARIA

Logic &Data







Video, Audio, WebGL

Backbone.js functionality map


14/16


Figure 9:

Support Key

Server i/o Server Method InvocationXHR

asynch, conversion



InterfaceElements





Themes Styles

ViewSystem


SVG, CanvasTheming

computed styles



LocalizationRTL, locale support


Logic &Data







Video, Audio, WebGL

jQuery + jQueryUI Functionality Map

Figure 10:

Support Key

Server i/o Server Method InvocationXHRasynch, conversion



InterfaceElements




Containers & Windowspanels, cards, modals Themes Styles

ViewSystem


SVG, CanvasTheming

computed styles





Logic &Data


State Managerhistory, routes






Video, Audio, WebGL

Ember Functionality Map


15/16


The Ext JS Stack

Compared to the libraries and toolsets weve 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 ve 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.

Figure 11:

Support Key


asynch, conversion


Socketsextension

Server Notifcations

InterfaceElements





Themes Styles

ViewSystem


Layout Managerabsolute, ex







Logic &Data


State Managerhistory, routes





Persistent Dataextension

Multimedia3D, audio, video

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 dont 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.

Its also worth pointing out a few areas where alternatives really dont 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


16/16


performance, sortable, lterable 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

Its worth noting that no framework currently offers good support for management of audio and video playback

or server notications, 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. Wed 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
http://www.sencha.com/forumhttp://www.sencha.com/traininghttp://www.sencha.com/traininghttp://www.sencha.com/forum

Documents

Whitepaper the Modern Web Stack