Tuesday, April 10th, 2007

Dojo Footprint and Ajax Performance Recommendation

Category: Articles, Editorial, JavaScript, Library

Coach Wei of Nexaweb has been spending time on the Dojo Footprint and Ajax Performance Recommendations.

Coach compares the Ajax usage scenarios, from building a rich application, to doing a little HTML enhancement.

He ran a Dojo Performance Overhead Challenge which involved creating a simple widget with Dojo, and one from scratch:

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:

  1. 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;
  2. 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.
  3. 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.

This discussion isn’t just about Dojo, it is about any of the frameworks, and it needs to be discussed as the community to make sure we come up with solutions that allow Ajax to continue to grow as a development platform.

Would the initial download matter so much if the browser cached Dojo libraries?

Dylan Schiemann responded discussing how the Dojo team is pushing hard to solve some of these problems.

Posted by Dion Almaer at 9:47 am
22 Comments

+++--
3.8 rating from 26 votes

22 Comments »

Comments feed TrackBack URI

While Dojo contributes more to the footprint than any other js framework, all frameworks contribute to the footprint. The question a dev has to ask is, “Is the footprint worth the convenience”. While dojo is large they are working on a “Dojo Core” that should be more the size of Prototype and jQuery. However, here is a question I pose. Why wait until June, or later, for Dojo Core when there are so many other great frameworks to use that aren’t heavy and are easier to use?

Comment by j — April 10, 2007

I’ve always seen Dojo are more of a overall infrastructure library, meant more for more complex applications that want to take advantage of its extensibility.

There are simpler libraries, including the ones mentioned, such as Prototype and jQuery, as well as Dean Edwards tasty little base2.

I wonder if the library developers wouldn’t be better directed to define their audience and then optimize the code for it, rather than trying to be all libraries to all people. Coach Wei even said, “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.” He then went on to describe what Dojo can do to meet the different use cases. I think a better approach would be for each library developer to pick specific user cases, fine tune and optimize for such, and let the other libraries have their share.

Comment by Shelley — April 10, 2007

This fits my usage scenario… I used mootools, because it gave a full featured library, compressed at about 35k with slick effects and and lots of time-saving functions. You can strip out effects and some of the other extras and cut that down to half pretty easily.

The benefits of using a sane, compact library like mootools or others like it is that it drastically simplifies the custom code you do need to write. This improves maintainability. I dread the thought of going in and doing maintenance on a website I wrote 8 months ago. I won’t go back to custom code. Not now that I can do xhr in 1 or 2 lines or fade effects in one line.

Comment by Matt Nuzum — April 10, 2007

“Would the initial download matter so much if the browser cached Dojo libraries?”

(a) Of course it would. On the web you often only get one chance to win the user’s attention and adding 168k of code on top of everything else on a page is a potential stumbling block. In my mind, planning for a user’s second page view is a mistake.

(b) http://ajaxian.com/archives/browser-cache-usage-only-40-60

Comment by rob larsen — April 10, 2007

Ditto what Matt said. Also a mootools user. The key for me has always been the ability to strip out stuff you don’t need in mootools. You can have multiple versions of mootools on your server and call the one you need depending on the situation.

Comment by Marat Denenberg — April 10, 2007

100% moo here too.

Comment by Karl — April 10, 2007

We recently used Dojo in a larger application with lots of screens and functionality. It was a total failure because of very poor performance. I have doubts on using Dojo for larger apps, using it for small HTML enhancements would be overkill. On the other hand I used mootools for small HTML enhancements, and it rocks.

Comment by Ray — April 10, 2007

I have my eye on MooTools. I use Prototype and am loven it (v1.5.1_rc2 is mind blowing).
Have no need to switch to moo yet. 8P

Comment by Jay — April 10, 2007

Check our http://www.visualwebgui.com they manage to do lots of work with very little footprint.

Comment by Ramanjit — April 10, 2007

