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.

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.

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.

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.

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.

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.

Regards

As to the argument of technology for technology's sake (ala Flash), we're geeks...that's what we do.

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.

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.

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.

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.

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.

Additionally I'm not so sure how the size of the javascript increases in memory. This still needs some testing.

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.

Also, keep in mind it is a bit unfair to compare tw-sack.js, which does one thing and compare it to a group of files that provide quite a lot more functionality.