"Web Applications Come of Age" 전반적인 web app의 진화부터 개발방법 변화를 짚은 글.

1. Web Applications
Come of Age
Table of Contents Executive Summary
Executive Summary 1 From the earliest days of the World Wide Web, developers have sought to create
web applications that provide desktop-quality user experiences. Unfortunately,
A Brief History of Web Development 2
the page-oriented request-response model of the HTTP protocol has been a
The JS Web App: A New Paradigm 4
major obstacle to achieving this goal. In this model, any significant user interaction
Request-Response Model 5 reloads the entire page, interrupting the user and reducing responsiveness.
JavaScript Web Application Model 7 As a result, enterprise developers have often selected plug-in-based SDKs such
Why HTML5 and CSS3 Matter 9 as Adobe Flash or various out-of-browser web application solutions, such as
Nokia Qt, when building applications that require complex and extensive user
Mobile App Development 9
interactions.
Loosely Coupled Services 9
But several parallel developments in recent years have changed this situation:
Effect on Development Teams 10 • Rich JavaScript frameworks have emerged to provide sophisticated
Changing the Mindset 11 programming environments for creating complex applications that execute
within the browser.
Implications for Decision Makers 11
• The HTML5 and CSS3 standards have entered the mainstream, making it
Conclusion 13
possible to create visually sophisticated, high-performance web applications
based purely on browser technology.
• The proliferation of mobile devices with modern browsers has enabled web
applications to successfully address mobile application needs.
The new JavaScript application frameworks convert the web browser into a full-
fledged application environment, entirely controlled by JavaScript running on the
client side. The browser-based web application has finally been freed from its
tightly coupled relationship with the server. Instead, a loosely coupled services
architecture for web applications is gaining popularity.
As a result, a rich web application experience can now be achieved without plug-
ins. And instead of programming exclusively in server-side frameworks such as
Java Server Faces, Rails, or Zend, most of the development effort is devoted to
building client-side web applications that interact with server-side data sources
through lightweight Representational State Transfer (REST) interfaces.
Decision makers need to understand the implications of the new architecture for
their own development teams and technologies. Important factors include the
costs of distributing and maintaining desktop configurations required for plug-
1

2. in and out-of-browser technologies; the point an enterprise has reached in the
life cycle of its toolsets; and the kinds of tradeoffs that make sense for a given
organization.
This paper introduces the new loosely coupled services architecture and what it
means for enterprise web application development.
A Brief History of Web Development
When the World Wide Web first took off in the mid-1990s, the mechanism for
displaying web pages was based on a straightforward request-response model.
Browser software on a desktop computer sent a request for a page to a server,
and the server responded with a copy of that page. In most cases, the page was
assembled on the fly from instructions in a page template that inserted data from
database queries.
Creating web applications that provide the same level of interactivity as desktop
applications has been the Holy Grail of web development from the beginning. But
cross-browser and version incompatibilities in script languages, primitive styling
and graphics capabilities, as well as the limits of the fundamental page request-
response model were early barriers to achieving this goal.
Before long, plug-in technologies such as Java applets and Active X controls made
it possible to update interface elements within a page on-the-fly. However, due
to performance and security issues, applets and ActiveX controls quickly fell out
of favor. At the same time, Macromedia Flash emerged as a popular alternative,
allowing developers to create cross-browser rich application experiences—as long
as the right version of the plug-in was installed.
Early versions of web technologies such as JavaScript and Cascading Style
Sheets (CSS) allowed designers and developers to provide simple interactivity
without plug-ins; but in practice such technologies were plagued by browser
and version incompatibilities. Most application logic, whether interacting with
databases or responding to user requests, was still executed by the server. As
a result, most web interfaces during the first decade of web development felt
primitive compared to traditional desktop applications. And as services available
over the web became more complex, most application development was focused
on server-side programming.
2

