Rich Cloud-based Web Applications with CloudBrowser 2.0

Xiaozhong Pan Godmar Back Department of Computer Science Department of Computer Science Virginia Tech Virginia Tech [email protected] [email protected]

ABSTRACT form simplifies the distribution of these applications. As Designing modern web applications involves a wide spec- a result, researchers and practitioners alike have devoted a trum of choices when it comes to deciding where the differ- great deal of attention to how to architect frameworks on ent tiers of application and framework code that constitute this platform, which is characterized by the use of the state- these distributed applications should be placed. These sys- less HTTP protocol to transfer HTML-based user interface tem design choices affect programmer productivity, ease of descriptions to the client along with JavaScript code, which deployment, security, and performance, particularly with re- in turn implements interactivity and communication with spect to latency and scalability. the application’s backend tiers. In this paper, we propose and evaluate a design choice in In many recently developed frameworks, much of the presen- which not only all application logic executes server-side, but tation logic of these applications executes within the client’s most presentation logic as well. The client browser is re- browser. User input triggers events which result in infor- duced to a rendering and I/O engine, similar to a “thin mation being sent to a server and subsequent user interface client” or “dumb terminal,” but retains the full expressive- updates. Such updates are implemented as modifications ness of rich, modern Internet applications. to an in-memory tree-based representation of the UI (the so-called document object model, or DOM), which is then We have developed CloudBrowser 2.0, a system that imple- rendered by the browser’s layout and rendering engine so the ments this distribution model using a scalable multiprocess user can see it. However, the state of the DOM is ephemeral approach. In this paper, we perform an evaluation of the in this model: when a user visits the same application later benefits and costs of this approach when compared to both from the same or another device, or simply reloads the page, more traditional approaches as well as emerging alternatives. the state of the DOM must be recreated from scratch. In We focus on programmability and systems aspects including most existing applications, this reconstruction is done in an performance and latency. rudimentary and incomplete way, because application pro- grammers typically store only application state, and little or no presentation state in a manner that persists across visits. CCS Concepts As a result, many web applications do not truly feel like per- •Information systems → Web applications; Web in- sistent, “in-cloud” applications to which a user can connect terfaces; •Computer systems organization → Client- and disconnect at will. By contrast, users are accustomed server architectures; to features such as Apple’s Continuity[1] that allows them to switch between devices while preserving not only essen- tial data, but enough of the applications’ view to create the 1. INTRODUCTION appearance of seamlessly picking up from where they left Most newly developed applications that provide a user in- off. terface to end users are web-based. Modern browsers pro- This paper explores an alternative design that keeps the vide powerful and expressive user interface elements, allow- state of the HTML document in memory on the server in ing for rich applications, and the use of a networked plat- a way that is persistent across visits. In this model, pre- sentation state is kept in virtual browsers whose life cycle Permission to make digital or hard copies of all or part of this work for is decoupled from the user’s connection state. When a user personal or classroom use is granted without fee provided that copies is connected, a client engine mirrors the state of the vir- are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights tual browser in the actual browser which renders the user for components of this work owned by others than the author(s) must interface the user is looking at. Any events triggered by the be honored. Abstracting with credit is permitted. To copy otherwise, user are sent to the virtual browser, dispatched there, and or republish, to post on servers or to redistribute to lists, requires prior any updates are reflected in the client’s mirror. This idea specific permission and/or a fee. Request permissions from permis- [email protected]. is reminiscent of “thin client” designs used in cloud-based SAC 2016,April 04 - 08, 2016, Pisa, Italy virtual desktop offerings, but with the key difference that in this proposed design the presentation state that is kept in Copyright 2016 ACM 978-1-4503-3739-7/16/04. . . $15.00 a virtual browser is restricted to what can be represented http://dx.doi.org/10.1145/2851613.2851859 at the abstract DOM level; no flow layout or rendering is visits, they have to represent it in session state or in per- performed by the virtual browser on the server. sistent state such as a database, and retrieve it from there every time the view is rebuilt. This model entails additional benefits: since only framework code runs in the client engine, the application code run- Our own experience includes the development of two sub- ning on the server does not need to handle any client/server stantial applications using a server-centric approach [5, 4]: communication and can be written in an event-based style an application to allow students to develop ZK applications similar to that used by desktop user interface frameworks. in the cloud, and a complex configuration management sys- Since the virtual browser has the same JavaScript execution tem. This experience convinced us of the feasibility and capabilities as a standard browser, emerging model-view- value of a server-centric approach. In particular, our users controller (MVC) frameworks such as AngularJS [7] can be reported enjoying the user interface style we were able to directly used, further simplifying application development. present, in which their actions took immediate effect [2]. More side benefits include: a lighter weight client engine Notably, the latency introduced by server round trips did that can load faster, a resulting application that is more se- not present a barrier to usability. cure since no direct access to application data needs to be We soon felt hampered by the lack of persistence across visits exposed, the ability to co-browse by broadcasting the virtual and no obvious way to solve it, other than to tie all variables browser state to multiple clients. controlling the application’s view to model variables that We first introduced the idea of HTML-based server-centric were, in turn, stored persistently in some way. We hesitated execution in [9]. In CloudBrowser 2.0, we provide the first to do that since we did not want to pollute our relatively multi-process implementation of the CloudBrowser concept clean model that represented the business data of our ap- which enables its use on multiprocessor machines and on plication with less critical state solely intended to improve clusters. We have also investigated and implemented sev- usability. eral features commonly expected from a framework, such as A second limitation that influenced our thinking was the authentication and administration. CloudBrowser 2.0 also mismatch between server side representation (XUL) and the includes a model for the deployment of applications and in- HTML used in the browser, which meant that debugging lay- troduces the concept of an application instance, which al- out issues became difficult since it required understanding lows multiple virtual browsers to share state. We have im- or reverse engineering how ZK’s components were imple- plemented a number of sample and benchmark applications mented. Thus born was the idea to keep the presentation and profiled them to better understand the intrinsic and ex- state in HTML on the server. trinsic limitations of this design. Keeping presentation state on the server imposes a cost that not all types of applications may be willing to pay, even 2. MOTIVATION when the reduced development effort is taken into account. With the emergence of AJAX as a technique over ten years In [9], we discuss the types of applications for which we be- ago a shift commenced from traditional, page-based appli- lieve the trade-off we propose may be worthwhile: personal cations to the single-page applications in use today. Al- and business applications such as tax preparation systems though hybrid forms have been emerging recently, architec- or configuration management systems. These applications tural frameworks for these applications largely falls into two are characterized by the following traits: groups: client-centric and server-centric. Client-centric ap- proaches focused on the creation of powerful JavaScript li- • They are single-page applications with a large naviga- braries that execute in the browser and which provide high- tion space in which the user has free reign, thus remem- level abstractions such as two-way data bindings and custom bering the exact view state is crucial for a satisfactory directives to manage UI state. user experience. However, the user interface programmer must decide when • Users expect that their actions take immediate effect, to retrieve the data from the server and when to save/up- that is, almost every user input must trigger a com- date the server’s state. Any type of “server-push” must be munication with the server. explicitly programmed. Moreover, such applications rarely remember presentation state across visits, and when they • Users expect that updates to application state done by do, they do so using storage facilities (such as HTML5’s others become immediately reflected in their UI. localstorage) that is not available on other devices on which a user might use the application. 2.1 Challenges By contrast, server-centric approaches represent the user in- Successfully applying the idea of preserving presentation terface on the server. In a server-centric approach, the ap- state using virtual browsers in server memory imposes a plication programmer writes only code that executes on the number of challenges which this work makes an attempt server, whereas all client-side code is framework-provided to better understand. These are related to user interface code. A pioneering framework in this area was ZK [3]. This implementation, latency, resource consumption, scalability, simplified model, along with having to maintain a single and and behavior in the presence of faults. much smaller codebase, is tied to significant productivity gains. Unfortunately, even in this approach, the user inter- A virtual browser does not lay out HTML elements or com- face representation is recreated every time a user navigates pute their styles in the way that the rendering engine in the to a page. If programmers wish to preserve UI state across actual browser will, as doing so would be cost-prohibitive Web Browser Server‐side JS Environment (node.js) Virtual Browser Forwards Events JS Web Application

