The CloudBrowser Web Application Framework Brian McDaniel Godmar Back Department of Computer Science Virginia Tech [email protected] [email protected] CloudBrowser is a web application framework that sup- the state of the user interface is retained across page nav- ports the development of rich Internet applications whose igation and sessions so they can pick up where they leave entire user interface and application logic resides on the off. server, while all client/server communication is provided by The creation of such rich Internet applications within the the framework. CloudBrowser thus hides the distributed na- context of the current web infrastructure is difficult for mul- ture of these applications from the developer, creating an en- tiple reasons. Application developers and framework design- vironment similar to that provided by a desktop user inter- ers must decide how to split the application’s user interface face library. CloudBrowser preserves the user interface state code and its business logic between client-side JavaScript in a server-side virtual browser that is maintained across vis- code and server-side code, and how to structure the com- its. Unlike other server-centric frameworks, CloudBrowser’s munication between the client and the server on top of the exclusive use of the HTML document model and associ- stateless HTTP protocol. ated JavaScript execution environment allows it to exploit Traditional AJAX [18] applications, which are developed existing client-side user interface libraries and toolkits while using a mix of client- and server-side programming, fully ex- transparently providing access to other application tiers. We pose developers to the underlying infrastructure’s distributed have implemented a prototype of CloudBrowser as well as nature. Developers must write view logic to produce an ini- several example applications to demonstrate the benefits of tial rendering of the user interface, then implement client- its server-centric design. side controller logic to track the user interface state using Categories and Subject Descriptors D.2.2 [Software En- JavaScript, use some variation of AJAX to inform the server gineering]: Design Tools and Techniques User Interfaces; of relevant changes to the application data, and incorporate H.5.3 [Information Interfaces and Presentation]: Group and any server responses into the HTML document that is ren- Organization Interfaces Web-based Interaction dered for the user. If the user refreshes the page, or makes use of the browser’s navigation buttons, the ephemeral client Keywords web application framework, AJAX, server-cen- state must be restored from scratch, often using hints stored tric, remote display, PaaS, cloud applications on the server, because there is no automatic way of preserv- ing user interface state. 1. Introduction To address these problems, server-centric AJAX frame- More and more applications are moving from the desktop works [11, 27] move all application logic to the server, to the web. Web applications can be accessed from any web hiding most or all client-side programming from the de- browser, regardless of underlying platform, allowing them to veloper. Such frameworks maintain the view state for each be deployed and updated instantly. Users have begun to ex- visit in a server-side representation, such as a document in a pect rich and expressive user interfaces whose single-page framework-specific, higher-level markup language that pro- design mirrors that of desktop applications. At the same vides elements that represent user interface components. time, users assume that the data on which these applications These components encapsulate the initial rendering into operate resides “in the cloud,” which stores any changes im- HTML, manage the forwarding of client-side events to mediately and persistently. Increasingly, users expect that server-side controller logic, and handle the propagation of any resulting updates to the client-side document with which the user interacts. Existing server-centric frameworks suffer from multiple Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed shortcomings. First, since they instantiate components for for profit or commercial advantage and that copies bear this notice and the full citation each visit, they also do not automatically preserve user in- on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. terface state across visits. Second, they still require the pro- SPLASH’12, October 19–26, 2012, Tucson, Arizona, USA. grammer to synchronize updates to the application’s model Copyright c 2012 ACM 978-1-4503-1563-0/12/10. $10.00 state across visits. Third, in practice they can make styling 2. Motivation difficult, since the specifics of the rendering strategy used by We motivate our approach using several example application these high-level components is encapsulated in their imple- scenarios. First, consider an example application such as the mentation. Fourth, the necessary computation of incremental popular meeting scheduling service ’Doodle’ (doodle.com). client-side document updates after mutating the server-side A user may initiate event scheduling by entering a set of pos- view is tedious and error prone. Fifth, these server-centric sible meeting times, which are displayed to potential partici- frameworks often do not leverage the numerous JavaScript pants on a specially crafted webpage. Participants then enter libraries that have been developed to facilitate the interac- their name, check boxes indicating their preferences when to tion with HTML documents, and thus cannot leverage the meet, and hit a submit button, which navigates to a new page substantial skill sets developers have acquired. that displays their preferences along with the preferences of This paper presents CloudBrowser, a web application all other participants who have entered their preferences so framework that addresses these concerns. CloudBrowser far. maintains an application’s user interface state server-side, The user experience of Doodle, as well as many other cur- as a document in a headless, virtual browser. The applica- rently available similar services, could in our opinion be sig- tion logic interacts with the server-side representation in a nificantly improved. For instance, a user does not see what manner similar to how a desktop application interacts with other participants have entered until they submit their own, a graphical user interface (GUI) library, by creating and ma- and subsequently only when they refresh or revisit the page, nipulating components and listening for events fired in re- even when the potential meeting participants visit the page sponse to user interactions. This design hides the distributed at around the same time. In addition, if the process of enter- nature of the web from the application developer, because ing their name and checking appropriate times is interrupted, all client-server communication is encapsulated inside our perhaps because the user clicked an ad and navigated to an- framework. Clients connecting to application instances mir- other page and returned to the page, the user will need to start ror the user interface state using a synchronization/update over. Lastly, if the user overlooks the submit button before protocol we have developed. CloudBrowser automatically closing the page, their submission will not reach the server interposes on any changes to the server-side document, re- at all, which frequently happens to users accustomed to the moving the need to manually compute updates. For effi- single-click style used in their native OS (i.e., Mac OSX). ciency, the actual layout and rendering of user interface el- Second, consider a social forum application such as Pi- ements is performed inside the actual browser by the client, azza (piazza.com), which provides an interactive Q & A rather than the virtual browser on the server. forum for instructional settings in which students can post CloudBrowser uses exclusively HTML, CSS, and Java- questions to other students and to instructors. From an in- Script to express the user interface and its interaction with structor’s perspective, the Piazza user interface presents a the application, allowing us to leverage existing libraries and constantly changing dashboard - new questions are being developer skill sets, and avoiding any semantic overhead posted, questions are withdrawn, marked as answered by associated with a translation from high-level components other instructors or students, or archived (hidden from view) to low-level components. Since CloudBrowser application after being answered. If the Piazza application is used from instances persist across visits, this design naturally handles multiple computers (say, the instructor’s work PC, work lap- page navigation and refresh. It also provides a natural co- top, home PC, and perhaps a mobile device), the dashboard browsing ability since it can support simultaneous display to views are not kept in sync: already answered questions ap- multiple clients. pear as unanswered when the instructor revisits the class site CloudBrowser is targeted at developing web applications after returning home from work, forcing a manual refresh of in which most user interactions trigger persistent changes to the page. When such a refresh happens, some user interface the application data that