3. In the request-response model, a user clicks a hyperlink or a form’s Submit button,
and the browser sends a request to the server. The server passes data to a Java
program, Python script, CGI process, or something similar. When the server has
finished processing the request, it sends back a completely new page:
Request-Response Model
Java,
Browser PHP,
Server
Python,
Submit CGI . . .
Browser requests Server assembles page
page and sends to browser
The person coding the form interface and the person writing the server-side code
must both have a detailed understanding of each other’s requirements in order to
make everything work correctly.
This model changed in the mid-2000s with the rise of AJAX, or Asynchronous
JavaScript and XML. “Asynchronous” means that a JavaScript program running
within the browser can request information from the server and continue executing
without waiting for a server response. XML provides a way of encoding the data
response, whether HTML content or other data, in a structured manner that the
JavaScript program can understand. (Since its initial coining, the term AJAX has
also come to mean the use of JSON as well as XML data formats.)
In an AJAX-enabled browser application, when the user clicks an interface element
such as a button, the browser sends data to a JavaScript program running
on the client, rather than directly to the server. This code uses the JavaScript
XMLHTTPRequest object to request new data, which is returned to the JavaScript
program. The JavaScript program—not a server-generated web page—decides
what the user sees, updating the page contents granularly and on the fly to
achieve desktop-quality responsiveness.
JavaScript Ajax model
Code
JavaScript fetches
Browser calls data wrapped in
JavaScript code XMLHTTPRequest
in response to object
user actions
Java,
Browser PHP,
Server
Python,
Browser requests CGI . . .
3 and receives
entire pages

4. Combined with more mature HTML and CSS technologies, this hybrid approach
made it possible to build highly responsive applications powered by nothing
more than a standards-compliant browser. With the release of Google Maps
in 2005, and related improvements to highly interactive sites like those built by
Amazon and the major airlines, users began to expect comparable interactivity
from web applications everywhere. However, performance and cross-browser
incompatibilities were still a problem for complex interfaces, and developers were
understandably wary of using AJAX for enterprise applications.
As demand for the Rich Internet Application (RIA) experience grew within
enterprises as well as from consumers, development environments built around
plug-in and out-of-browser technologies evolved alongside more lightweight
JavaScript toolkits. Flex, introduced by Macromedia in 2004, rapidly gained
popularity in the enterprise web application market. Although Flex and similar
SDKs required more advanced programming skills than simple web programming,
the payoff was interfaces that successfully combined the advantages of the
Internet with the speed and sophistication of native applications.
But in the late 2000s, several parallel developments triggered dramatic changes in
the web development landscape:
• Rich JavaScript frameworks have emerged to provide sophisticated
programming environments for creating complex applications that execute
within the browser.
• The HTML5 and CSS3 standards have entered the mainstream, making it
possible to create visually sophisticated, high-performance web applications
based purely on browser technology.
• The proliferation of mobile devices with modern browsers has enabled web
applications to successfully address mobile application needs.
Today, AJAX toolkits and JavaScript application frameworks are widely used for
developing high-end consumer websites. In the enterprise sector, JavaScript
application frameworks have also become a popular alternative to plug-in-based
RIA technologies such as Flex and outside-the-browser RIA platforms like Nokia
Qt and Microsoft Windows Presentation Foundation. The remainder of this paper
describes why.
The JavaScript Web Application: A New Paradigm
To understand the key differences between the traditional request-response model
and a modern AJAX-based web application, consider how a programmer uses
each one to assemble and display a grid of data obtained from a database.
4

5. Request-Response Model
Here’s a simple server-side web page template with a PHP script that makes some
SQL queries, plus HTML formatting for a table that contains the results of those
queries:
5

6. The HTML for the table and the PHP scripts and variables that populate the table
are intermingled on the same page. When the server receives a request from the
client to display the page, it processes the scripts involved, assembles the page,
and sends it across the network to the client:
1. Browser requests
page 2. Server loads
source code
Browser Server </>
4. Server sends nal
assembled page
back to browser
3. Server runs scripts
and assembles page
5. Browser displays page
Database
The application logic—-in this case represented by the PHP scripts—is executed
on the server. The client merely receives the generated HTML and displays it. The
programmer who creates the web page must be knowledgeable about both PHP
and the organization of the database.
Although easy enough for a simple table, this approach does not scale well for
performance or ease of development. As a web application grows more complex,
integration with tightly coupled server services becomes more difficult. Client,
server, and database programmers must meet frequently whenever relatively
small changes need to be made to the user interface. And features that desktop
application users are accustomed to, such as sortable columns, are difficult to
incorporate.
Most importantly, the request-response model requires business data and
business rules to be tightly integrated. This tight integration breaks the object-
oriented programming (OOP) model, so that the full benefit of data encapsulation,
abstract interfaces, and so on can’t be realized no matter what programming
languages are used. In the late 2000s, server-side frameworks such as ASP
6