Client Engine Server Engine CSS, Images Web Socket Parses HTML Connection JS Listens Applies Sends Updates Dispatches Observes Events Changes Data Bindings Librar ies (jQuery, for Events Updates knockout) DOM DOM Update Adds Event JavaScript Protocol Listeners Application node.js Other Tiers Code Libraries

Modifies DOM visualizeJSDOM, how data Contextify flows html…

use same style as other figs

Figure 2: Single Process CloudBrowser Architecture Overview

Client Layer Web Layer Storage Layer A fourth concern which this paper focuses on, is how to Internet implement scalability across multiple processes and/or ma- chines. Related to that is the behavior of the system if server Web Browser HTTP Requests Dispatch processes fail or must be restarted for other reasons. Fig. 1 Internal Load Protocols shows a canonical architecture used for scalable, multi-tier Balancer web applications, of which numerous variations exist. Scala- Web Browser HTML, JSON, javascript… bility is achieved by having a load balancer spread individual HTTP requests across multiple web or application servers, which in turn talk to databases or other storage providers. In this model, the load balancer must be able to dispatch HTML, CSS, Javascript, requests to any web server as web servers can be added and Bootstrap, JQuery, Web Servers Back-end Servers Angular, Reactjs … Tomcat, Apache, PHP, MySql, Redis, BigTable removed at will. To handle a request, a web server needs JSP, Ruby on Rails … Cassandra, … to have access to session state, which is replicated and kept Figure 1: Traditional Scalable Multitier Application Design consistent across the web servers. Though session state may be cached in a web server’s memory, it is stored in a way that allows for server processes to restart. At the same time, loss of session state is not catastrophic as essential user data and not help at all when the user switches devices. As is stored in a separate storage layer. such, it cannot support inquiries by code about computed or user-determined attributes such as what is the screen size, A scalable virtual browser environment can be implemented or what is the height of an element after its layout has in similar fashion; however, here the load balancer is re- been computed. Recent trends in web development have stricted in the choice of web server to which to forward re- made this much less of a problem; for instance, in applica- quests as soon as a server process is chosen on which the vir- tions that use responsive design (e.g. the Bootstrap library), tual browser is allocated. A crash or restart of such a process programmers are discouraged from directly inquiring about leads to the loss of all presentation state. To prevent this computed style attributes. from becoming catastrophic, applications developers must, as before, decide which part of their state is deemed essen- Secondly, since events are dispatched on the server, the delay tial data that must be stored in the separate storage layer. of a wide area network roundtrip is added to the process- This can be done by accessing existing storage layers, but ing delay, along with any request queuing that may occur. we also added a facility that allows applications to save a According to the human computer interface literature, the snapshot of their state and resume from it later. resulting latency must not be larger than 100-150ms for the user to be perceived negatively. We treat this as a cut-off for the feasibility of a server-centric design. 3. DESIGN AND IMPLEMENTATION A third concern is resource consumption, in particular mem- Full details of a single process implementation of the Cloud- ory and CPU consumption. Virtual browsers will consume Browser architecture are available in [9]. We highlight only memory while they exist, and consume CPU time while han- the essential design here. Figure 2 shows the relationship dling events. The use of high-level JavaScript libraries exac- between the client engine running in the user’s browser and erbates this effect because they are often designed for use on the virtual browser running server side. When the user vis- powerful client machines, although optimizations in terms its the application, the client engine code is downloaded and of CPU and memory for use on less powerful mobile devices restores the current view of the application by copying the helps us. current state of the server document. Subsequently, user in- put is captured, forwarded to the server engine inside the virtual browser, which then dispatches events to the docu- example.com CloudBrowser Installation ment. All application logic runs in the global scope asso- http://example.com/app1 http://example.com/app2 ciated with the virtual browser’s window object. Since the Application 1 Application 2 server environment faithfully mimics a real browser, libraries … such as AngularJS can be used unchanged to implement the multi-instance single-instance user interface. Client and server communicate through a lightweight RPC protocol that is layered on top of a bidirec- Application 1 Application 1 Application 1 Application 2 tional web socket communication. Stylesheets, images, etc. Instance 1 Instance 2 Instance 3 Instance 1 + + are provided to the client through a resource proxy. + +