I wonder if there are facilities that support Dojo that would be interested in doing for Dojo what Yahoo! did for it’s YUI. Host the libraries and let people point to them for their sites. With proper caching and such set up, the footprint becomes less of a problem. It’s one reason I’m planning on sticking with YUI. I figure, there’s a good chance a user for my site in development will have already been to yahoo, and cached that set of libraries anyway.

Comment by Joe — April 10, 2007

Joe, AOL hosts dojo so you can do just that.
http://dojotoolkit.org/node/288

Comment by Jay — April 10, 2007

@rob: I think the reference to caching was less traditional browser caching and more of the idea of letting browser manufacturers actually distribute versions of libraries with the browser itself. I know there’s been some back and forth with Moz about it (not just with Dojo, from what I understand). Would you still care as much about footprint if that was the case?

@everyone else: for those of you who don’t know me and my interactions with Dojo as a major contributor, many (but not all) of the complaints being made have been made in some way, shape or form by me and a number of others. The entire split for Dojo 0.9 is one end result; you’ll be able to use Dojo (NOT the widget system–which is really a separate entity) the same way you’d use jQuery or Prototype. I don’t remember the initial numbers but I *think* Alex said he got the download for Dojo base to about 26k, maybe less. That includes the event system, communication, HTML/CSS manipulation/querying and some fx, IIRC.

Unfortunately we made some mistakes with Dojo in that everyone equates the Dojo Widget system to BE Dojo. It isn’t and never really was, but most of us are terrible at marketing and the damage has been done. I’ve used core Dojo as additive sugar on web pages and never had to deal with a 168K download, because I recognize what I need and only use those things–and in general, when you’re doing sugar, you don’t need a declarative-based widget system. By contrast I’ve also used Prototype and scrip.taculo.us, and found the experiences to be similar. Not exact, but similar. If I’m in a situation where the task at hand is simple, I won’t use a library at all; as Coach Wei said, there’s no reason for it. If I’m in a situation where it’s easier to use Prototype, I will.

I will also say that I consider the payload argument to border on the ridiculous at times, as well as the unobtrusiveness. Both are desirable but they are not lines in the sand; if there’s a 10 – 20K difference between libraries and it so happens that the bigger one is more maintainable (as Coach Wei implies), there should be no real argument. Cryptic naming with duplication across libraries is a bad thing–especially when that naming means different things based on which library you’ve used.

Finally, I’d reiterate that the point of using a library is so that you don’t have to roll your own. Each use case has it’s own unique requirements and to say something to the effect of “jQuery is the ONLY solution for all” is ridiculous (not hitting on jQuery, just using it as an example).

Comment by Tom Trenka — April 10, 2007

I reproduced the challenge in GWT (Google Widget Toolkit). The endresult is 49kb according to firebug’s net tab; 568b for the HTML, 18kb for the generic gwt loader, 3kb for the app-specific loader, and the program proper clocks in at 29kb. GWT 1.4 should be released this week and I hear it’s seen work to reduce this even further (specifically, generic loader + app specific loader will be combined).

It’s a simple yellow sticky note with a title, a message, the appropriate styling, and a ‘closer’ button that simply removes it from its parent. I assume that was the challenge.

Comment by Reinier Zwitserloot — April 10, 2007

“On the web you often only get one chance to win the user’s attention and adding 168k of code on top of everything else on a page is a potential stumbling block.” – rob larsen

Who is your target audience?! If you are concerned about 168k of code, you need to stop worrying about the hillbillies in the Georgia hills on dial-up accounts and get comfortable with corporate America’s highspeed bandwidth. Even I have 15Mbps VerizonFIOS at home. 168k? I laugh at that pitiful footprint!!! :D

Comment by Giggle Platypus — April 10, 2007

I use jQuery and Moo Tools, and if it’s really simple I’ll use plain old Prototype. Both jQuery and Moo are both pretty small and doesn’t try to write the code for you. Dojo seems really bloated *(and so is GTW).

