Whitepaper The Modern Web Stack

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

Summer 2014
Sencha, Inc.
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 and
more fexible 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 fve 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 fnd it hard to believe that these
investments are now entering obsolescence. In many peoples minds, the frst 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 offine, 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 offine, 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.
Figure 1:
Page Display
Page Generation
APIs
User Interface
Logic & State
Integration
Interface
Management
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, fltering 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 refect 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 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 fve 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
View
System
Dynamically lay out screen elements in response to diferent 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.
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 Invocation
Server Calls
asynch, conversion
2-Way Data Server Notifcations
Base Services Rendering, DOM, fonts, parallelism, security, media decode, sensors, printing, network i/o
Interface
Elements
Compound Widgets
trees, grids, gauges
Basic Widgets
buttons, bars, text felds
Visualizations
charts, infographics
Containers
panels, cards, modals
Themes Styles
View
System
Interactions
gestures, drag & drop
Layout Manager
absolute, fexible
Drawing
vector, bitmap
Theming
computed styles
Templating
iterations, conditionals
Visual Efects
animations, flters
Localization
RTL, locale libraries
Accessibility
focus manager, ARIA
Logic &
Data
Data Binding
1-way, 2-way
State Manager
history, undo, routes
Modularity
components, modules
Testing
IOC, test hooks
Data Objects
queues, hashtables
Data Models & Stores
group, sort, validate
Persistent Data
cache & sync
Mulitimedia
3D, 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 simplifcation 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.
Interface Elements

Compound Widgets
Basic Widgets
Visualizations
Containers
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 fle 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

Interactions
Layout Manager
absolute, fexible
Drawing
vector, bitmap
Theming
computed styles
Templating
Visual Efects
animations, flters
Localization
Accessibility
focus manager, ARIA
Templating is a capability that converts placeholders into fnal 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.
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