Virtual Virtual Virtual 3.1 Application Deployment Model Browser 1 Browser 2 Browser 1 Must be colocated in the same process We designed an application deployment model for Cloud- co-browse Browser 2.0 that allows different instantiation strategies. This deployment model addresses a problem that traditional web applications so far have not faced, which is to manage the lifetime of virtual browsers as users create them, connect to them, and disconnect from them. The underlying goal is to minimize the level of awareness on both the side of the Figure 4: Hierarchy of applications, application instances, and virtual browsers. Note that a single virtual browser may be broad- + application developer and the applications’ users. cast to multiple clients (cobrowsing). + + Application programmers can create CloudBrowser applica- + tions in the same way in which they create the client-side portion of a client-centric application, using low or high level chatroom(s), users and their associated messages. JavaScript libraries such as jQuery [8] or AngularJS. A de- The hierarchy that results from applications, application in- scriptor in the application’s manifest describes their appli- stances, and virtual browsers is depicted in Figure 4. This cation’s required instantiation strategy. When a user in- figure shows the general case in which an application might stantiates an application, the allocated application instance allow multiple instances, and in which each user can cre- object representsApp Instance metadata Figure about this application instance, ate multiple virtual browsers. We also found it useful to such as ownership and access permissions, along with appli- support more specialized instantiation modes, which are re- cation data that the application’s code can directly access. lated to the user’s authentication state. These include sin- gleAppInstance, singleUserInstance, and multiInstance, and

