Tuesday, May 03, 2005

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?"


At 3:17 PM, Blogger Anne said...

Opera's implementation of XMLHttpRequest is based on Document Object Model (DOM) Level 3 Load and Save Specification which is for loading XML documents. See also my post about Opera 8 and related comments.

At 3:29 PM, Anonymous Anonymous said...

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.

At 3:36 PM, Anonymous Anonymous said...

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.

At 3:37 PM, Blogger Stuart Langridge said...

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?

At 3:38 PM, Blogger Stuart Langridge said...

...although Dean's point about JSON, which I always forget to use until it's too late, is a good one...

At 5:47 PM, Blogger Brent Ashley said...

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.

At 7:17 PM, Anonymous Anonymous said...

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? :)

At 7:52 PM, Anonymous Anonymous said...

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.

At 2:37 AM, Anonymous Anonymous said...

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.

At 6:28 AM, Anonymous Anonymous said...

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.

At 7:48 AM, Anonymous Anonymous said...

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.

At 4:09 PM, Anonymous Anonymous said...

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.

At 7:03 PM, Anonymous Anonymous said...

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.

At 5:50 AM, Anonymous Anonymous said...

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

At 8:54 AM, Anonymous Anonymous said...

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.

At 9:22 AM, Anonymous Anonymous said...

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...

At 11:15 AM, Blogger scottandrew said...

[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?

At 11:45 AM, Blogger Adam Michela said...


"Secondly, eval is a pretty inefficient function, but so is walking a bloated XML file."


Looking forward to meeting you in SF btw!

At 5:09 PM, Blogger Brad Neuberg said...

"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.

At 12:49 AM, Blogger Rakesh Pai said...

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.

At 11:38 AM, Blogger noahspurrier said...

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

At 2:21 PM, Blogger Work From Home Center said...

Hi, Thanks for your interesting blog. Keep up the great work! I also have a site & blog about Envelope Stuffing Work from Home
, please feel free to visit.

At 3:20 PM, Blogger daniel said...

In search of a PERL programmer for my site. Swing by and let me know
Credit Card Company
My website provides information on credit cards and credit reports. Mostly
low interest credit cards. Looking for PERL help so I can parse large
text files. If interested email me

At 5:44 AM, Blogger thomas said...

Thanks Dan. I found a programmer!
*Providing above industry standards
Low Cost Health Insurance
Cheap Low Cost Health Insurance

At 6:08 AM, Blogger TimmyPowers said...

I 100% agree with that view point. These remarks are great and this is why I come back

Life Insurance Policy
Term Life Insurance Policy

At 6:23 AM, Blogger cmeltifa said...

I am not sure I agree with Timmy on this one. I will need to sleep on it :0)
Voip Phone Services
Broadband Voip Phone Services

At 6:41 AM, Blogger TimmyPowers said...

Use my programmer :0) instead! kidding..
Regards, Timmmy
Disaster Recovery
Disaster Recovery Services

At 5:23 AM, Blogger Rachel said...

Nice post Dom. Good info!

Debt Consolidation Services

Credit Card Debt Consolidation Services

At 5:44 AM, Blogger jeffT said...

I am personally up in the air with the remark. To each's own :0)

Home Owner Insurance
I am personally up in the air with the remark. To each's own :0)
Home Owner Insurance Quotes

At 6:02 AM, Blogger thomas said...

Valid argument but I don't think so :-(
Ionic Air Purifiers

At 8:53 AM, Blogger jeffT said...

I am on the fence about that issue. That is my own unbiased opinion of course!
Terrific site and great comments.
Ionic Air Purifiers

At 7:37 AM, Blogger thomas said...

Great site! Great comments!
Cheap Cellular Phones

At 8:36 AM, Blogger Jason said...

I couldn't agree anymore. Keep up the great work :-) Very impressive

-Homerun :-)
Low Cost Health Insurance
Cheap Low Cost Health Insurance

At 5:55 AM, Blogger daniel said...

I 100% agree with Jay on that!

At 5:56 AM, Blogger daniel said...

Why else would we think that way????
Life Insurance Policies

At 6:02 AM, Blogger thomas said...

Fantastic blog. I 100% agree with the above comments! I will be back!
Newest Cellular Phones
Newest Nokia Cellular Phones

At 6:03 AM, Blogger thomas said...

Fantastic blog. I 100% agree with the above comments! I will be back!
Newest Cellular Phones
Newest Nokia Cellular Phones

At 12:13 PM, Blogger daniel said...

Great commenting. Great posts. Great job! :-)
Help Quit Smoking Movement

At 10:09 AM, Blogger daniel said...

This site was really helpful and informative. Keep up the great work!


At 2:53 AM, Blogger Joy-hgf675 said...

Your post is having nice info of "and XML" part of Ajax. It's really informative

Your blog is really a eye opener. I never thought i could, get this much brainstorming info in a blog. Keep up the good work. I just came to this blog through search engine while having a break from my current project Credit Card. Though your blog is not exactly straight related to my current project. I glad i have a visit today. I too wish to come back and participate in the comment section. So i clearly book marked your blog. See you later.

At 6:43 PM, Blogger LeProgrammeur said...


I posted a tutorial at www.KYNOU.com about Loading and Parsing XML with AJAX.
Go to the link above and search for: Loading and Parsing XML with Ajax.
Also in this website there is a chat room where I try to spend time answering questions. Feel free to stop by.

At 6:43 PM, Blogger LeProgrammeur said...


I posted a tutorial at www.KYNOU.com about Loading and Parsing XML with AJAX.
Go to the link above and search for: Loading and Parsing XML with Ajax.
Also in this website there is a chat room where I try to spend time answering questions. Feel free to stop by.

At 8:23 AM, Blogger search engine secrets said...

The greatest lesson in life is to know that even fools are right sometimes.
search engine ranking
Winston Churchill

At 3:51 PM, Blogger Bayarealawyers said...

Debt Help Home Loans Loan Consolidation can help you reduce your interest burden by charging an interest rate lower than the rate on your existing loans.


Post a Comment

<< Home