XMLHttpRequest - parsing returned data

[Tony]

I'm wondering if anyone has run any tests to compare the speed of
parsing XML vs text in simple lists - such as:

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>User 1</user>
<user>User 2</user>
<user>User 3</user>
</users>

and retrieving using .responseXML
vs:

User 1|User 2|User 3

then using .split('|') to parse the .responseText

Just a matter of curiosity - thx!

 

[VK]

I'm wondering if anyone has run any tests to compare the speed of
parsing XML vs text in simple lists - such as:

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>User 1</user>
<user>User 2</user>
<user>User 3</user>
</users>

and retrieving using .responseXML
vs:

User 1|User 2|User 3

then using .split('|') to parse the .responseText

Just a matter of curiosity - thx!

That collides with a rather old discussion "What's wrong with AJAX":
<http://groups.google.com/group/comp..._frm/thread/f6ce0a5e95d8bf30/95c4d63e4c82f068>

Still the whole year 2005 has been spent by numerous users to
re-discover an open-source fact: for explicit script handling XML is
the least convenient and the most uneffective format one could imagine.
But Microsoft IXMLHTTPRequest was never minded to be used in such way.
It was merely further evolution of *data binding*: one click to change
the source leads to "zero maintenance" page update.
The curved path by where the things went can be traced back to the
famous Adaptive Path article
<http://www.adaptivepath.com/publications/essays/archives/000385.php>

By simply reading posts in this newsgroup one can trace the development
from the initial attempt to use AJAX for XML - to the final use as a
simple responseText grabber where the responseText evolutionated from
some XML-like format to script-ready and script-friendly format close
to the serialized object form.
Eventually as I expected people dropped any XML-attempts whatsoever and
started to move to JSON (or JSON clones) as transport media.

Next year I see further evolution of AJAX/JSON symbiotic use, but it is
a limited path because of AJAX same-domain limitation. It makes it hard
to use in a complex corporate environment (with different sub-domains
and even domains). Also it is not usable for server-side free RSS
feeds. After the users will be fed up enough of this: they will move on
some cross-domain free solution like script.src (or something else).
Initially it will be kind of hack, but it will be eventually blessed
into standards as soon as it will get enough popularity. I accept bets
on it as 2:1

Another great influence of AJAX is the power demonstration of users to
browser producers and standard writers. Some browsers could not /
refused to implement the most basic features for years. So more amazing
it was to watch the entire year how they rushed to implement or at
least mimic XMLHttpRequest functionality to not loose their users. And
they actually *fixed all bugs in a timely manner*, sometimes within a
month! Just for this reminder who is the customer and who is the humble
service provider - just for this we have to love AJAX.

IMHO

 

[Douglas Crockford]

I'm wondering if anyone has run any tests to compare the speed of
parsing XML vs text in simple lists - such as:

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>User 1</user>
<user>User 2</user>
<user>User 3</user>
</users>

and retrieving using .responseXML
vs:

User 1|User 2|User 3

then using .split('|') to parse the .responseText

Just a matter of curiosity - thx!

You might consider using JSON instead of XML.

{"users": ["User 1", "User 2", "User 3"]}

It is a whole lot easier to handle.

http://www.JSON.org

 

[Tony]

That collides with a rather old discussion "What's wrong with AJAX":

<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread...>

VK - thanx for the link, but I didn't see much relating to my specific
question. I'll admit to perhaps being dense - if I missed it, I would
appreciate a little direction

You might consider using JSON instead of XML.

{"users": ["User 1", "User 2", "User 3"]}

It is a whole lot easier to handle.

Douglas - easier to handle, perhaps. But what I'm most interested in at
the moment is speed of execution.

If such a test hasn't been done, I will probably do one - I just
wanted to see if it was already done first.

 

[VK]

If such a test hasn't been done, I will probably do one - I just
wanted to see if it was already done first.

Any DOM method call is much longer than a JavaScript native method. It
is kind of "prove me in 1 min that the Earth is a globe" Out of
immediate arguments right now but I'm sure that there is somethere a
fact sheet of in-script methods vs. outside (DOM) methods call.

With JSON (or JSON-like) approach you have to deal with DOM only once:
while feeding processed results to your document.
With XML you have to do it twice: first to parse XML data, second to
feed the document. Plus this - minus that - and being conservative - I
predict at least 30% speed increase. Would be great to know what kind
of Kassandra am I

 

[Jim Ley]

You might consider using JSON instead of XML.

{"users": ["User 1", "User 2", "User 3"]}

It is a whole lot easier to handle.

Douglas - easier to handle, perhaps. But what I'm most interested in at
the moment is speed of execution.

JSON is orders of magnitude faster than XML in almost all situations,
in almost all UA's, please confirm this yourself, but I'd be shocked
if you find different.

Jim.

 

[Matt Silberstein]

I'm wondering if anyone has run any tests to compare the speed of
parsing XML vs text in simple lists - such as:

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>User 1</user>
<user>User 2</user>
<user>User 3</user>
</users>

and retrieving using .responseXML
vs:

User 1|User 2|User 3

then using .split('|') to parse the .responseText

Just a matter of curiosity - thx!

You might consider using JSON instead of XML.

{"users": ["User 1", "User 2", "User 3"]}

It is a whole lot easier to handle.

http://www.JSON.org

ISTM that there two major differences is that JSON does not have a
doctype so we can validate against some external definition and it
does not have explicit closing tags. Is that correct?


--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

 

[Douglas Crockford]

You might consider using JSON instead of XML.

{"users": ["User 1", "User 2", "User 3"]}

It is a whole lot easier to handle.

http://www.JSON.org

ISTM that there two major differences is that JSON does not have a
doctype so we can validate against some external definition and it
does not have explicit closing tags. Is that correct?

JSON does not have doctypes because it is not a document format. It is
a data interchange format. It is easy to determine that the data
delivered is syntactically correct (or "well formed"). Ultimately,
data must be verified by the application that consumes it. This cannot
be done syntactically. Verification is easier to do in JSON because
the structure of the data conforms to the affordances of the
programming language.

JSON does not have tags, so it does not have closing tags. It does
have syntactic structure, using { ... } to wrap unordered collections
of key/value pairs, and [ ... ] to wrap sequences of values.

 

[Thomas 'PointedEars' Lahn]

Any DOM method call is much longer than a JavaScript native method.

That statement, in and of itself, is pure nonsense, regardless what
meaning may be attached to the words.


PointedEars

 

[Tony]

That's about what I suspected - but I was hoping for something more
than suspicion to go on...

That statement, in and of itself, is pure nonsense, regardless what
meaning may be attached to the words.

Would you please clarify your meaning?

 

[Luke Matuszewski]

I'm wondering if anyone has run any tests to compare the speed of
parsing XML vs text in simple lists [...]

From <URL:http://blogs.ebusiness-apps.com/dave/?p=45> we can think that

JSON is slightly faster (or equal) than XML when there dataset is
small... bigger datasets are parsed faster for XML...

I guess that only reason for it is not native implementation of JSON
parser... i also guess that native implementation of JSON parser would
be faster then XML.

Whole thing would be better is Web API Working Group would add
extension to XMLHttpObject, so between responseText and responseXML
there could be

XMLHttpObject.responseJSON

, which will return 'data' JavaScript object...not just for speed
purpose, but for 'easyness' of mainipulating JSON object at JavaScript
side (even at other langueges sides - beacause there are also
implementations for other languages...).

I think that there is reason to write to Web API wokring group
<URL:http://www.w3.org/2006/webapi/> to include it in futer
recomendation of it, but first step is for Douglas Crockford to do so.