User Session 1 User Session 2 User Session 3 correspond to a single instance for all users (as in a tradi- tional webpage), a single instance per authenticated user, and multiple instances per user. Only the last instantiation

Virtual Browser 1 Virtual Browser 2 Virtual Browser 3 mode exposes users to a management interface for virtual View browsers that allows them to create new virtual browsers, or reconnect to existing ones when the connect/disconnect Model Application code Application code Application code from the web applications.

Chat App User Chat App User Chat App User ChatRoom ChatRoom ChatRoom 3.2 Distributed Implementation Figure 5 shows the distributed design of CloudBrowser 2.0, Reference ChatRoom Messages Reference which consists of a single master process, multiple reverse App Instance ! PostMessage() proxies, and multiple worker processes. The number of work- ers is determined by the number of CPUs available, due to Figure 3: This figure shows how multiple virtual browsers can the event-based (nonblocking) implementation of the node.js directly, and seamlessly share relevant application data, in this case chat messages, which then become part of the model that platform on which CloudBrowser is implemented. All pro- drives the presentation MVC framework. cesses communicate via standard TCP/IP sockets, so they can be located on a shared multiprocessor machine or in a cluster. As an example, consider a scenario for a Chat application de- veloped using AngularJS, depicted in Figure 3. A system ad- The master process maintains a table of which application ministrator of a CloudBrowser deployment would install the instances have been created and which worker is responsi- application, which give users the ability to create application ble for which application instance. When a new application instances. To start a chat site, a user would create an ap- instance is created, the master will apply a load balancing plication instance and share its URL with chat participants. algorithm to decide on which worker to place this instance. As the participants join the chat site, a virtual browser is We support two load balancing strategies: first, the mas- created on demand for each participant, which is connected ter can assign application instances to workers in a simple to the application instance (the users can bookmark their round-robin fashion. However, since application instances virtual browser’s URL to later return.) The shared appli- may vary widely in terms of the actual cost they impose on cation instance data in such an application consist of the a worker, we also implemented a load-based scheme in which TCP/IP

