Modular Asynchronous Web Programming: Advantages & Challenges Wiliam Rocha Shibaura Institute of Technology Japan xl15607@shibaura- it.ac.jp Hiroaki Fukuda Shibaura Institute of Technology Japan hiroaki@shibaura-it.ac.jp Paul Leger Universidad Catolica del Norte Chile pleger@ucn.cl ABSTRACT Because of the success of the Internet technologies, tradi- tional standalone applications like Spreadsheet and Drawing are now provided as Web Applications. These adopt asyn- chronous programming that provides high responsive user interactions. At the same time these applications can grow and make their maintenance harder, turning Modular Pro- gramming an attractive practice because of its concept of dividing concerns in separated modules. However, it’s dif- ficult to combine asynchronous methods and modular pro- gramming because the first requires uncoupling a module into two sub-modules, which are non-intuitively connected by a callback method. It can spawn the creation of other two issues: callback spaghetti and callback hell. Some propos- als have been developed to reduce the issues about modular programming. In this paper, we compare and evaluate them applying them to a non-trivial open source application, the FlickrSphere. Then, we will discuss our experience. General Terms Algorithms, Measurement, Design, Reliability, Experimen- tation, Verification Keywords Asynchronous programming; aspect-oriented programming 1. INTRODUCTION Due the growth of high speed networks, traditional stan- dalone applications such as drawing and spreadsheet soft- ware are now provided using web technologies, namely Web Applications. Such modern applications adopt asynchronous techniques such as AJAX, providing high responsive user in- teraction. At the same time, as the scale of such applications grows, its maintenance becomes more complex and there is where modular programming shines because it allows sepa- rating concerns into modules[8], meaning that changes made in one concern does not affect the others (e.g., other mod- ules), turning the maintenance easier and safer. The ba- sic idea of asynchronous programming is to decompose a blocking operation that awaits for its completion into a non- blocking operation that immediately returns the control by a callback method. Therefore, this practice can reveal two issues: callback spaghetti[6] and callback hell[7]. Callback spaghetti refers to the concern of the implementation when we have a complex and tangled control structure to the fol- lowing executions over many callback methods. Callback hell refers to deeply-nested callbacks that have dependen- cies on data returned from previous asynchronous invoca- tions. Also, the combination of Asynchronous Programming and Modular Programming can lead to structural problems that conflicts the concept of each one, because modules will need to be divided in two sub-modules that will be non- intuitively connected by a callback method called after the asynchronous function ends its execution and in a large scale application, the execution flow will be really trick to be tracked. Some proposals have been presented to crawl these issues such as async/await from C#[1], Promise pat- tern from JavaScript[3] and SyncAS from ActionScript[4]. Although the Promise and SyncAS versions were developed as Web Applications, the async/await version was devel- oped as a common Windows Application. But it’s impor- tant to denote that the async/await constructs work in a Web Application project too. This paper evaluates these proposals applying them to a non-trivial open source appli- cation called FlickrSphere[9], originally implemented in Ac- tionScript3, using nested and iterative asynchronous func- tions which will bring some drawbacks such as Callback spaghetti and Callback hell. Then, our experiences will be discussed about the implementations. 2. ASYNCHRONOUS PROBLEMS Nowadays, asynchronous programming is widely-adopted by programmers. This section briefly compare asynchronous programming and synchronous programming. 2.1 Synchronous Programming Synchronous programming is the common style taught to programmers. Listing 1 shows one example of an applica- tion. The ImageViewer class contains one method: showFro- mURL. It basically downloads data from an image to dis- play it. It’s important to assume that the method download from Request class is a blocking operation that downloads data and takes significant time. The control flow is clear because each instruction needs to end and then advance. BICT 2015, December 03-05, New York City, United States Copyright © 2016 ICST DOI 10.4108/eai.3-12-2015.2262472