Sencha Web Applications Come of Age

Sencha Web Applications Come of Age

• 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-browsertechnologies; 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-responsemodel, 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 moremature 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 forthe 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, andRuby 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 thiscode 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 similarmanner, 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 possibleto 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 haslittle 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 ofLinux 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