Comment by Matt — April 10, 2007

@Giggle Platypus
Hillbillies? Please, Look at Gmail, Everyone uses it, You need to realize that you’re target audience doesn’t always have a 15Mbps connection. If you write a really slow program, especially with a huge toolkit, no one but yourself will be able to use it.

Comment by Matt — April 10, 2007

In my opinion, developers need to start focusing their attention on making tools that programmers can use to write their own code, instead of writing a platform that a site must be developed on. If I just want to make a nice little animation on 5 jpgs on my site, am I going to load the Dojo library to run the animation?! Of course not! But unfortunately many people do. So the web is fast becoming cluttered with library code that is NEVER used and ALWAYS loaded.

And keep in mind that these huge libraries aren’t just a bandwidth concern (for the user and the publisher) but they’re loaded in memory on the users system. So if I’ve got 10 tabs open and all the sites are loading libraries….my browser will start to bog down.

That’s why I’ve begun to consider writing a toolkit that’s not designed to be the be-all-end-all library, but rather a way to speed up development and allow for easy implementation of features.

– Andrew

Comment by Andrew Worcester — April 10, 2007

Oh and yes, I know my site sucks ;-)

Comment by Andrew Worcester — April 10, 2007

Yup, I started almost a year ago with dojo for desktop-alike application because it provided all the widgets I needed. Still today we have lots of perfomance issues after sooo many optimizations and version upgrades. During migration from one dojo version to next, lots of hair have been fallen out.

With prototype and ext-yui it is possible to do everything MY way, not the good ‘ol DOJO way. So i’m already migrating to these and i’m happy to do it :)

But I hope that dojo doesn’t give up. They have put lot of effort in it.

Comment by Priit — April 11, 2007

@ Matt
The Gmail client currently clocks in at ~ 540k of compressed/minimized javascript; and google uses a sophisticated compressor. Gzip brings that to about 180k over the wire. Not exactly a small web app.

Comment by SV — April 11, 2007

Unlike pretty much everybody here I’ve been very impressed with dojotookit. My core dojo.js is about 23k once compressed, of course I use the buildscripts to customize my builds. I use mod_headers to force caching of javascript, and then load libraries on the pages they are needed, combining monolithic and distributed download to get the greatest efficiency.

Dojo does have 2 very serious problems. 1) It’s not very well documented so it’s difficult to approach, especially if you aren’t a programmer. 2) The Widget framework assumes you’re making a full blown GUI so using even a simple widget leaves your page hanging for about 3 seconds while the DOM Parser crawls your tree looking for dojoType=”” tags ( granted that’s 3 seconds whether you use 1 widget or 10 ). Solution, I don’t use dojo widgets. ( 2 of course may simply be a symptom of 1 )

Comment by Vance Dubberly — April 11, 2007

(Full disclosure: I am a co-worker and friend of Coach Wei, and I communicate with Dojo guys via the OpenAjax Alliance)

First, Vance in Dojo you can turn off the automatic page scanning using the djConfig object.

Second, this is really just different strokes for different folks. The Dojo toolkit including all the widget code is comparable to something like AWT, SWT or MFC. All the library stuff makes it easy to write fairly complex widgets with small amounts of code. It isn’t really suitable for including a single widget in a page or for writing a single widget of your own, but if you plan on making a complex application that uses tables, tab panes, splitters, etc, and if you plan on creating your own widgets to interact with those out-of-the-box one then it might fit your needs well.

At this point there is no one toolkit to rule them all, and there isn’t ever going to be. What prototype offers is very different from what a full-fledged library offers.

Dojo is nice in that it has a well-baked strategy for creating your own builds that include only what you need. Perhaps some file re-org would be in order but the basic strategy is pretty sound.

Comment by James Margaris — April 12, 2007

Leave a comment

You must be logged in to post a comment.