“Forcing users to download 81kB of script just so you can $(‘a#next).click() is a complete waist.”

has 2 errors in it:
$(‘a#next).click() should be $(‘a#next’).click()
“waist” should be “waste”

Other than that, great article. I agree completely with what you said here (too often sites will use too much JavaScript (Twitter and Facebook are near the top of the list), and it can really harm the user experience).

Also you have operations obviousely suitable for the clients and others for the servers. It’s not difficult to know which ones.

But the best practice is still to keep things simple. To ask yourself “is this realy necessary?”.

For example, I’ve had to do this with portable ad calls before. We needed to show a random subset of the data to users (5 random ads) on every view, but the ad calls are hit so much that doing a random select for every hit was simply out of the question. To make this scale we did a random select of 50 ads and cached the results server-side for 10 minutes. Then on the client side I select 5 random ads from that data. The users see different random ads but I only need to query data once every 10 minutes, instead of querying data for every single hit.

This was a compromise I had to make to get this feature to scale and support the traffic.

However, in my experience cases like this are fairly rare. This had to be a JavaScript call to begin with, so there wasn’t any lost usability. A vast majority of the time the best practice is to do the work on the server and implement server side caching. Even highly dynamic web apps can use caching. In a very high traffic environment, even a thirty second cache might save you hundreds hits to the database. And will appear no less dynamic to the users.

But as you said, it’s a judgment call. I guess I should point out that my golden rules can be bent or broken in places. But it’s best practice to avoid it unless necessary.

What I was ranting about in this article was web developers who use JavaScript and AJAX, not as a tool to enhance the app or make it scale… but simply because they can. I don’t like seeing complete JavaScript dependence on front-facing web sites just because someone thinks it’s cool.

This is a nice idea until you have over a million visitors a month like we do. Then your server is screaming in pain and your hosting costs shoot through the roof.

We found this out the hard way. Q.E.D.

Balancing the load of server side cpu and client cpu is a judgement call. Not a rule.

I can’t understand that because these scripts have, 99% of the time, no reason to be whatsoever. If you disable scripts totaly, everything is still there identical or almost.

So why do they do that? Web designer hubris? Obsession on automation? Non monitored self-generating code?
Anyway, how much time and money have been waisted to code this crap is beyond me.

Even if these codes are autogenerated by several separate entities, and multiplied without purpose just because nobody thought of deactivating them, still someone had to code them one day. Who did all these huge useless and terribly inneficient scripts, must be either maniac, schyzophere or something. So are all the webdesigners js maniacs like that? Why all the big companies and news sites hire them?
What do these companies managers wanted exactely with their websites? Sure, not “please write me a 5000-lines js code for the sake of coding”! I can’t even figure out the goal of these projects. Advertisement, of course, but why like this?

Regards.