Experimenting with jQuery

I've done a little experimentation with jQuery while building out geoffreywiseman.ca.  I've been meaning to get a little deeper into AJAX and jQuery was one of the libraries that appealed to me.  It went pretty well for the most part, although I'm not yet sure if it took me less time to learn jQuery than it would have taken me to do the work by hand with JavaScript.  Seems pretty powerful as a library, though.

I did some experimentation with jQuery animations, but quickly discovered that it wasn't going to do the job for me -- you can roll over the icons faster than the animations typically run, and it's very difficult to get a set of animations happening in sequence, cancelling each other without tripping over your own feet, so I dropped the animations.

Even then, I was pleased to realize that I could accomplish this all in presumably cross-browser code without having to test in all these browsers.  Out of curiosity, I fired up IE7 this morning, only to discover that although the site works well in Chrome and Firefox, it's got problems in IE7. 

Ah, browsers.   Can't code web-apps without 'em, can't kill the vendors who wrote such incompatible clients without getting arrested.  This is one of the things that had me focus on server-side code for most of my career.  I'm hoping there's an easy fix.

AJAX via XMLAsynchronousMessage

It seems to me that much of the interactions that take place over a relatively synchronousAJAX XMLHttpRequest could just as easily have been modelled as asynchronous messages.

Now, I'll grant that async messages have been hampered by not using a common wire protocol (e.g. AMQP), and that browsers are fundamentally HTTP clients, but I wonder if an event-driven asynchronous model would have made more sense in the long run?

PURE + AJAX + REST + JSON Web Framework

I am imagining a web framework that delivered static HTML which made data requests to the server using AJAX to REST services that returned JSON, which were mapped into the HTML using PURE.

I'm curious to see what working in that kind of structure would be like. Seems very tightly compartmentalized, quite possibly in a good way.

In particular, I'm not totally sold on the idea that interleaving application data with HTML on the server-side is the right approach - sending down a clean, cacheable template of HTML (possibly still generated on the server-side to put components together and so forth), and then sending down a really thin data representation and having the client interleave the two seems appealing, and I haven't yet worked with a web framework that goes in that direction.