Title: Bloated Ajax Applications Due to Libraries
Author: Alex Kirk
Published: October 3, 2005
Last modified: October 6, 2005

---

# Bloated Ajax Applications Due to Libraries

October 3, 2005

When Ajax began to rise, there was quite a movement towards the [prototype javascript library](http://prototype.conio.net/).
This was also pushed by the great [Ruby on Rails](http://www.rubyonrails.org/). 
Then came the visual effects of [script.aculo.us](http://script.aculo.us/). They
look great, they really do. But for what price? Lots of KB of code.

`alex@www:~/scriptaculous/$ du *.js -ch --apparent-size
 23K controls.js 18K dragdrop.
js 21K effects.js 28K prototype.js 899 scriptaculous.js 12K unittest.js 8.7K util.
js 109K total

This is unacceptable for just a library. Most of these KB’s have to be downloaded
and do not provide any functionality per-se. Broadband is not an argument here. 
To load or not to load 100kb is relevant.

I therefor really like the [Sack of Ajax](http://twilightuniverse.com/2005/05/sack-of-ajax/).
It takes only about 4K:

`alex@www:~/sack/$ du *.js -ch --apparent-size
 3.9K tw-sack.js 3.9K total

Now this does not give us all the script.aculo.us stuff. For that case I suggest
to just reuse the relevant parts of it. Just let the user download what you really
use. Maybe one day we will see a reduced script.aculo.us. Or an alternative using
Sack.

**UPDATE:** I now recommend to use protoype.js again, in a [reduced version just for AJAX](https://alex.kirk.at/2005/10/05/prototypejs-just-for-ajax/).

ajax, sack of ajax, prototype, bloated

[Ajax](https://alex.kirk.at/category/code/ajax/)

Read this next

[News about E-Ink](https://alex.kirk.at/2005/09/28/news-about-e-ink/)

## 5 responses to “Bloated Ajax Applications Due to Libraries”

 1.  ![Alexander Kirk Avatar](https://alex.kirk.at/wp-content/uploads/sites/2/2025/
     06/cropped-2025.Alex-512x512-1-48x48.jpg)
 2.  [Alexander Kirk](http://www.bandnews.org/)
 3.  [October 6, 2005](https://alex.kirk.at/2005/10/03/bloated-ajax-applications-due-to-libraries/comment-page-1/#comment-8)
 4.  I agree that broadband and HTTP compression allows larger amounts of data be transfered
     to the user in less time. But it does not become irrelevant. I just wanted to 
     show how fast a hundred kilo bytes can come together without any functionality
     added.
 5.  Additionally I’m not so sure how the size of the javascript increases in memory.
     This still needs some testing.
 6.  I’m just trying to alert developers that they should overthink the way they structure
     their application. Don’t load too much at once but try to do this over time. Try
     to present the user the initial view as quickly as possible.
 7.  [Log in to Reply](https://alex.kirk.at/wp-login.php?redirect_to=https%3A%2F%2Falex.kirk.at%2F2005%2F10%2F03%2Fbloated-ajax-applications-due-to-libraries%2F)
 8.  ![keittl Avatar](https://secure.gravatar.com/avatar/a2916b245ec5c3d558676c3504f7966d02aed8ed432a4aba4f1613c4ac1f1511?
     s=48&d=mm&r=g)
 9.  [keittl](http://www.keittl.com/Blogs/Keith/)
 10. [October 6, 2005](https://alex.kirk.at/2005/10/03/bloated-ajax-applications-due-to-libraries/comment-page-1/#comment-9)
 11. I think library size *is* an issue to some degree. Of course it varies with the
     situation.
 12. True that bandwidth is increasing and so. But what is also increasing is the amount
     of stuff we pump thru these bandwidth pipes. I think *percieved* speed stays roughly
     constant.
 13. A good analogy would be the hard disk. There was a time when 20MB was big. We 
     were able to fill them at the time. Now a few hundred GB is big (order of 10^3).
     We are finding ways to fill these hundreds of GBs. Percieved storage space stays
     roughly constant.
 14. One of the ideas that ajax tries to bring us is to not waste so much user’s time
     with page requests. This is why I think it is important not to have bloated ajax
     apps.
 15. Once the js library is loaded, it doesn’t need to be loaded until a new page refresh
     is done. But bloating is not only about download time. It’s also about memory 
     consumtion and responsiveness.
 16. I hope we don’t see too much ajax being used simply for eye-candy (animations 
     and so) just for the sake of it. That happened with flash.
 17. [Log in to Reply](https://alex.kirk.at/wp-login.php?redirect_to=https%3A%2F%2Falex.kirk.at%2F2005%2F10%2F03%2Fbloated-ajax-applications-due-to-libraries%2F)
 18. ![Alex Russell Avatar](https://secure.gravatar.com/avatar/af68319be2eaf49db906027c68b40eeb82db185c4de25a79bd35bc024f08e75b?
     s=48&d=mm&r=g)
 19. [Alex Russell](http://alex.dojotoolkit.org)
 20. [October 6, 2005](https://alex.kirk.at/2005/10/03/bloated-ajax-applications-due-to-libraries/comment-page-1/#comment-14)
 21. So I’m incredibly biased in this discussion (I work on Dojo), but good tools help
     a lot.
 22. Firstly, a “compressor” (like the one we build Dojo with) reduces the size of 
     the code significantly. Running the variant of Prototype included in the scriptaculous
     1.5 beta through the Dojo compressor took 33% off the file size without changing
     the file’s semantics at all.
 23. Next, a good build system will put all your scripts into a single file. Say what
     you will about file size, but the limiting factor in perceived performance today
     is network latency combined with the synchronous nature of browser rendering engines,
     not network throughput. The less you have to reach-out-and-touch the network (
     even for a 304), the better off you are. On top of that, something like Dojo or
     JSAN allow you to grab just what you need, reducing the overall size of a library
     based on your usage of it. A capable package system even lets you do this without
     changing the way you develop and without cutting you off from the rest of the 
     available APIs, should you need them.
 24. Lastly, there’s much to be said for gzip encoding on the wire and a good HTTP 
     server configurationn. The best kind of data is the kind you don’t have to (re)
     send, and the next best thing is the gzipped kind.
 25. So yes, large libraries are a problem, but developers need some of the capabilities
     they provide. The best libraries, though, should make you only pay for what you
     use. Hopefully Dojo and JSAN will make this the defacto way of doing things.
 26. Regards
 27. [Log in to Reply](https://alex.kirk.at/wp-login.php?redirect_to=https%3A%2F%2Falex.kirk.at%2F2005%2F10%2F03%2Fbloated-ajax-applications-due-to-libraries%2F)
 28. ![Erik Arvidsson Avatar](https://secure.gravatar.com/avatar/c9e45c66e3481626cec0d7e65e7ff0adeb8ec36abec2c51340b15e137c6693e4?
     s=48&d=mm&r=g)
 29. [Erik Arvidsson](http://erik.eae.net/)
 30. [October 10, 2005](https://alex.kirk.at/2005/10/03/bloated-ajax-applications-due-to-libraries/comment-page-1/#comment-19)
 31. I second everything Alex just said. I just wanted to add that the download time(
     and parsing) is often insignificant to the time spent manipulating the DOM. As
     a reminder I point you to Peter-Paul’s “Benchmark – W3C DOM vs. innerHTML” article
     at [http://www.quirksmode.org/dom/innerhtml.html](http://www.quirksmode.org/dom/innerhtml.html)(
     and this just tests very basic DOM manipulations)
 32. [Log in to Reply](https://alex.kirk.at/wp-login.php?redirect_to=https%3A%2F%2Falex.kirk.at%2F2005%2F10%2F03%2Fbloated-ajax-applications-due-to-libraries%2F)
 33. ![Gregory Avatar](https://secure.gravatar.com/avatar/1f2f9b78a16e7d2f47a8bdcce858a77881844328c9c52a54e89d31745f39d521?
     s=48&d=mm&r=g)
 34. [Gregory](http://twilightuniverse.com)
 35. [October 31, 2005](https://alex.kirk.at/2005/10/03/bloated-ajax-applications-due-to-libraries/comment-page-1/#comment-51)
 36. Hey, glad you like SACK, and yes: one advantage of it is that it is small, but
     as discussed here that is sometimes not an issue. It certainly isn’t an issue 
     in really complex applications, because the overall code impact is probably small.
     However, as mentioned above, really large libraries can slow a browser down.
 37. The main reason I wrote SACK however was because I wanted something that allowed
     me (and others) to use AJAX quickly, simpley, and without a lot of code that wasn’t
     needed for simple communication. Basically.. simplicity.
 38. As said – it’s not quite the same as something like prototype (or Dojo!), but 
     for many people that want to create AJAX apps it is nice, neat, and simple enough
     to satisfy their needs.
 39. [Log in to Reply](https://alex.kirk.at/wp-login.php?redirect_to=https%3A%2F%2Falex.kirk.at%2F2005%2F10%2F03%2Fbloated-ajax-applications-due-to-libraries%2F)

### Leave a Reply 󠀁[Cancel reply](https://alex.kirk.at/2005/10/03/bloated-ajax-applications-due-to-libraries/?output_format=md#respond)󠁿

Only people in [my network](https://alex.kirk.at/friends/) can comment.

This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/)