|By Coach Wei||
|April 4, 2007 07:15 PM EDT||
Ajax is flying high and Ajax toolkits are certainly of big help. However, I do hear from people in the community complain about the size of various Ajax toolkits. A lot of Ajax toolkits requires hundreds of kilobytes of download, sometime even over megabytes. Dylan Schiemann from Dojo Foundation/SitePen wrote a fairly good blog entry in response to clarify questions related to download size and performance etc.
Dojo is one of the most well known and respected Ajax toolkits. On the other side, I have also heard complains that “Dojo is too big…Dojo is bloat-ware”. So I decided to study Dojo footprint. Further, I was hoping to gain some insight about the general Ajax toolkit footprint concern from the study of Dojo, and hope to offer some recommendations to footprint relatd performance issues for Ajax development in general.
Context and Background
I personally have also been playing with Dojo for quite a while. There is no doubt that Dojo has its own (but necessary) overhead. The overhead ranges from about 26KB (the minimum profile of Dojo) to a few hundred kilobytes, depending on the Dojo build profile.
For example, here are some sample demos that you can take a look to show the value of a declarative framework and the inclusion of Dojo:
- EasyTrader: an Ajax-based trading application(built using Nexaweb Ajax Client)
- SendMeAPic: search and browse pictures from web services, process them and send the result to mobile phones(Built using Apache XAP)
Over the last few months, I started to think about other usage scenarios for Dojo. In this context, the application is a page-based web application that is largely HTML. The developer is interested in adding some Ajax to enhance the application, but not interesting in rewriting the application. In this context, is it still worthwhile to use Dojo?
Build and Package My Dojo Widget
The Dojo custom widget I am building is very simple – it is largely based on the “Memo widget” example provided by Dojo Manual. In my effort to evaluate Dojo performance, I am going to create my own build profile so that only the absolutely required files for my application are packaged into the initial download.
The details look like a good end to end tutorial on how to build custom Dojo widgets with some important real world considerations. So I wrote it up as a "Dojo Custom Widget Tutorial" and posted it here.
A sample application that uses this simple "memo" widget can be accessed here: http://www.ajaxword.com/dojowidget/release/memo.html.
The code (including Dojo) can be downloaded from http://www.ajaxword.com/dojowidget/release/dojowidget.zip. (37MB)
The Dojo Performance Overhead Challenge
After building and packaging the my simple Dojo widget, the custom build produces a new dojo.js that has packed all necessary files, but only the necessary file, into one single download. The footprint of this custom dojo.js is 168KB.
In contrast, if I wrote this simple widget from scratch without using Dojo, its footprint would be under 10KB(with compression, it would be under 2KB).
Given the dramatic difference in footprint, my conclusion is that Dojo is not suitable for this use scenario.
There are three use scenarios of Ajax technologies:
- HTML enhancement: Using Ajax to enhance HTML pages. In this case, the majority of the application code is HTML and CSS, and Ajax is only a small portion of application code that provides enhanced interactivity;
- Web Widget: Using Ajax to develop an embeddable web widget. Widgets are small code snippets that can be easily embedded by third party websites to provide focused functionality. The popularity of widget is so high that Newsweek even declared that “2007 is the Year of Widget”. Ajax is certainly the technology of choice for developing widgets.
- Desktop-like web application: Using Ajax to develop a desktop-like application. The application contains many screens. Majority of the application code is based on Ajax and HTML/CSS are only to compliment these Ajax code.
Dojo 0.4 is certainly a good fit for the third use scenario. The application complexity and the amount of Ajax code required for delivering such applications can easily justify the Dojo overhead.
However, in both the first and second use scenarios, Dojo 0.4 is not a good fit. The “memo” widget I created above is probably one of the simplest widgets one can think of. Writing such a widget from scratch would require less than 10KB footprint. The footprint becomes 168KB using Dojo. This overhead is so significant that makes Dojo practically not usable for such usage scenarios. If the complexity of the widget is higher, the footprint difference between using Dojo vs. not using Dojo would be smaller, though I would still expect a significant difference.
The Challenge for Ajax Toolkits: Footprint vs. Feature/Maintenability
From the above study of Dojo toolkit, I come to the realization of the challenges facing Ajax toolkits trying to meet the conflicting needs of different use cases.
In the context of building desktop-like, fully Ajax-driven web applications, the complexity of the application requres a rich featured Ajax toolkit that is well structured and enables good code maintenability going forward. Dojo is a good fit, but such rich feature set, architectural structure and good coding style can come at a footprint cost. However, the complexity of such applications well justifies the initial download footprint.
In the context of HTML enhancement and web widget, small footprint seems to be of the ulmost importance and coding style/structure etc are much less important, given that the complexity of the application is much lower. In such use cases, Dojo's overhead may not be worthwhile.
There are other Ajax toolkits that are highly tuned for HTML enhancemend and web widgets, such as jQuery. jQuery is designed to be lightweight. It works very well for HTML page enhancement. However, the coding style and structure of using jQuery for large scale application can cause serious maintenability issue. For example, looking at the following jQuery code (from jQuery website on "Chainability (The Magic of jQuery) ": http://docs.jquery.com/How_jQuery_Works):
This kind of code is just not going to work well for large scale applications, though it can work well for HTML enhancement and web widgets. Imagine having thousands of lines of code like this in an application - how can someone maintain such code?
So is there a way that we can deliver rich featured toolkit like Dojo and still being lightweight and without a lot of overhead?
As a user and a supporter of Dojo, I obviously hope the Dojo commuity will address this challenge.
My recommendation is to enhance Dojo's existing packaging/compression system by adding the capability to “strip out” the functions that are never called.
When creating a Dojo build for a specific application, Dojo build/packaging system can ask developers to specify additional information in the “dojo build profile” file. This additional information includes a list of Dojo entry functions that are called by the browser or application code directly. Then Dojo build/packaging system should navigate the execution path starting from these entry functions, figuring which functions are called along the execution path, and package only these functions into the initial download.
Such a technique has been successfully used in the Java community for reducing the footprint of Java applications. By specifying the application entry points, such compression program would recursively navigate through all function calls, and remove these methods that are never called. For example, within the Nexaweb Universal Client Framework, its Java Client uses such a technique that works wonders. Depending on the application behavior, the result can be 30% to over 90% footprint reduction.
I think this technique will dramatically reduce Dojo deployment footprint, and make Dojo applicable to additional use scenarios including both HTML enhancement and web widgets. With such technique, the dojo.js would be probably really small (under 10KB) for our “memo” widget.
This is just going to be an absolute nightmare for large scale applications and makes the already notorious code maintenance problem associated with Ajax even worse. Dojo has the right foundation that encourages well structured code with maintenability in mind. The cost associated with "code maintenability and structure" can be well solved with this technique.
|James Burke 04/05/07 04:27:12 PM EDT|
Some comments from a Dojo contributor: for the 0.9 release (the next major release), the code structure is being changed so that if someone just wants some basic HTML/JS helper functions, they will have one small file they can use. If they want more than that, then we'll still have the build system to make custom distributions, and a web build tool.
On the unused code stripping front, Dojo does have an alpha-quality tool to do this, the JS Linker. The tool needs more work and a friendlier interface, but there is some info here:
It was not clear from your article if the "compressed" sizes you mentioned were gzip-compressed sizes or just the size after running through the JS compressor, which renames things to smaller names. Gzipping is a recommended.
With Dojo 0.4.2, there is an easy, lightweight way to use Dojo: use it from the AOL CDN. This means you just have to include a script tag pointing to the dojo.js on the CDN to get access to all of the Dojo modules. Nothing to download to your site. Nice for trying quick, small things in your page.
Since that version of Dojo is hosted on the CDN, it is on a different domain than your page, so you get more network connections in the browser to download Dojo. The CDN content is also gzipped and has appropriate cache headers. The end result is faster delivery of Dojo code.
More info on using Dojo on the AOL CDN (as well as making a custom dojo.js using a web build tool) can be found here:
|AJAX News Desk 04/04/07 04:21:11 PM EDT|
AJAX is flying high and AJAX toolkits are certainly of big help. However, I do hear from people in the community complain about the size of various Ajax toolkits. A lot of AJAX toolkits requires hundreds of kilobytes of download, sometime even over megabytes. Dylan Schiemann from Dojo Foundation/SitePen wrote a fairly good blog entry in response to clarify questions related to download size and performance etc.
- Where Are RIA Technologies Headed in 2008?
- i-Technology Predictions for 2007: Where's It All Headed?
- Cloud People: A Who's Who of Cloud Computing
- "Mobile Web 2.0" – How Web 2.0 Impacts Mobility & Digital Convergence
- "Real-World Flex" by Adobe's Christophe Coenraets
- The OpenAjax Technology Vision: Accelerating Customer Success with AJAX
- A Compelling Ajax Discussion in New York City
- SOA World Expo: Enterprise Mashup Services
- Coach Wei's "Direct From Web 2.0" Blog: The Converging Developer Community
- Implementing SOA Without Enterprise Mashups? You Might As Well Kiss Your Job Goodbye!