These days, I have moved away from talks about markup (as most of you must have noticed), mostly for two reasons.
- XHTML is too stringent. It is so stringent, it is not practical.
- There are other ways to save bandwidth.
Reasonable digress: Of late, I have been damn busy. I guess everyone goes through these phases where he thinks that he’s reading too much RSS, but I’ve just stopped keeping myself updated because I don’t have the time anymore. However, I still take the time to comment on the odd good article.
One such post was Roger Johansson’s. He talked about how XHTML can be made easier to use, but in his comments (though he tried hard not to), the discussion shifted to whether XHTML is really worth the effort or not. I maintained that though XHTML is a good way to learn, it is probably not what we’ll use in practice.
That apart, here’s why I am making this post.
I’ve been working on a lot of DHTML these days. Not in the traditional sense – I probably have to call it DOM Scripting to be politically correct. XMLHttpRequest has been my most interesting toy. I’ve been playing with it like a baby boy plays with his first toy truck. He just rides it all over the place. He runs it over terrains that the toy couldn’t possibly take on, just because somewhere in his heart he’s confident that it’ll hold out. XMLHttpRequest has been my toy, and the web is my terrain.
Here are my lessons, good and bad, listed out, while working with XMLHttpRequest.
- I think this is the most important issue. Using XMLHttpRequest doesn’t change the URL. Think about this. Eric said that a page that loads faster is good for business, and XMLHttpRequest does that for you in more ways than one. But XMLHttpRequest doesn’t respect URL resources, as seen by the address bar. If you use XMLHttpRequest, your page’s URL remains the same, whatever else you do. Do you need permalinks for your content? XMLHttpRequest can't deliver.
element.innerHTMLwon’t work with XHTML. You’ll have to get into the mess of
element.appendChildway too often. There are a couple of tutorials on the web to explain these concepts, but mostly you are on your own.
- XMLHttpRequest doesn’t come without its differences between browsers and their implementations. I don’t mean to scare the one’s who are starting – it’s really not that difficult. But just don’t expect one piece of code to work everywhere. We haven’t reached markup, styling and scripting nirvana yet.
- I’ve come across a lot of browser bugs in the implementation of XHTML and XMLHttpRequest scripting. I use Firefox, and (ok, probably after Opera) I think Firefox’s support for standards is pretty good. Yet, Firefox catches me off guard sometimes. And don’t get me started about other browsers yet, including the most popular one. (By the way, for the uninformed, XMLHttpRequest is NOT part of the standard – probably why Opera hadn’t supported it until recently.)
- In the end, probably in a nerdy sort of way, XMLHttpRequest is fun. It makes entire page-loads unnecessary. It makes information easier and faster to get to. It makes the user happy. It doesn’t involve too many UI issues. (I thought a user will never be comfortable unless he sees a page refresh when he clicks on a link in the browser. Obviously, I am wrong.) If well planned, XMLHttpRequest rocks!
- XMLHttpRequest is tempting to overuse. This not such a problem from the developer’s point of view. However, I am not so sure if it’ll really save you bandwidth in the long run. The problem is that, since users find it so responsive, users will like to pamper themselves with more data than they’d otherwise need. XMLHttpRequest makes it easy, and fast. Just what the users need to have a good experience. I think all those talks about XMLHttpRequest saving the developers’ bandwidth needs to be re-thought. I have no math to back me up, but this is what my hunch tells me.
- Did I say yet that XMLHttpRequest rocks? It’s the best thing that happened to the web since the invention of HTTP itself. It’s the stuff that’s going to direct the development of the Internet itself for the next half decade. But like every other intoxicating substance, it could be a life-saver or a poison depending on how you use it.
It’s just a matter of what suits the job best. Flying a jet to work is too much power in your hands, but walking down to work is too little, if you know what I mean. You just have to use the right tool at the right time. XMLHttpRequest is just a tool – you have to decide when it’d be good and when it’d be impractical.
For those who are in doubt, XMLHttpRequest is a tool you are not going to be able to do without. I think that web-developers who still work with old style HTML are already on their way to losing out, but now web-developers who haven’t mastered XMLHttpRequest are on their way to meeting the same fate. Yet, it’s a tool like any other – it has to be used at the right time for the right purpose. Every other time, it’s probably more effort than it’s worth.