Its awfully hard to justify changing code just to change code. It’d be one thing if you had to go in and make major changes that would force you to do massive retesting anyway but even then, I prefer to work in smaller steps…

Well, I think the XHR abbreviation was about the only place I’ve been ahead of you! Even then, I used it (yeah, those were my chapters – sorry about the spell checking thing!) because I’m a lazy typist. Just can’t stand typing in the whole thing all the time and I would guess we mentioned XHR dozens and dozens of times.

I’m worrying a bit about overuse myself. As you say, we’ve got a new hammer here and I think lots of folks are going to start beating on their thumbs. I’m kicking around some blog ideas revolving around that – more specifically the volume of tiny, granular requests that are going to start pooping up (can you say data transfer object?) It will be interesting to see how apps that were architected for say, 50 concurrent users will fair when those 50 users are making dozens of calls instead of just one or two.

I agree on not fixing something that’s not broken. I’ve hardly touched the code on the http://www.blogchat.com chat application I run with Tim Aiello for nearly three years and there are still quite a few regular users.

At the time I commented that I didn’t think XHR was a common enough abbreviation to use, I hadn’t yet seen it used anywhere despite having been on top of all of the buzz. It’s become a widely accepted short form since then – looks like you were just ahead of me!

I’m starting to see some of the predictable overuse of Ajax – a user and password box with a login button and then an Ajax call that replaces the entire visible page, for instance. Some people get a new hammer and every problem looks like a nail.

Despite it’s widespread adoption, XHR is still as you say an afterthought (just look at creating an instance) and someday I too hope we have a built in way to communicate that is browser independent. I fear that a lot of shops will delay or avoid “ajaxifying” their apps due to these cross browser issues. Of course, you still need to rely on the scripting approaches like JSRS if you need to support older browsers.

Thanks for subscribing, I really appreciate another reader! I hope I write some more stuff worth commenting about…

I’ve preferred using XMLHTTP myself since 2001 or so on projects that could be limited to the browsers that supported it. I had thought many times that I might XHR-ify my iframes-based JSRS library but left it as is for those who needed that compatibility. Of course I kick myself now for not publishing any of my XMLHTTP-based remote scripting stuff at the time, but there are so many fabulous resources now that I don’t think I’d be able to offer anything new by jumping back in.

Although it’s a great improvement over really hackish methods like iframes or img/cookie, XMLHTTP was still an afterthought and I’d like to see a future where the browsers all have designed-in communication methods that give us more control for error handling, timeouts, retries, etc.

I’ve subscribed to your RSS feed now – looking forward to following along.