7. .NET, MVC, and Ruby on Rails began to address this problem by providing better
structure for server-side application code. Nevertheless, it’s no wonder many
enterprise customers adopted plug-in or out-of-browser solutions.
JavaScript Web Application Model
A “single page” JavaScript web application built with HTML5 and CSS3 typically
lives in a web page (with an .html extension) that usually doesn’t contain any
initial HTML markup at all. The single page is the application environment. The
JavaScript program executing in the page generates all content dynamically by
writing data into the page’s Document Object Model (DOM). The data displayed on
a page is cleanly separated from the application code that manipulates that data.
As a result, the source code for such a page typically consists solely of links to
CSS style sheets and the JavaScript application file. The JavaScript application
running on the client has complete responsibility for generating and managing the
user interface.
Here’s a snippet of Sencha Ext JS JavaScript code that displays a grid:
7

8. Note that this code requires no special knowledge of database calls or server-side
scripting. Instead, the programmer only needs to understand the interface for the
object that provides the data.
When the user performs an action, such as clicking a column header to change
the sort order, the JavaScript performs an independent refresh, on the fly, of just
those user interface (UI) elements that require updating:
JavaScript requests
data as needed
JavaScript
Server
Application
Server sends data
objects back to JavaScript
Server retrieves
Browser fetches JavaScript updates data and assembles
and runs JavaScript browser on the y requested XML or
when page opens JSON objects.
Browser Database
Displayed page responds
continuously to JavaScript updates
The grid already exists in the browser’s DOM, rendered appropriately for that
browser and platform.
One major advantage of this approach is that an application will run efficiently
on any browser. Plug-ins and out-of-browser solutions, by definition, require
installation and upgrades, are dependent in various ways on the underlying
operating system, and demand specialist programming skills that can be difficult
to find. This doesn’t mean that they aren’t still a good choice in some situations. It
does mean that switching to the JavaScript web application model has become a
popular and convenient option for many enterprises.
8

9. Why HTML5 and CSS3 Matter
The highest-profile benefits of HTML5 and CSS3 involve improved support for
time-based media. Flash is no longer required to embed video, audio, or animation
in web pages. Video streamed with HTML5 works just as well.
Other improvements of interest to web developers include a more logical and
flexible markup language and numerous programming features designed explicitly
to support the requirements of high-performance web applications. Such features
include cross-domain messaging, a rich package of APIs for manipulating the
DOM, and support for offline applications.
Enhancements for designers include embeddable fonts and text styling, enabling
more precise control over type across all browsers and operating systems, and
other graphic improvements related to color, formatting, and image handling.
In short, HTML5 and CSS3 have dramatically reduced the user experience gap
between purely web-based applications and modern desktop applications. The
standards have been embraced by a new generation of browser software on
all sorts of devices. Another generation of browser technologies is stimulating
innovation at all levels. Major strides in both programming and graphic capabilities
have led many companies, most visibly Apple and Google, to invest heavily in
HTML5, CSS3, and related “pure browser” technologies as the wave of the future.
Browser-Based Development for Mobile Apps
Combined with HTML5 and CSS3, the JavaScript application paradigm allows
developers to write browser-based applications for any screen size. Because such
applications are based on standards, they work consistently across all modern
browsers. Although a mobile application needs to be designed appropriately for
touch-based interfaces, most application code can be re-used across desktop,
tablet, and phone form factors.
The same development tools and environment can be deployed across the board,
from an iPod Touch to Internet Explorer on the desktop, and the same code will
run on Android, iOS, or Blackberry. The resulting web apps can even be wrapped
for deployment through native app stores for iOS or Android. By consolidating
development efforts, enterprises can achieve significant cost savings and improved
time to market in the fast-paced mobile world.
A Loosely Coupled Services-Based Architecture
Loosely coupled object-oriented programming, with a clear separation between
model, view, and controller (MVC), is widely used today to create server-side web
applications.
9