Data Binding
1-way, 2-way
State Manager
Modularity
components, modules
Testing
IOC, test hooks
Data Objects
queues, hashtables
Persistent Data
cache & sync
Mulitimedia
3D, audio, video
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 suffcient 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, flter, 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
identifable 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 fle 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 Method Invocation
Server Calls
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 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.
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.
Server Calls
asynch, conversion
Interface
Elements
Compound Widgets
Basic Widgets
Visualizations
Containers
Themes Styles
View
System
Interactions
Layout Manager
absolute, fexible
Drawing
vector, bitmap
Theming
computed styles
Templating
Visual Efects
animations, flters
Localization
Accessibility
focus manager, ARIA
Logic &
Data
Data Binding
1-way, 2-way
State Manager
Modularity
components, modules
Testing
IOC, test hooks
Data Objects
queues, hashtables
Persistent Data
cache & sync
Mulitimedia
3D, audio, video
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 frst 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
Figure 4:
Server i/o Server Method Invocation XHR2 Web Sockets Notifcations
Interface
Elements
Compound Widgets
Range, Color Picker, Date/Time,
Progress, Telephone
Visualizations
Containers
Themes Gradients, Border Radius
View
System
Drag & Drop Flexbox, Multicolumn SVG, Canvas
Theming
computed styles
Templating
Animations & Transitions,
Filters
Localization
WAI - ARIA
Logic &
Data
Data Binding
1-way, 2-way
History Push State
Modularity
components, modules
Web Timing API
Data Objects
queues, hashtables
Local Storage, Indexed
DB, 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 fll 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 fles and directories per
application domain. And Adobes Regions proposal for complex cross-element text fow is partially available in
Internet Explorer and Safari, but not Chrome. In summary, as of mid 2014, there are signifcant gaps remaining
for a development team that wants a complete front-end development stack. And there is little expectation that
these gaps will be flled in the near term.
JavaScript to the Rescue
Fortunately, since JavaScript frst 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 fnding a library to fll 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 frst 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.
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 fgure 6, for example, we show where
Bootstrap provides functionality.
Figure 6:
Support Key
Server Calls
asynch, conversion
None / HTML5 Partial Complete
Sockets Server Notifcations
Interface
Elements
Compound Widgets
Basic Widgets
Visualizations
Containers & Windows
Themes Styles
View
System
Drag & Drop
Layout Manager
responsive grid
SVG, Canvas
Theming
computed styles
Templating
Visual Efects
animations, flters
Localization
locale support
WAI - ARIA
Logic &
Data
Data Binding
1-way, 2-way
State Manager
Modularity
components, modules
Web Timing API
Data Objects
queues, hashtables
DB, App-cache
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 diffcult. 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 diffcult to synchronize changes in grids and charts. Its easy to see how such
solutions can become franken-frameworks.
Figure 7:
Support Key
Server Calls
asynch, conversion
Interface
Elements
Compound Widgets
Basic Widgets
Visualizations
Themes Styles
View
System
Drag & Drop
Layout Manager
responsive grid
SVG, Canvas
Theming
computed styles
Templating
Visual Efects
animations, flters
Localization
locale support
WAI - ARIA
Logic &
Data
Data Binding
1-way, 2-way
State Manager
Modularity
components, modules
Web Timing API
Data Objects
queues, hashtables
DB, App-cache
Video, Audio, WebGL
AngularJS Functionality Map
Figure 8:
Support Key
Server Calls
asynch, conversion
Interface
Elements
Compound Widgets
Basic Widgets
Visualizations
Themes Styles
View
System
Drag & Drop
Layout Manager
responsive grid
SVG, Canvas
Theming
computed styles
Templating
Visual Efects
animations, flters
Localization
locale support
WAI - ARIA
Logic &
Data
Data Binding
1-way, 2-way
State Manager
Modularity
components, modules
Web Timing API
Data Objects
queues, hashtables
DB, App-cache
Video, Audio, WebGL
Backbone.js functionality map
Figure 9:
Support Key
XHR
asynch, conversion
Interface
Elements
Compound Widgets
Basic Widgets
Visualizations
Themes Styles
View
System
Drag & Drop
Layout Manager
responsive grid
SVG, Canvas
Theming
computed styles
Templating
Visual Efects
animations, flters
Localization
RTL, locale support
Accessibility
focus manager, ARIA
Logic &
Data
Data Binding
1-way, 2-way
State Manager
Modularity
components, modules
Web Timing API
Data Objects
queues, hashtables
DB, App-cache
Video, Audio, WebGL
jQuery + jQueryUI Functionality Map
Figure 10:
Support Key
XHR
asynch, conversion
Interface
Elements
Compound Widgets
Basic Widgets
Visualizations
Themes Styles
View
System
Drag & Drop
Layout Manager
responsive grid
SVG, Canvas
Theming
computed styles
Templating
Visual Efects
animations, flters
Localization
RTL, locale support
Accessibility
focus manager, ARIA
Logic &
Data
Data Binding
1-way, 2-way
State Manager
history, routes
Modularity
components, modules
Testing
IOC, test hooks
Data Objects
queues, hashtables
DB, App-cache
Video, Audio, WebGL
Ember Functionality Map
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 fve 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
Server Calls
asynch, conversion
Sockets
extension
Server Notifcations
Interface
Elements
Compound Widgets
Basic Widgets
Visualizations
Themes Styles
View
System
Interactions
Layout Manager
absolute, fex
Drawing
vector, bitmap
Theming
computed styles
Templating
Visual Efects
animations, flters
Localization
RTL, locale support
Accessibility
focus manager, ARIA
Logic &
Data
Data Binding
1-way, 2-way
State Manager
history, routes
Modularity
components, modules
Testing
IOC, test hooks
Data Objects
queues, hashtables
Persistent Data
extension
Multimedia
3D, 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
performance, sortable, flterable 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 notifcations, 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

Whitepaper The Modern Web Stack

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Whitepaper The Modern Web Stack

Hochgeladen von

Copyright:

Verfügbare Formate

The Modern Web Stack

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

Das könnte Ihnen auch gefallen