Thursday, October 6th, 2005

Rise of slow Ajax applications

Category: Editorial

Alexander Kirk has been writing about Ajax performance via entries such as Bloated Ajax Applications Due to Libraries, Rise of slow AJAX applications, and Code downloading with AJAX.

Alex tends to like lean libraries such as SACK.

Although, we have to keep down the code in an environment such as browser-based, there is a reason that richer libraries have been created.

Often there is a lot of quality magic going on when you use a Dojo or a full Prototype.

We see this when client go running around with the raw XHR object, and quickly run into issues revolving around browser compatibility, caching, bugs, and degrading to other transports. There is enough of this going on what I would rarely see a point in sitting down and start typing out new XMLHttpRequest.

Central JavaScript

The library issue does make me wish for the central JavaScript repository that allows me to share ONE JavaScript file among multiple applications.

It would be great if you could could register for “Dojo version 0.1”, and any app that wants that version gets it. No need for everyone having their own version of the same thing. To make this really happen the browser would need to get into the mix, and cross site issues resolved.

Once you take a look at apps like Yahoo! Mail beta, it is hard to say that you can not create performant applications on the Ajax platform.

Posted by Dion Almaer at 3:06 am
8 Comments

+++--
3 rating from 5 votes

8 Comments »

Comments feed

It is not my intention to largely promote low-level AJAX libraries. In my opinion it should just be a priority to keep size in mind to keep these apps fast. As soon as the code and the libraries have been downloaded to the client, these apps move fast indeed.

But using techniques such as code downloading (or Javascript On-Demand) allow only litte initial loading to instantly display the app. With AJAX apps we should never come to the point when we have to display progress bars for loading such as with Flash apps.

Comment by Alexander Kirk — October 6, 2005

A central JavaScript repository could be done, just like Gravatar.com does for avatars. It could speed up loading time with a few seconds, but I don’t know how practical it would be.

Comment by Tinus — October 6, 2005

By carefully considering what is commonly used, and what is not, it’s possible to deliver a compact set of scripts initially to the client, and more as required (Alexander called it “Javascript On Demand”).

For example, I did a shopping cart recently, https://inkjet.ie/, which uses AJAX extensively. The only script implicitly mentioned in the source is a general list of common functions. This script then figures out what else it needs, and downloads them.

But – back to the point; another worry I have had, relating to speedy javascript apps in general, is memory usage. The main point of AJAX is that the page is rarely fully refreshed. This means that any JavaScript variables that are created may be around for a long time, and grow over time. It would be handy to have some methods for hunting down memory-hogs in JavaScript applications.

Comment by Kae Verens — October 6, 2005

Take a look at JSAN, http://www.openjsan.org/, to see a fledgling central javascript repository. They even have a library (JSAN, http://www.openjsan.org/doc/c/cw/cwest/JSAN/0.10/lib/JSAN.html) that will download other libraries from the repository.

Comment by Kyle Adams — October 6, 2005

JS on deman is a cool idea but there’s a big caveat. Firefox (and IE with certain cache settings) does not respect caching headers in XHR requests, so it will re-fetch the requested file every time. I did a lot of hacking on JSAN to try to make this caching happen and could not get it to work.

This could add up to a huge waste of (potentially expensive) bandwidth quite quickly. I wrote a Perl module to do the same dependency resolution as JSAN but on the server side for just this reason (http://search.cpan.org/dist/JSAN-ServerSide/)

Comment by Dave Rolsky — October 6, 2005

Why not use a Pushlets-like (http://www.pushlets.com/) solution for JS on demand? Here is the server who “push” Javascript to the client when needed.

Comment by jose — October 7, 2005

JS is not only slow, but buggy as well. Very soon JavaScript will need serious REFACTORING. You can read more about this topic in my article “JAVASCRIPT REFACTORING FOR SAFER FASTER BETTER AJAX.” Follow this link (http://www.softwaresecretweapons.com/jspwiki/Wiki.jsp?page=JavascriptRefactoringForSaferFasterBetterAJAX)

Article argues that its time for Javascript coding practices to mature into professional software engineering, discusses various ways to improve Javascript code and has examples of Javascript refactoring from real-life projects.

Comment by Pavel Simakov — October 10, 2005

what is the difference between ajax and pushlet

Comment by master — November 16, 2005

Leave a comment

You must be logged in to post a comment.