10. In a similar manner, a loosely coupled, services-based architecture for web
applications should provide a clear separation between client, server, and
database. HTML5 and CSS3 have converged with market conditions, including
improved browser capabilities and the rise of JavaScript frameworks, to make this
possible. JavaScript is now a first-class programming citizen: a true application
language for connected devices.
When JavaScript programmers need to access server-based services, deep
knowledge of those services is no longer required. Instead, they only need to agree
with their server-side counterparts on the XML or JSON interfaces used to wrap
the data returned to the JavaScript code.
At the same time, server programmers no longer need to concern themselves with
details of the UI displayed by the browser—that is, they don’t need to create pages
on the server to be rendered in the browser. Instead, they create XML or JSON
objects to deliver in response to JavaScript requests.
Effect on Development Teams
With the tightly coupled architecture that used to dominate web development,
changing something in the client interface almost always meant changing
other things on the server side. As web applications grew more complex, this
interpenetration of responsibilities led to all kinds of problems. Regression testing
became more difficult. Communication between development teams took more
time. Even relatively small extensions to an existing interface could require many
meetings and much testing to implement successfully.
A more loosely coupled architecture minimizes many of these problems. The
JavaScript application doesn’t need continuous access to the server to function
smoothly. It controls the DOM directly, requesting specific data and services only
when necessary, making its own decisions about when and how to display data.
Using loosely coupled REST-style interfaces, a JavaScript programmer can add a
user to the www.bar.com application simply by posting a properly formatted JSON
object to bar.com. Server programmers can implement the server code to handle
this request in any way they please. The client programmer doesn’t care what’s
happening on the back end, and vice versa.
As a result, the organization of development teams may be affected. In the past,
web developers typically had to be familiar with several technologies. For example,
they might code PHP templates for HTML markup and JavaScript for the local
page interactions, while making SQL calls to populate their PHP templates
with data. Mobile developers might be a separate team familiar with mobile
development, making server calls from native objective C code on Apple iOS
devices.
10

11. Today, it’s possible to consolidate application development across all devices
onto a single web-based platform. The application developer no longer needs
to worry about obscure Java behaviors or database calls. And the programmers
on the back end creating standardized and general purpose JSON/REST server
interfaces don’t have to think about the user interface at all. Obviously, there are
situations in which intensive collaboration will still be required, but it can now be
the exception rather than the rule. Data interfaces and data presentation can be
cleanly separated.
As with development, so with testing. The application still has to be tested as a
whole, but it’s very clear where the points of failure are. Debugging can quickly
focus on one compartment to the exclusion of others. Each team’s responsibilities
can be more precisely defined.
Changing the Mindset
Like any other major shift in technology, the new model has required a change
in mindset. Executives need to understand the implications for planning and risk
mitigation. Managers need to think differently about development organizations.
Web developers need to change the way they think about JavaScript and how to
construct a web page.
Many web developers are already moving away from the request-response model
for web content. Previously, they viewed a web page as a static structure, and
JavaScript as a tool that allowed them to query the DOM and manipulate individual
elements. Now, they are beginning to think about modeling interface objects that
interact with other objects, with results rendered to screen in the form of HTML
and CSS. The central idea is that the web page is the application environment.
Most significantly, all developers working on a web application, whether on the
client or the server, are changing how they think about interactions between the
code they write and code written by others. This is not a trivial challenge.
Once the dust settles, however, the benefits quickly become clear. Project scoping
improves, because there are fewer chances for unexpected dependencies
or unpredictable interactions. On the client side, there’s the added benefit of
leveraging related skills. Mobile developers who already use JavaScript can get
up to speed more quickly, for example, on a website that needs to be ported as a
wrapped iOS web app. Much of the code won’t change at all, and the new mobile
interface uses many of the same calls and techniques as the existing code.
Implications for Decision Makers
Some people might wonder what all the fuss is about. Plug-in and out-of-browser
RIA solutions have supported sophisticated user interfaces for years. The whole
point of such solutions was to achieve a desktop-like experience. If you’ve already
achieved that, why bother switching?
11

