I was going through my referrer list today, and come across another user who came to me through Eric Meyer’s post about (and in response to my older post) the Economics of XHTML, where he (Eric) talks about how the savings in bandwidth appreciates the value of the site.
These days, I have moved away from talks about markup (as most of you must have noticed), mostly for two reasons.
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.
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.
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.
- Using XMLHttpRequest involves a lot of DOM Scripting (especially if you think I am correct when I say that data should be passed as JavaScript over XMLHttpRequest). This is a problem for me, mostly because I use XMLHttpRequest in conjunction with XHTML. A command as simple as
element.innerHTMLwon’t work with XHTML. You’ll have to get into the mess ofdocument.createElement,element.setAttributeandelement.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.
Previously:
9 comments:
I don't understand the first problem you list. I think people just want to use it to build web apps and whether or not the address/url changes isn't much of a deal.
What do seem to be major limitations are 1) the inconsistencies across browsers and 2) the cross-domain restrictions.
I see a lot of people noting that this whole thing is supposedly "nothing new" and "been around for awhile". These people miss the point. Fact is, this thing is getting nearly zero usage despite being incredibly valuable. The documentations on this stuff is, at best, horrible.
ps I would never base an XHTML v. HTML decision on bandwidth savings. If people cared an ounce about bandwidth they'd look like Google or Craigslist. You'd get much better savings simply deleting one useless image per page.
Pat:
The issue of the address-bar URL not changing is much the same with XMLHttpRequest as it is with framed web pages. The problems include un-bookmarkable pages, difficult-to-get permalinks, broken functionality of the back button, etc. This hasn't been a problem yet with XMLHttpRequest, but then again, we are just starting to use XMLHttpRequest and the wow-factor hasn't yet died down.
Inconsistencies across browsers may be reasonably easy to handle using code. However, you are right about the cross-domain scripting. A little research later, I found out that browser manufacturers have started realizing this as being detrimental to the growth of web services itself, and steps are being taken to fix the security issues.
I think this cross-domain problem might be easy to circumvent if the servers communicate with each other, and the client gathers data from only one domain. So, effectively, the server mirrors the information from different domains, probably realtime. This is just a thought - I'll have to experiment with this to be sure.
I'm wondering if you could import a `script` tag from the XHTML document into the host document. That would be a sweet way to transfer JavaScript via XMLHTTPRequest I think.
Actually, in a comment to one of my earlier posts, Adam Michela gave a beautiful snippet of JavaScript to dynamically include a JavaScript file from the server. It requires a DOM compliant browser, though, but that should be reasonable to ask for.
Rakesh, while that would work, you won't be able to send anything to the server anymore, aside from sending variables via the GET request.
P.S. I was the "Anonymous" who suggested importing a `script` tag. Gotta love Blogger for not allowing anonymous posters to use contact infromation!
- Mark Wubben
What was that again, Mark? I didn't quite understand what you meant.
Rakesh, sorry for the late reply, been a bit busy last few days... and I'm not really sure what you want to know, either :)
- Mark Wubben
For the innerHTML problem with XHTML, in a web application, I use something like this:
var parser = new DOMParser();
var doc = parser.parseFromString(xmlhttp.responseText, "text/xml");
Now "doc" is the returned XML made into elements without the mess of creating each element and setting its attributes and text.
Post a Comment