Evaluation and comparison of ajax frameworks regarding applicability, productivity and technical limitations E-Book
Lukas Ostermaier
36,99 €
Mehr erfahren.
- Herausgeber: GRIN Verlag
- Sprache: Englisch
Master's Thesis from the year 2008 in the subject Computer Science - Internet, New Technologies, grade: 1.0, Vienna University of Technology (Department of Distributed and Multimedia Systems), language: English, abstract: The rapidly growing popularity of Ajax has led to the publication of numerous frameworks in the last years. Not only big companies but also small development teams have developed their own Ajax frameworks or libraries. Consequently, finding the best framework for a specific project can be difficult and time-consuming. This thesis compares three of the most popular Ajax frameworks in order to facilitate the technology selection process. The evaluation was carried out by implementing a tracking system for public transportation with particular focus on the applicability, productivity and technical limitations of each framework and Ajax in general. In addition, this thesis presents a general approach for the evaluation of arbitrary Ajax frameworks and points out particular issues that should be given special consideration when applying Ajax initially. The thesis concludes with a brief analysis of trends that may be relevant to the future development of Ajax.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Veröffentlichungsjahr: 2008
Ähnliche
Page 1
Page 2
the last years. Not only big companies but also small development teams have developed their own Ajax frameworks or libraries. Consequently, finding the best framework for a specific project can be difficult and time-consuming. This thesis compares three of the most popular Ajax frameworks in order to facilitate the technology selection process. The evaluation was carried out by implementing a tracking system for public transportation with particular focus on the applicability, productivity and technical limitations of each frame-work and Ajax in general. In addition, this thesis presents a general approach for the evaluation of arbitrary Ajax frameworks and points out particular issues that should be given special consideration when applying Ajax initially. The thesis concludes with a brief analysis of trends that may be relevant to the future development of Ajax.
Page 3
5.2.4. ASP.NET Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2.5. Backbase Ajax 360 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.6. Direct Web Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2.7. Dojo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.8. Google Web Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2.9. JMaki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.10. Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.11. Rico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.12. Script.aculo.us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2.13. Spry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.14. Yahoo! User Interface Library . . . . . . . . . . . . . . . . . . . . . . 48
5.4.1. Classification according to the Level of Adoption . . . . . . . . . . . . 51 5.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6. Evaluation Procedure and Sample Application 53
6.1. Description of the Sample Application . . . . . . . . . . . . . . . . . . . . . . 53 6.1.1. Detailed Description of the Tracking System . . . . . . . . . . . . . . 53 6.1.2. Application specific Requirements for the Ajax Frameworks . . . . . . 56 6.2. Evaluation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.2.1. Selection Criteria for the Ajax Frameworks . . . . . . . . . . . . . . . 57 6.2.2. Selected Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.2.3. Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.2.4. Detailed Test Specification . . . . . . . . . . . . . . . . . . . . . . . . 63
7. Framework Evaluation 68
7.1. Adobe Spry Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.1.1. Implementation of the Sample Application . . . . . . . . . . . . . . . 68 7.1.2. General Aspects of the Framework . . . . . . . . . . . . . . . . . . . . 70 7.1.3. Developing Company and Community . . . . . . . . . . . . . . . . . . 73 7.1.4. History, Maturity, Outlook of the Framework . . . . . . . . . . . . . . 74 7.1.5. Costs of the Framework and Terms of License . . . . . . . . . . . . . . 76 7.1.6. Available Documentation and Support . . . . . . . . . . . . . . . . . . 77 7.1.7. Productivity of Development . . . . . . . . . . . . . . . . . . . . . . . 77 7.1.8. Generated Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.1.9. Client-side Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.1.10. Load and Response Times of the Application . . . . . . . . . . . . . . 80
Page 4
7.1.11. Maintainability of the Application . . . . . . . . . . . . . . . . . . . . 81 7.2. Google Web Toolkit Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.2.1. Implementation of the Sample Application . . . . . . . . . . . . . . . 81 7.2.2. General Aspects of the Framework . . . . . . . . . . . . . . . . . . . . 82 7.2.3. Developing Company and Community . . . . . . . . . . . . . . . . . . 88 7.2.4. History, Maturity, Outlook of the Framework . . . . . . . . . . . . . . 89 7.2.5. Costs of the Framework and Terms of License . . . . . . . . . . . . . . 91 7.2.6. Available Documentation and Support . . . . . . . . . . . . . . . . . . 91 7.2.7. Productivity of Development . . . . . . . . . . . . . . . . . . . . . . . 91 7.2.8. Generated Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.2.9. Client-side Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.2.10. Load and Response Times of the Application . . . . . . . . . . . . . . 94 7.2.11. Maintainability of the Application . . . . . . . . . . . . . . . . . . . . 95 7.3. ASP.NET Ajax Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7.3.1. Implementation of the Sample Application . . . . . . . . . . . . . . . 96 7.3.2. General Aspects of the Framework . . . . . . . . . . . . . . . . . . . . 97 7.3.3. Developing Company and Community . . . . . . . . . . . . . . . . . . 102 7.3.4. History, Maturity, Outlook of the Framework . . . . . . . . . . . . . . 102 7.3.5. Costs of the Framework and Terms of License . . . . . . . . . . . . . . 104 7.3.6. Available Documentation and Support . . . . . . . . . . . . . . . . . . 104 7.3.7. Productivity of Development . . . . . . . . . . . . . . . . . . . . . . . 105 7.3.8. Generated Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.3.9. Client-side Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.3.10. Load and Response Times of the Application . . . . . . . . . . . . . . 107 7.3.11. Maintainability of the Application . . . . . . . . . . . . . . . . . . . . 108 7.4. Overall Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 7.4.1. Analysis of the Features and general Aspects . . . . . . . . . . . . . . 108 7.4.2. Developing Company and Community Analysis . . . . . . . . . . . . . 109 7.4.3. History, Maturity and Outlook Analysis . . . . . . . . . . . . . . . . . 110 7.4.4. Cost and License Analysis . . . . . . . . . . . . . . . . . . . . . . . . 111 7.4.5. Analysis of the available Documentation . . . . . . . . . . . . . . . . 112 7.4.6. Analysis of the Productivity of Development . . . . . . . . . . . . . . 112 7.4.7. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.4.8. Client-side Workload Analysis . . . . . . . . . . . . . . . . . . . . . . 114 7.4.9. Load and Response Time Analysis . . . . . . . . . . . . . . . . . . . . 115 7.4.10. Analysis of Maintainability Aspects . . . . . . . . . . . . . . . . . . . 116
8. Further Issues and Outlook 117
Page 6
1. Introduction
For some years the Internet has been dominated by phrases like Web 2.0 and Ajax. The catch-word Web 2.0, which was originally established by O’Reilly at the first Web 2.0 conference in October 2004, not only describes a new way of perception and usage of the internet (e.g. social software like blogs, wikis, etc.), but also stands for more or less innovative techniques as for instance RSS or Ajax. The latter is a combination of techniques that have been available since the late 1990s, such as JavaScript, asynchronous requests and XML. However, the term Ajax only exists since Jesse James Garret introduced it in his article [Gar05] in February 2005. Since then Ajax has experienced a real hype. Google Mail, Google Maps or Flickr just serve as examples for the mass of applications that have to attribute their success substantially to Ajax. When it comes to web application development there has also been a lot of progress in the field of Ajax: Ajax frameworks of all kinds massively gained popularity and flooded the development community. From the biggest companies through to small development teams, almost everyone has published his own Ajax framework or library in the last two years. In the meantime there are far more than 150 different frameworks for various programming languages and diverse aims. Because of this uncontrolled growth of frameworks it is quite difficult to say which of those is most suitable for a specific project.
There are two key questions that have to be considered in case of Ajax or Rich Internet Applications1(RIAs) in general: How can Ajax significantly increase the business value of an application and how can it be applied productively? This thesis mainly focuses on the latter question by evaluating three Ajax frameworks of large companies with a strong background by means of an example application with respect to commercial applicability, productivity, performance as well as enhancement and adaptation possibilities. Furthermore this work discusses the technical limitations and problems of Ajax and provides an outlook on future developments in this area.
As example application for the evaluation a web-based tracking system for public transportation is implemented. Each single vehicle is visualized on a street map according to its current position. By the implementation of this application with each of the three chosen Ajax frame-works their applicability, productivity and performance is illustrated as well as their weaknesses and limitations.
In order to provide a short overview about this topic, Section 2 defines the term Rich Internet
1A definition of the termRich Internet Applicationis provided in Chapter 2.
Page 7
Application, compares it to conventional web applications and discusses its advantages and weaknesses. In Section 3 a short overview about the different RIA technologies is given and the basic differences to Ajax are highlighted. Section 4 describes the technical aspects of Ajax, gives a critical view on the hype of Ajax and reveals the challenges developers have to face when introducing Ajax. Furthermore some categories of typical Ajax applications as well as different levels of Ajax adoption are defined in this part.
Section 5 defines the general requirements for an Ajax framework, gives an overview over a short selection of diverging frameworks and classifies them in two different ways. In Section 6 the sample application is described in detail and the evaluation procedure as well as the criteria upon which the evaluation is based are specified. Section 7 represents the core of this paper by presenting each of the three frameworks explicitly including the results of the evaluation. At the end of this part these results are compared to each other in order to highlight the differences between these frameworks. Finally, in Section 8 an outlook on current trends and future developments is given.
Page 8
2. The Trend to Rich Internet Applications
Rich Internet Applications (RIAs) are currently becoming more and more popular and there is no indication that this trend will stop in the near future. Since Ajax is a technique for creating RIAs it is part of this trend. Therefore, this chapter takes a closer look at RIAs in general by describing what they are and how they relate to traditional web applications. Furthermore it outlines the advantages and disadvantages of this kind of web application.
2.1. What is a Rich Internet Application?
A Rich Internet Application is something between a web application and a desktop application and combines the benefits of both approaches. Desktop applications are highly responsive and interactive and certainly have advantages when it comes to graphics (especially vector graphics) as well as audio and video applications. There is no need to load data from a remote machine as the application is installed locally and therefore it is reacting immediately to the user’s actions. The drawbacks of desktop applications are obviously that they depend on the underlying platform and distribution and maintenance costs are much higher. A traditional web application based on HTML has its strengths where a desktop application has its weaknesses: They are highly available through the web and are by far easier maintainable as they do not require any updates or patches to be shipped. Furthermore web applications are platform independent since they are based on standards like HTML and are running within a browser. However, they also have some disadvantages: They are by far not as responsive and interactive and not very well-suited for visualizing or manipulating complex data or charts. A quite disturbing mannerism of web applications is that for each task a new page has to be loaded [Deb06].
Rich Internet Applications attempt to combine the advantages of both types of applications and to eliminate their disadvantages. They combine ‘the reach of Web applications with the richness of desktop applications’ [Bac07]. The main benefits of RIAs are described in the following list:
• Rich Internet Applications provide a rich user interface which is not downloaded repeatedly as in traditional web applications. This user interface provides interactive UI controls in order to support increased interactivity (e.g. sortable lists, drag & drop, tree views, etc.) and make the application more feel like a desktop application.
Page 9
• The application reacts immediately to user actions without reloading the entire application. Contrary to traditional web applications some actions can be entirely handled by the client without asking the server. However, if a request has to be send to the server it is done asynchronously for not breaking the user’s workflow.
• Rich Internet Applications reduce the bandwith since the application is only downloaded once and updated according to the user’s requests.
• RIAs have almost the same reach as traditional web applications as they are accessible via the web. Only specific requirements, like plug-ins or certain browser versions, may restrict the use of the application.
• Their maintenance costs are as low as those of conventional web applications since the application is not installed locally and therefore no updates have to be distributed.
Table 2.1 summarizes this comparison between desktop, web and Rich Internet Applications. It shows where each type of application has its strenghts and weaknesses and shows how RIAs try to combine the benefits of the others.
nesses. First of all they need a special plugin (e.g. a Flash Player or a Java Runtime Environment) or have special requirements for the browser (e.g. that JavaScript is enabled or that it supports the XMLHttpRequest object). A lack of these settings entails that the application is not executable on a specific client or may lead to unexpected behaviour because of unsupported functions or different browser implementations.
Another drawback is that the history function every browser offers does not work properly with Rich Internet Applications since they usually represent a single page. If the back button is pushed by the user the browser displays the page that has been requested before starting the application which is often not intended by the user. Since RIAs change their state without changing the page, bookmarking the current state of an application cannot be done by simply bookmarking the page’s URL. Some RIA technologies even offer ways to bypass this problem but currently these features are rarely used.
Page 10
Since Rich Internet Applications need, contrary to traditional web applications, some additional client side logic, the initial download of the application may last longer. It depends on the application how much has to be downloaded at the startup and which parts are downloaded on demand. These decicions depend most notable on the type of application.1
Another characteristic of RIAs is that they require more resources on the client since their main part is running there. The positive effect of this shift is that the server is relieved of these tasks which are now performed on the client. Old devices that do not have much computational power may have problems when executing Rich Internet Applications in combination with other applications.
Rich Internet Application also bring a new, though desirable, user experience. Some users might be irritated by the new way of interaction with this kind of web application, e.g. the browser’s back button. Due to the rich effects that are possible with these technologies, another risk might stem from the fact that the application gets overloaded and possibly discourages the user to use it. Therefore, a very important issue is to create user friendly applications in order to minimize these risks and avoid user dissatisfaction.
Since (most of) these applications are running in the browser’s sandbox they usually do not have access to system resources.2For example it is not allowed for an application running in the browser to access the file system without special privileges the user has to grant. This may lead to the situation that the user is afraid of granting these privileges but the application does not work properly without them.
When it comes to accessibility aspects Rich Internet Applications are also unfavourable. Since many RIAs use JavaScript, similiar scripting languages or animations that are not sup-ported by screen readers visually handicapped people may not use the application. Providing an additional version that is accessible for a broader audience may be a possible workaround to this problem but is also associated with extra costs, especially when it comes to maintenance issues. Providing a sound solution to this issue will be a challenge for the future in order to make these applications also accessible for handicapped people.
A big advantage of conventional web sites is that they can be easily found using search engines. To achieve this these sites have to be indexed by the search engine. Since Rich Internet Applications do not consist of several HTML pages their content might be invisible to search engines. A short summary of all advantages and disadvantages is also provided in Section 2.3.
1See Section 4.4 for a description of some popular categories of Rich Internet Applications.
2Only Adobe AIR (see Section 3.5) allows access to system resources since it is not running in a browser but
directly on the desktop.
Page 11
2.2. Architectural Overview of RIAs
The architecture of a Rich Internet Application is quite different from a traditional, serverbased web application. A conventional web application processes everything on the server by receiving the user’s request with the controller, updating the model according to the request and combining the view with the updated model. This conglomerate is then sent to the client’s web browser where it is interpreted and displayed. Each action of the user results in an HTTP request to the server and therefore interrupts the workflow of the user. Considering that the amount of data contained in an HTML page only accounts for approximately 20% of its total size it is easy to see that a lot of extra traffic is generated by HTML tags. [Ste07a] Figure 2.1 shows an MVC (Model-View-Controller) architecture of a server-based web application. The user interacts with the controller on the client (i.e. the application that is displayed in the browser). Each interaction results in an HTTP request that is send to the controller on the server which updates the model (if needed) and delegates the request to the view. The view constructs an HTML response using the (updated model) and sends it back to the client where it replaces the previously displayed page. Thus every action of the user entails a replacement of the whole page. As the user does not interact directly with the web server but via a browser the client has its own model and controller elements that mediate the interaction between user and server. The client’s view is responsible for rendering the received page to the screen whereas the controller reacts to user inputs and sends requests to the server. If the user performs an action that does not result in a page reload (e.g. filling in a form or scrolling the page) the client’s controller directly updates the view. All other interactions require a round trip to the server.
Figure 2.1.: MVC architecture of server-based web applications
Avoiding the permanent round trips to the server and the consequent disruption of the user’s workflow is a main goal of Rich Internet Applications. Therefore, RIAs have a different architecture than conventinal web applications as we can see in Figure 2.2. A big difference to the diagram above is that there is model element on the client side in addition to the server side model. This model facilitates that an interaction of the user does not automatically result in a
Page 12
request to the server. For the most part an action results in a change of the client’s model and therefore the application responds much faster and is much more interactive. This allows for example client side validation of user input or manipulating tables (e.g. sorting, deleting items, etc.) without server interaction. The client side controller only sends a request to the server if neccessary and, of course, in an asynchronous manner for not disturbing the user’s workflow. Another difference is that there is only a single view element, namely on the client side. If the server side controller receives a request from the client it always effects a change of the model as there is no more view element on the server. Changes to the view happen exclusively in the client’s browser. Another consequence of this change is that the server does not respond to the request by sending HTML. The server only returns the updated model as XML, JSON or something else. This data is then used to update the view on the client.
2.3. Advantages and Disadvantages of RIAs
To summarize both the advantages and disadvantages of Rich Internet Applications in general this section provides an overview of their pros and cons. These characteristics affect all RIA technologies but each of them has of course its individual qualities. The following list describes the advantages that arise with the use of Rich Internet Applications.
•Improved user experience.Rich Internet Applications improve the user’s experience significantly since they reduce the waiting times considerably. Some actions do not require a communication with the server and hence can be performed immediately on the client. And those actions that need an interaction with the server do not block the whole application while the data is loaded. Besides, the user interface is only created once and updated with the latest data (compared to traditional web applications which are rendered every time a request is sent to the server).
•Increased interactivity.Since an essential part of the application logic is executed on
Page 13
the client the application can immediately react to the user’s actions. In this regard a RIA resembles more a desktop application than a web application.
•Reduced traffic.Due to the fact that the data that is required by the application is transferred without any markup, the traffic of a RIA is significantly lower compared to conventional web applications. This and the fact that the data is loaded asynchronously leads to much less idle time.
•No installation.A very important criterion for the rapid diffusion of RIAs is that they do not have to be installed on the client. They are simply downloaded and run in the previously (and only once) installed runtime environment (i.e. the Flash Player, the Java Runtime Environment (JRE) or the browser’s scripting engine) they require.
Besides all this advantages there are also some drawbacks. They have to be considered carefully to ensure that the benefits outweigh the disadvantages. The following list describes the most relevant drawbacks regarding Rich Internet Applications.
•Longer loading times.Loading a RIA initially in the browser usually results in more traffic compared to HTML based web applications. This is caused by the application logic and the more complex user interface elements that have to be transferred to the client when the application is loaded. But since these parts of the application are only downloaded once the overall traffic and loading times are much less compared to traditional web applications.
•Special runtime environments required.The application logic that runs on the client requires a special runtime environment where it is executed. This can be a Flash Player, the Java Runtime Environment (JRE) or the scripting engine of a browser.3If the required runtime environment is not available the application cannot be executed.
•More client-side resources needed.Due to the fact that more application logic resides on the client and downloaded data is processed by these parts of the application, more resources are needed compared to displaying simple HTML pages. The development of RIAs should always respect this fact in order to minimize this disadvantage.
•Accessibility problems.Accessiblity of traditional web applications has already come to an adequate level during the last years. In case of Rich Internet Applications making an application widely accessible is a bit more difficult. Especially governmental web sites are often obligated to conform to special guidelines.
Page 14
•Content invisible to search engines.The content that is provided by RIAs is usually not accessible by unique URLs and simple HTML, which is the basis for search engine indexing, and therefore their content cannot be crawled and indexed as easily as that of conventional web applications. As search engine optimization is an important issue for every web application appropriate measures to mitigate the effects of this drawback have to be taken. Since RIAs are becoming more and more popular it is also the responsibility of the search engine providers to adjust their search strategies in order to take this trend into account.
•History confusion.Another thing that often leads to confusion of the user is the browser’s history mechanism. A Rich Internet Application is usually located on a single web page and does not create history events on standard actions. A click on the back button leads the user to the page that was displayed before the application has been loaded, discards the state of the application and confuses the user. Most RIA technologies provide convenient solutions for this issue but many developers do not implement them.
The ultimate challenge when developing Rich Internet Applications is to exploit the advantages and to minimize the disadvantages. For most of them solutions and workarounds are available but they are certainly associated with some effort. Therefore, the secret of success is to find out which measures are worth its costs.