12. The answer has little to do with the behavior of the resulting applications. Rather,
it depends on the costs of distribution and maintenance on the desktop, the point
you’re at in the life cycle of your particular toolset, and the kinds of tradeoffs that
you’re willing to make.
The fundamental benefit of web technologies is that they are standards-based and
backwards compatible (sometimes to a fault!). Web pages created in 1995 still
display perfectly in today’s latest browsers. How many Windows 95 applications
still run on Windows 7?
Using web technologies also provides insurance against platform shifts. Anyone
who invested heavily in Adobe Flex as an application platform is now left with
applications that can’t execute on the world’s most popular smartphone and tablet
platform—Apple iOS.
Similarly, using standardized languages such as JavaScript provides strong
insurance against the language obsolescence of proprietary platforms. If you are in
a dedicated Microsoft technologies organization, then you’re already familiar with
the rapid changes of Microsoft programming tools from Visual Basic 6 to C# and
.NET and on to Silverlight.
The decisions involved are becoming all too familiar to enterprise teams. Continue
down an increasingly expensive and risky path, or disrupt critical systems and
processes with a major paradigm shift. Upgrade to the latest proprietary tools
and technologies, or switch to web technologies and a JavaScript framework.
Each option involves tradeoffs. To make such tradeoffs intelligently, you need to
understand the limitations and opportunities of the pure browser approach to web
development.
For example, only the latest HTML5-capable browsers can handle rapid scrolling
through thousands of rows of data. If your organization still has significant installed
bases of Internet Explorer 6, then you may want to remain on native technologies
such as Windows MFC and .NET for your desktop applications.
Development processes are another factor. For example, a mobile app and
a website may consume the same data store. If you move the mobile app
to the browser, you can move some development from data logic into the UI
presentation. A .NET application, on the other hand, requires more code to be
written to expose its data externally. So in this sense you can get a 2 for 1 when
you enable mobile applications, if this is important to you.
The decoupling of server and client development has implications for the back
end. A JavaScript web application doesn’t have any special server requirements.
So, for example, it may now be possible to host your application on a Linux server
12 without affecting client development in the slightest. You can have the security

13. and reliability of Linux running the application in the background, while no longer
needing to concern yourself with the user’s hardware.
The point an enterprise has reached in the life cycle of a particular technology is
another critical factor. If you’re currently using a legacy system that is five or six
years old, and you haven’t yet invested in something like Flex or Silverlight, the
browser approach may be very attractive as the next step. Organizations that have
invested in such technologies more recently may have the luxury of taking their
time.
Conclusion
The rise of JavaScript frameworks, new capabilities of HTML5 and CSS3, and
the rapid deployment of millions of mobile devices running modern browser
technology have converged to redefine the way developers build web applications.
JavaScript is now a first-class programming citizen: a true application language for
connected devices.
The browser-based web application has finally been freed from its tightly
coupled relationship with the server. Developers today are moving away from
the original request-response model for web content. Instead, they are adopting
a loosely coupled services-based architecture that provides a clean separation
between client, server, and database. The web page has become the application
environment.
This new paradigm for web development makes it possible to achieve a rich
application experience without plug-ins or out-of-browser technology. Among
other benefits, enterprises that are in a position to adopt the new paradigm are
finding that they can:
• Consolidate application development for all devices on a single web platform.
• Ensure backward compatibility across multiple browsers and devices.
• Avoid the worst effects of platform shifts and language obsolescence.
After nearly two decades, web applications have come of age.
1700 Seaport Boulevard Sencha makes application frameworks that equip developers to create, deploy,
Suite 120
and optimize compelling experiences using web-standard technologies. The
Redwood City, CA 94063
1 888 736 2421 company’s flagship products, Ext JS and Sencha Touch, are a cross-browser
www.sencha.com JavaScript frameworks which produce rich internet applications for desktop and
@sencha
mobile devices. More than one million developers worldwide—representing more
Copyright © 2011 Sencha than 150,000 companies—use the Sencha family of products to build amazing
applications every day.
13