Web Browser Forwards Events Worker 1 App Instance 1

Reverse Proxy Dispatch App Instance 2 Web Socket Virtual Browser 2-1 Client Engine Web Socket Connection Connection Virtual Browser 2-2 Sends Updates DOM Listens Applies DOM Updates for Events Updates Virtual Browser 2-3 Master DOM App Instance Reference App Instance Object Map

Worker 2 App Instance … Load Balancer

Figure 5: Multiprocess Architecture Overview workers periodically report a measure of current load to the 4. EVALUATION master. Our main focus in this evaluation is to demonstrate that Multiple reverse proxy processes are bound to the socket the multiprocess implementation in CloudBrowser 2.0 can that accepts client requests, allowing the OS to distribute scale with the number of available cores on which to place pending client connections in a round-robin fashion. When a separate workers. Our secondary focus is to investigate the proxy process accepts a client, it parses the incoming HTTP cost of using different client libraries on the throughput we Worker 2 request to extract the application id, which is part of the re- achieve. quest’s URL. Each proxy process maintains a table of known App Instance 3 To test CloudBrowser 2.0 with existing applications, we de- mappings from application ids to workers. If the requested veloped a small expect-like language in which to describe id is already cached in that table, the request is directly scenarios. A client test tool interprets test scripts written relayed to the worker. Otherwise, the master is contacted in this language and makes RPC calls to a server in the to find out which worker is assigned to that application id, same way the client engine would in actual deployment, then triggering an initial assignment if necessary. The reverse checks whether the server is making the expected RPC calls proxy can relay both HTTP requests/responses as well as back that would reflect requests to the client engine to up- the bidirectional web socket protocol after the connection date the DOM the user sees. Like a (patient) human user, has been upgraded. Once established, the majority of traf- the script will not send the next event until after the previ- fic will be web socket messages for which there is relatively ous event resulted in the expect DOM update. To simulate little per-message overhead. human processing speed, a programmable “thinking delay” can be introduced between receiving an expected response 3.3 Interprocess Communication and sending the next event. To create test scenarios from Masters, proxies, and workers need to be able communicate actual applications, we run those applications using a real with one another. This communication takes places at the browser and record the client/server interactions in a log, level of JavaScript method calls. To facilitate the invocation which our test tools can reply. of JavaScript methods that belong to objects residing in We used a dual-socket, 8 core Intel Xeon 2.27GHz processor other processes, we developed nodermi, a remote method with 38GB of RAM on the machine on which we run Cloud- invocation (RMI) library [12]. Browser 2.0’s master, worker, and proxies. We colocate the nodermiuses JavaScript’s reflection facilities to transpar- first proxy with the master in the same process. This sys- ently create client-side stubs for remote objects on the fly. tem is connected via Gigabit Ethernet to a 8 core AMD Since JavaScript does not use static typing and heavily uses machine with 16GB of RAM on which the test client(s) ex- variadic functions, it serializes method arguments dynami- ecute. Both machines run Ubuntu 14.04 with a stock Linux cally via reflection. Our system supports all primitive Java- 3.13 kernel. We use Node.js 0.10.33 and the version of JS- Script types, objects, and arrays; it can handle cyclic object DOM 2.0 we customized. We use the static load balancing graphs. It also recognizes when arguments refer to remote strategy discussed in Section 3.2 to ensure an exactly pre- objects, in which case the receiving side will create its own dictable distribution of application instances onto workers. stub that directly refers to the remote object. If an argu- ment is a function, a stub will be created on the remote side that, when invoked, will make a RPC request back to the 4.1 Click Application requestor. Our first benchmark is a simple click application that in- crements a counter on a page whenever the user clicks. It to support up to 8,000 operations per second at which point is written without any libraries, making direct use of the it becomes CPU bound; for the 6 and 8 worker cases, we JavaScript DOM API. It only has 14 lines of HTML and add a second proxy process. Since the reverse proxy pro- 5 lines of JavaScript code. As such it most closely mea- cesses run on the same machine as the workers, throughput sures the overhead of our framework only, e.g. the overhead does not increase beyond 6 workers since this machine has of making RPC calls, serialization and deserialization, and only 8 cores. We carefully monitor the CPU usage on the dispatching events into the server-side DOM, observing any benchmark client machine, adding new test driver instances DOM changes occurring as a result, and relaying those to as needed, up to 8. the client. We consider two possible scenarios, a fast “Back-to-back” Click application with delay 10000 1 worker click application with no thinking times between clicks, and 2 workers 9000 4 workers a more “Human-paced” click application in which there is a 6 workers think time drawn from a uniform distribution in the range 8000 8 workers of 1 to 2 seconds. We perform 5 runs for each data point 7000 and report the mean. For all benchmarks, the variance was 6000 small. The vast majority of data points incurred a relative 5000 standard error below 5%, the maximum relative standard error was 11%. 4000 3000 Throughput(operations/second) Click application 2000 14000 1 worker 1000 2 workers 4 workers 12000 6 workers 0 8 workers 0 5000 10000 15000 20000 25000 30000 client count 10000 Figure 8: Throughput of click application, after introducing 8000 artificial delay.

