<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: XML vs JSON: A Second Sober Look</title>
	<atom:link href="http://blogs.nitobi.com/dave/2007/01/08/xml-vs-json-a-second-sober-look/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.nitobi.com/dave/2007/01/08/xml-vs-json-a-second-sober-look/</link>
	<description>let the chips fall where they may</description>
	<lastBuildDate>Fri, 27 Feb 2009 15:19:27 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Dave Johnson</title>
		<link>http://blogs.nitobi.com/dave/2007/01/08/xml-vs-json-a-second-sober-look/comment-page-1/#comment-24606</link>
		<dc:creator>Dave Johnson</dc:creator>
		<pubDate>Thu, 14 Jun 2007 21:20:54 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.nitobi.com/dave/?p=178#comment-24606</guid>
		<description>I certainly agree that JavaScript + JSON are much easier and everyone knows them!

I think that Internet Explorer is the main reason to want to use XSLT though since it is significantly faster in terms of performance.</description>
		<content:encoded><![CDATA[<p>I certainly agree that JavaScript + JSON are much easier and everyone knows them!</p>
<p>I think that Internet Explorer is the main reason to want to use XSLT though since it is significantly faster in terms of performance.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: vitrus</title>
		<link>http://blogs.nitobi.com/dave/2007/01/08/xml-vs-json-a-second-sober-look/comment-page-1/#comment-24528</link>
		<dc:creator>vitrus</dc:creator>
		<pubDate>Wed, 13 Jun 2007 09:57:32 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.nitobi.com/dave/?p=178#comment-24528</guid>
		<description>But this will always depend on the kind of application you are building! Sebastien&#039;s example with the client side sorting in XSLT is nice, but what if the dataset is larger than you ever want to retrieve in one query (so you need more than one page for your data!). In that case you NEED to go back to the server and sort it there (another example is ofcourse filtering). 

In this case you will need to build a solution that does server side sorting and preferably do as much on the client as possible (making the responses as small as possible).

This is not too hard to code by the way, but almost none of the available frameworks has a good solution for this. I believe backbase has some dataList or dataGrid thingy that solves this pretty well... 

Anyway, if you build it yourself and keep the response as small as possible like I said... Than JSON will probably be the fastest way to achieve this. Another argument is that XSLT is a relatively new (thus unknown, thus poorly documentated for beginners thus very hard and complicated) technique. Everybody knows javascript and dom, so JSON is easier.</description>
		<content:encoded><![CDATA[<p>But this will always depend on the kind of application you are building! Sebastien&#8217;s example with the client side sorting in XSLT is nice, but what if the dataset is larger than you ever want to retrieve in one query (so you need more than one page for your data!). In that case you NEED to go back to the server and sort it there (another example is ofcourse filtering). </p>
<p>In this case you will need to build a solution that does server side sorting and preferably do as much on the client as possible (making the responses as small as possible).</p>
<p>This is not too hard to code by the way, but almost none of the available frameworks has a good solution for this. I believe backbase has some dataList or dataGrid thingy that solves this pretty well&#8230; </p>
<p>Anyway, if you build it yourself and keep the response as small as possible like I said&#8230; Than JSON will probably be the fastest way to achieve this. Another argument is that XSLT is a relatively new (thus unknown, thus poorly documentated for beginners thus very hard and complicated) technique. Everybody knows javascript and dom, so JSON is easier.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SÃ©bastien Arnaud</title>
		<link>http://blogs.nitobi.com/dave/2007/01/08/xml-vs-json-a-second-sober-look/comment-page-1/#comment-10316</link>
		<dc:creator>SÃ©bastien Arnaud</dc:creator>
		<pubDate>Fri, 09 Feb 2007 06:01:28 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.nitobi.com/dave/?p=178#comment-10316</guid>
		<description>I will have to disagree James, depending on your AJAX application it may or may not be faster. I have a page that renders a large sortable table via AJAX and it is much faster than previously when I was rendering the HTML on the server first. I will give some numbers: 450K XML file + 20K XSL file generate a 1.1Mo HTML file. It takes between 2-3 seconds in IE or FF on a decent machine (less than 3 years old). So using XML/XSLT to render in the browser cuts my data transfer in half, and in this case renders faster on the client side for most people (with a 150ko/s connection, make the calculation;). Also this is not without saying that with rendering XML on the client side, they can sort with one click and within 2-3 sec get the whole dataset sorted to their taste. There is no way that JSON could do this with this much data, and re-rendering the page with the proper sort criteria on the server side is history IMHO! 
Dave - excellent post, can&#039;t agree more!</description>
		<content:encoded><![CDATA[<p>I will have to disagree James, depending on your AJAX application it may or may not be faster. I have a page that renders a large sortable table via AJAX and it is much faster than previously when I was rendering the HTML on the server first. I will give some numbers: 450K XML file + 20K XSL file generate a 1.1Mo HTML file. It takes between 2-3 seconds in IE or FF on a decent machine (less than 3 years old). So using XML/XSLT to render in the browser cuts my data transfer in half, and in this case renders faster on the client side for most people (with a 150ko/s connection, make the calculation;). Also this is not without saying that with rendering XML on the client side, they can sort with one click and within 2-3 sec get the whole dataset sorted to their taste. There is no way that JSON could do this with this much data, and re-rendering the page with the proper sort criteria on the server side is history IMHO!<br />
Dave &#8211; excellent post, can&#8217;t agree more!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Johnson</title>
		<link>http://blogs.nitobi.com/dave/2007/01/08/xml-vs-json-a-second-sober-look/comment-page-1/#comment-9356</link>
		<dc:creator>Dave Johnson</dc:creator>
		<pubDate>Fri, 12 Jan 2007 17:57:31 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.nitobi.com/dave/?p=178#comment-9356</guid>
		<description>Sorry, there was some implicit context there. One could also argue differently based on the speed of the client computer, load on the server and network bandwidth. Of course you are right James that rendering the HTML on the server can be a good option - though it will mean more server load and more data to transfer across the network.</description>
		<content:encoded><![CDATA[<p>Sorry, there was some implicit context there. One could also argue differently based on the speed of the client computer, load on the server and network bandwidth. Of course you are right James that rendering the HTML on the server can be a good option &#8211; though it will mean more server load and more data to transfer across the network.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Bennett</title>
		<link>http://blogs.nitobi.com/dave/2007/01/08/xml-vs-json-a-second-sober-look/comment-page-1/#comment-9292</link>
		<dc:creator>James Bennett</dc:creator>
		<pubDate>Tue, 09 Jan 2007 19:32:43 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.nitobi.com/dave/?p=178#comment-9292</guid>
		<description>&quot;The fastest way to render data to HTML is using XML and XSLT.&quot;

No, the fastest way to render data to HTML is to render it as HTML on the server side and shove that down the wire; on the client you have no parsing, no queries, no data structures to walk -- you just assign to some element&#039;s innerHTML and you&#039;re done.</description>
		<content:encoded><![CDATA[<p>&#8220;The fastest way to render data to HTML is using XML and XSLT.&#8221;</p>
<p>No, the fastest way to render data to HTML is to render it as HTML on the server side and shove that down the wire; on the client you have no parsing, no queries, no data structures to walk &#8212; you just assign to some element&#8217;s innerHTML and you&#8217;re done.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Johnson</title>
		<link>http://blogs.nitobi.com/dave/2007/01/08/xml-vs-json-a-second-sober-look/comment-page-1/#comment-9254</link>
		<dc:creator>Dave Johnson</dc:creator>
		<pubDate>Mon, 08 Jan 2007 19:06:23 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.nitobi.com/dave/?p=178#comment-9254</guid>
		<description>Yes you are absolutely right Michael!

We will have to see what Internet Explorer does with E4X though before it really catches on I guess.</description>
		<content:encoded><![CDATA[<p>Yes you are absolutely right Michael!</p>
<p>We will have to see what Internet Explorer does with E4X though before it really catches on I guess.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Thorne</title>
		<link>http://blogs.nitobi.com/dave/2007/01/08/xml-vs-json-a-second-sober-look/comment-page-1/#comment-9253</link>
		<dc:creator>Michael Thorne</dc:creator>
		<pubDate>Mon, 08 Jan 2007 18:59:25 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.nitobi.com/dave/?p=178#comment-9253</guid>
		<description>Another piece of the pie that people are not really looking at is E4X (ECMAScript for XML).

MDC: E4X

http://developer.mozilla.org/en/docs/E4X

ECMAScript for XML (E4X) is a programming language extension that adds native XML support to JavaScript. It does this by providing access to the XML document in a form that feels natural for ECMAScript programmers. The goal is to provide an alternative, simpler syntax for accessing XML documents than via DOM interfaces.

E4X is standardized by Ecma International in ECMA-357 standard, see http://www.ecma-international.org/publications/standards/Ecma-357.htm

In Gecko 1.8 based browsers such as Firefox 1.5, E4X is already partially enabled for web page authors.</description>
		<content:encoded><![CDATA[<p>Another piece of the pie that people are not really looking at is E4X (ECMAScript for XML).</p>
<p>MDC: E4X</p>
<p><a href="http://developer.mozilla.org/en/docs/E4X" rel="nofollow">http://developer.mozilla.org/en/docs/E4X</a></p>
<p>ECMAScript for XML (E4X) is a programming language extension that adds native XML support to JavaScript. It does this by providing access to the XML document in a form that feels natural for ECMAScript programmers. The goal is to provide an alternative, simpler syntax for accessing XML documents than via DOM interfaces.</p>
<p>E4X is standardized by Ecma International in ECMA-357 standard, see <a href="http://www.ecma-international.org/publications/standards/Ecma-357.htm" rel="nofollow">http://www.ecma-international.org/publications/standards/Ecma-357.htm</a></p>
<p>In Gecko 1.8 based browsers such as Firefox 1.5, E4X is already partially enabled for web page authors.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

