Who needs XML?
Been thinking about the "and XML" part of Ajax and wondering why we need XML at all.
For example, 37 Signals recently rolled out its new Backpack web-based PIM application, and I've read a few complaints about how it doesn't work in browsers like Opera and older versions of Safari, presumably (I haven't looked under Backpack's hood personally so I'm going on word of mouth here, careful!) its heavy reliance on XMLHttpRequest for client-server data transfer.
(BTW, that's not meant to be a negative comment on Backpack on my part. Backpack looks VERY cool, and I intend to play with it extensively.)
So here's my thought: what's wrong with just the "AJ" part of the Ajax equation? Seems to me that there are lots of sturdy JS libraries that can deliver and receive pseudo-asynchronous data to/from the server that don't require the overhead of an XML parser. It's relatively easy to bootstrap a JavaScript message format at the server level, so why do we insist on pushing XML back the browser?
The obvious reason is, I guess, compatibility with other apps that read XML, but that doesn't seem particularly compelling when 99% of the apps I've seen are built to be run in a JS capable-browser. Why wouldn't you optimize your data format to suit the target environment?
As far as XMLHttpRequest is concerned, as one Opera user stated, "shouldn't it just work without it?"
19 Comments:
I completely agree - most of the time, the added overhead of generating and parsing XML just isn't worth the hassle. My favourite trick with XMLHttpRequest is simply to pass back a bunch of JavaScript from the server and run eval() on it. You can minimise the amount of JavaScript sent back by having it be simple calls to functions that have already been defined at the client. It's the simplest thing that could possibly work.
Taking Simon's idea one step further, you can serialise data and code using something like JSON. Much more lightweight and browser friendly than XML.
I've got a couple of reasons why I use XML, when I do use it. The first is that the stuff that I'm pulling back with XMLHTTPRequest isn't stuff that is only used by that Ajax client; it's also consumed by lots of other applications. The second is that if I'm shipping a lot of data back and forth, I have to do it in *some* format, and it's a lot easier to use XML, and get a load of parsing functions (getElementsByTagName(), &c., &c.) for free than it is to pass back data in some other structured way and parse it yourself.
All that said, though, I totally agree with both you and Simon. If you don't need it (because you're passing back one piece of data, or because it's not "data" so much as data within an action), then I don't use it; why bother bloating the data up with loads of tags when you don't need to?
...although Dean's point about JSON, which I always forget to use until it's too late, is a good one...
Hi Scott;
Are you saying not only to forget the XML part (I agree, more envelope than necessary) but also to eschew the XMLHTTP object for the data transfer part? I admit I've not been doing webdev of late so I'm not up to speed as to how cross-platform the XMLHTTP support is lately.
If so, are you suggesting we fall back on Iframe, img/cookie and javascript injection methods? If it works for the transfer part I would try to use XMLHTTP, which was (I assume) designed for arbitrary data transfer, over the other methods which are historical hacks to effect ersatz data-transfer by whatever means possible.
I think the things that is also key in the story, is the fact that Ajax has such a buzz right now, so a lot of people are using it in that way. The upside : the hype makes for a lot of developpers starting to try and implement ajax and finding out there are similair ways or methods (like JSON) to get stuff done.
After the Ajax-buzz passes over a bit i think developpers will start moving towards planning the better model and format for the job.
For the XML part: it has benefits when you need your data portable or available to other apps/techniques as well.
I think your story and the comments here make for what will start to happen after Ajax. 'Best Methods and Formats from an Ajax point of view'.
ps: I read this post calling it XAP (XML Application platform). Sounded ok at first, now i think it should maybe be JAP or something.
Any word on that? :)
Im not sure if your complaint is about XMLHttp or just XML. A couple of comments about each.
XML should be consumable by any browser that can handle javascript. The Sarrisa library is an excellent example of cross-browser XML. If all one is trying to do is talk with a browser, JSON may be better, but its been a couple of years since I've worked on anything which only targeted a web browser. That's where XML is indispensible.
As for complaints against XMLHttp, it will become part of every mainstream browser within the next couple of years. Once there, it will be the usual question everyobe does handwringing about - does the developer care about the other 5% of user's who can't use it. Since XMLHttp is best used in web applications, I would say that it is in the developer's interest to make as useful an interface for the user of the application as possible instead of trying to accomodate the other 5%. We've developed multiple apps using XMLHttp and users who have used those apps usually complain when having to go back to an app that is the traditional web-based form post approach.
IFRAMES are an obvious alternative to XMLHttp, but we've found that performance is a good 30-40% slower in IE (not sure about Firefox but would not surprise me if it was similar) than using XMLHttp. That's a huge difference and probably due to better asynch capabilities using XMLHttp.
Just my 2 cents.
If you're already serving XML on the server side, it should be moderately trivial to perform a server side transform using XSLT to turn it into JavaScript instead. Then you can have the best of both worlds.
Personally, I prefer XML so I can use XSLT to handle the data in an advanced and well-structured way.
And also, since XSLT can offer more than the basic functionality available in JavaScript, I think XSLT is the language to use for selectin and sorting data.
XML is very useful to maintain temporary data client-side.
The DOM provides everything you need to work with your XML document and it can save you a lot of back and forth with the server (I talk more about it here.)
And maybe XMLHttpRequest should be called HttpRequest since XML is only one of the 'format' you can use to send data.
I'd say the definitive method is to simply use whichever transport is best suited to your project.
I'd say that typically this package would be XML, XHTML, some simple JavaScript, or perhaps a combination of two.
Most good applications these days, whether written in Rails or otherwise, follow some MVC pattern. Within these patterns, your servers typical response to an asynchronous javascript request will be generated from a view. It's probably safe to assume that, for compactness and maintainability, your server-side application will return the same HTML based view or partial that it would when creating a full document to return when you've built your application to degrade gracefully.
In anycase, your JavaScript should be as loosely bound to your markup as possible.
The client-side code need not be extremely robust if your server side application is packaged efficiently.
I'd rather use JSON with AJAX or any other remote scripting approach in transferring data. XML transfer would be a bandwidth hog and would use a higher processing power compared to JSON (just eval'd it).
Another thing, using JSON and creating the script tag to call a js file with JSON in it (as variable), there is no need to eval it. Doing this leaves the whole AJAX process as whole.
Mr. Reader...
No need for insults. If you haven't noticed, Simon Willison is somewhat of an authority on JavaScript.
As for using eval, sure, there are some issues with this. Primarily the fact that your backend should probably not be generating a bunch of JavaScript. Secondly, eval is a pretty inefficient function, but so is walking a bloated XML file. With that said, I don't see a huge issue with sending basic function calls back as string from the server.
Google, who between Mail, Maps, Suggest, and Groups, is arguably the largest scale adopter of anything Ajax related does exactly that.
Yes, we all know Ajax is nothing new. We've been over this already. Almost everyone in this thread knows and understands that. Almost everyone in this thread is well known for early Remote Scripting techniques. Brent Ashley in particular has had a site dedicated to RS online for many years. You're not telling us anything we don't know, you're simply missing the point.
If you would let go of the animosity you hold towards the recent popularity of such techniques because of your earlier usage of RS, you might actually learn something here.
"When we get too arrogant to learn, we start to die." - Marshall Goldsmith
There's a compromise that keeps the XML but cuts overhead on both the server and client sides: send the XML with attributes instead of child elements.
I noticed that the simple queries being passed in one application were just table look-ups that returned sets of records. Generating XML-with-attributes slashed the size of the data stream, and also simplified the scripting on the client side. Instead of iterative walking through nested child nodes to pick up the data, a single pass through one node level -- with getAttribute to pick up values -- took care of the job much more cleanly.
The only drawback is the danger of embedded quotes in the values, so they need to be converted to avoid conflicts with the attribute's quotes.
Again, this won't work in all situations, but it can streamline XML handling.
I think the thing which sold me on XML (which I avoided at first) was the availability of tools and the portability of the knowledge needed to work with them.
XSLT processors are available both server and client side. Built in ways to manipulate and deal with DOMs are available both client and server side. Protocols to shuffle things back and forth and the means to use them already exist. Once all these are in play, fairly radical changes can be made on either side of the connection without worrying about (or touching) what's happening on the other side, and there is a whole class of structural issues I don't even have to think about.
Now I know this isn't true for everybody, perhaps not even for most, but for me using XML just has more advantages than disadvantages. Well, for now anyway...
[ADMIN] I've deleted Mr. Annoyed Reader's comment, as he was obviously drunk.
Anyway, I have no beef with XmlHttpRequest. It seems optimized for this kind of behind-the-scenes communication. I'm just not convinced that XML is the greatest delivery envelope. JSON is pretty cool, I'm surprised I haven't seen it mentioned before.
Also surpised that so many people are okay with using eval(). Wasn't eval() considered the devil's work a few years back, what with it's sluggish performance and memleaks?
"Secondly, eval is a pretty inefficient function, but so is walking a bloated XML file."
What if you don't need either though? I've had projects where I use a hidden iframe to communicate with a server without page refreshes; the server then generates serialized JavaScript in the page that gets pushed back to the iframe, and this script then calls back into the parent document to signal it is loaded. The great thing about this is it is very fast and cross browser, and is extremely useful for large datasets that generate things like tables that need to be fast.
For the first time in a long time, I seem to be ahead of the discussion, even if in a very small way.
I have tried exporing JSON, but I still think that good ol' arrays are probably the best form of data transport between the client and server when using XMLHttpRequest. Of course, I might be entirely wrong and/or might change my opinion later.
JSON is neat, but if you only need
to talk to PHP on the server side then check out: http://aspn.activestate.com/ASPN/Cookbook/PHP/Recipe/414334
Post a Comment
<< Home