6000 For the back-to-back scenario, throughput is limited by the 4000 CPU capacity available to the workers for 100 clients or Throughput(operations/second) more. Throughput stays relatively constant as the number 2000 of client increases, but the observed latency increases, which is shown in Figure 7. We consider a latency of more than 0 0 200 400 600 800 1000 1200 100ms unacceptable [11], which is why we cut off the y-axis client count accordingly. In this scenario, a single worker can support up Figure 6: Throughput of “Back-to-back” click application. to 200 clients, and 6 workers can handle about 1,200 clients before latency increases to unacceptable levels. When introducing think times to simulate “human-paced” Click back to back clients, we obtain the throughput and latency shown in Fig- 200 1 worker 2 workers ures 8 and 9. In those cases, a larger number of clients 4 workers 6 workers can be supported, and maximum throughput will not be 8 workers reached until the number of clients ramps up. For each 150

Human paced click application 100 200 1 worker 2 workers Latency(ms) 4 workers 6 workers 8 workers 50 150

0 100 0 200 400 600 800 1000 1200

client count Latency(ms)

Figure 7: Latency of “Back-to-back” click application. 50

We measure throughput in terms of operations per second and average latency. Figure 6 shows the throughput of the 0 0 5000 10000 15000 20000 25000 30000 application for different numbers of workers. In those cases, client count all workers become CPU bound, adding more workers that can use additional cores increases throughput near linearly Figure 9: Latency of click application, after introducing artificial up to 6 workers. In this scenario, a single proxy is sufficient delay. Chat application with Angular.js 200 1 worker 2 workers 4 workers 8 workers

150

100 Latency(ms)

50

0 0 200 400 600 800 1000 1200 1400 1600 1800 client count

Figure 11: Latency of chat application with Angular.js. Figure 10: Chat Room Application

Chat application with JQuery 200 1 worker worker configuration, the maximum acceptable latency is 2 workers 4 workers reached slightly before maximum throughput is reached. In 8 workers these experiments, we do not increase the number of clients 150 further if latency has already reached unacceptable levels. We must note that the latency reported here does not in- clude a wide-area network (WAN) delay; which when taken 100 into account would reduce the bounds on acceptable pro- Latency(ms) cessing delay. Nevertheless, we conclude that our method of scaling to multiple processes is effective and that the reverse 50 proxy in particular does not become a bottleneck.

4.2 Chat Application 0 0 500 1000 1500 2000 2500 3000 3500 A key part of the productivity promise for using the server- client count centric CloudBrowser framework is the ability to reuse high- level libraries such as AngularJS with little or no changes, so Figure 12: Latency of chat application with JQuery. that applications prototyped in AngularJS can be directly executed in virtual browsers. These libraries are designed performance by 20%. for client-side use, however. We prototyped a Chat appli- cation to investigate the overhead of this usage scenario, a To eliminate the impact of AngularJS, we also reprototyped screenshot is shown in Figure 3. The application is only 207 the same application with a lower-level library, jQuery, which lines of HTML and JS code while providing features such increased its size significantly (and made it significantly less as creating chatrooms, joining them, chatting and changing readable). Avoiding AngularJS’s method of dirty checking the desired display name. to identify model changes roughly doubled performance, as shown in Figure 12. We make use of shared application instance data as discussed in Section 3.1 to hold the last 50 chat messages. Each ap- plication instance is visited by 5 simulated users, each in- 5. RELATED WORK stantiating their own virtual browser. Each user sends 100 ZK [3], which we use as part of our motivation in Section 2 chat messages in our script, consisting of a sentence of 15-20 is a Java-based server-centric web framework that is in wide characters. We set the think time to 5-10 seconds between use. ZK applications are constructed using components, messages. We define latency as the time taken to hit enter which are represented using the ZK User Interface Markup and when the message appears in the chat window. Language (ZUML). ZUML components are translated into Fig.11 shows the latency perceived by benchmark tool un- HTML and CSS when a page is rendered. A client-side li- der different numbers of clients. While scaling to multiple brary handles synchronization between the client’s view of workers remains effective, the use of AngularJS imposes a and interaction with components and their server-side repre- significant cost, reducing the number of concurrent users sentation. Our extensive experience deploying applications that can be supported with the same hardware. Most of the with ZK ([15, 4]) inspired the work on CloudBrowser. As time is spent in the AngularJS framework, which we discov- discussed, ZK does not maintain a representation of the ered through profiling. Optimizations made in successive server document across page reloads, which means that all revisions of AngularJS heavily impacted our performance; presentation state must be tied to session or persistent state. for instance, a single commit to optimize needless reexecu- To scale ZK to multiple processes or servers, this session tion of so-called filters in AngularJS improved benchmark state must be replicated. Unlike CloudBrowser, ZK aims to support layout attributes, ment, improved user experience across visits without requir- but we have found that the complexity of its client engine ing programmer effort, and potentially increased security. leads to numerous layout and compatibility bugs developers As such, it has the potential to lead to applications that must work around, particularly when the server-side doc- truly “live” in the cloud, rather than merely interactive web ument and the client-side document are not identical. By pages. contrast, CloudBrowser uses identical, HTML-based docu- Our results show that this design can be implemented in ments on the client and the server. a scalable way such that adding more resources results in ItsNat [13] is a Java-based AJAX component framework a proportional increase in capacity. However, it also shows similar to ZK, although it uses HTML instead of ZUML to that the use of code and libraries originally intended for express server documents, along with the Java W3C imple- client-side use on the server can be very expensive, primar- mentation. Unlike CloudBrowser, it also does not maintain ily in terms of CPU time. These limitations will narrow the server document state across visits, and cannot make the scope of applications for which a pure server-centric ap- use of existing JavaScript libraries. proach such as ours is applicable. The Google Web Toolkit [6] allows the implementation of AJAX applications in Java that are compiled to JavaScript 7. ACKNOWLEDGEMENTS (or other targets). Like CloudBrowser, it provides an envi- This material is based upon work supported by the National ronment similar to that provided by desktop libraries, but fo- Science Foundation under Grant No. CCF-0845830. The cuses on the client-side only; communication with the server source code for CloudBrowser 2.0 is available at https:// is outside its scope. github.com/brianmcd/cloudbrowser, branch deployment2. A closely related project that pursues similar goals in sim- plifying the development of rich web applications is Me- teor [10], a full stack platform for building web and mobile 8. REFERENCES applications. Meteor provides mechanisms that tie a client’s [1] Apple Inc. Connect your iPhone, iPad, iPod touch, presentation state directly to model state that is kept in a and Mac using Continuity. http://support.apple.com/en-us/HT6337, 2014. server-side database, which in turn is partially replicated [2] A. Bailey and G. Back. Streamlining access to library on the client. As such, user input can be handled, opti- resources. In E. Iglesias, editor, Robots in the mistically, before the server roundtrip has completed. If an Academic Library. IGI Global, Hershey, PA, 2013. update is rejected by the server, the optimistic application [3] H. Chen and R. Cheng. ZK: Ajax without the is undone. Like with client-centric frameworks, no presen- Javascript Framework. Apress, Berkeley, CA, USA, tation state is kept on the server. Asynchronous updates to 2007. model data is pushed to clients. [4] S. H. Edwards and G. Back. Bringing creative web 2.0 programming into CS1: conference workshop. J. Meteor will have lower server-side cost, and thus higher scal- Comput. Sci. Coll., 26(3):54–55, Jan. 2011. ability, than CloudBrowser, as well as the ability to reduce [5] T. Gaat. The LibX edition builder. Master’s thesis, user-perceived latency because of its optimistic processing. Virginia Tech, 2007. However, we believe that this comes at a high price of com- [6] Google, Inc. Google Web Toolkit (GWT). plexity and increased risk. For instance, programmers must http://code.google.com/webtoolkit/. be extremely careful to not leak sensitive data to the client, [7] M. Hevery. Building web apps with Angular, 2009. and they may easily expose (unintentionally) sensitive busi- [8] jQuery Foundation jquery.org. jQuery. http://jquery.com/, 2015. ness logic to the client. Meteor also does not focus on the [9] B. McDaniel and G. Back. The CloudBrowser web problem of simplifying the retention of presentation state application framework. In Proceedings of the 3rd across visits, either making that state ephemeral, or requir- annual conference on Systems, programming, and ing the programmer use session state or store all necessary applications: software for humanity, pages 141–156. model variables in the database. ACM, 2012. [10] Meteor. https://www.meteor.com/, 2015. Lastly, our system shares ideas with traditional thin-client [11] J. Nielsen. Usability Engineering. Morgan Kaufmann, and remote display systems, going back to “dumb termi- 1st edition, Sept. 1993. nals” based on the X Window System [14]. We note that [12] X. Pan. nodermi. VMWare’s Horizon product provides a way to see the user https://github.com/bladepan/nodermi, 2014. interface of actual virtual machines via a browser, with its [13] J. M. A. Santamaria. ItsNat: Natural AJAX. BLAST protocol. Compared to these systems, CloudBrowser component based Java web application framework. is unique in that it uses a markup document and differential http://itsnat.sourceforge.net. [14] R. W. Scheifler and J. Gettys. The X window system. update to it to describe the structure and evolution of the ACM Trans. Graph., 5(2):79–109, Apr. 1986. user interface that is rendered to the user. [15] E. Tilevich and G. Back. ”Program, enhance thyself!”: demand-driven pattern-oriented program enhancement. In Proceedings of the 7th international conference on Aspect-oriented software development, 6. CONCLUSION AOSD ’08, pages 13–24, New York, NY, USA, 2008. This paper discusses a scalable, multiprocess implementa- ACM. tion of web application framework that maintains rich pre- sentation state server-side. This approach has many advan- tages, from simplified and accelerated application develop-