<?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"
	>
<channel>
	<title>Comments on: JavaScript and domain specific languages</title>
	<atom:link href="http://www.sitepoint.com/blogs/2005/03/01/javascript-and-domain-specific-languages/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sitepoint.com/blogs/2005/03/01/javascript-and-domain-specific-languages/</link>
	<description>News, opinion, and fresh thinking for web developers and designers. The official podcast of sitepoint.com.</description>
	<pubDate>Tue, 02 Dec 2008 07:24:57 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: nico</title>
		<link>http://www.sitepoint.com/blogs/2005/03/01/javascript-and-domain-specific-languages/#comment-616789</link>
		<dc:creator>nico</dc:creator>
		<pubDate>Wed, 30 Jan 2008 04:02:59 +0000</pubDate>
		<guid isPermaLink="false">1833825942#comment-616789</guid>
		<description>"and the point of processing data on the client that inevitably needs to come from the server is?"

eheh... probably you would have a different opinion now, having seen google spreadsheets :)</description>
		<content:encoded><![CDATA[<p>&#8220;and the point of processing data on the client that inevitably needs to come from the server is?&#8221;</p>
<p>eheh&#8230; probably you would have a different opinion now, having seen google spreadsheets :)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: sil</title>
		<link>http://www.sitepoint.com/blogs/2005/03/01/javascript-and-domain-specific-languages/#comment-3738</link>
		<dc:creator>sil</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">1833825942#comment-3738</guid>
		<description>&lt;p&gt;Blimey. The templating stuff sounds cool. I'm less convinced by the minilang idea, since the SQL example given is a bit contrived, but I do like the idea of client-side templating, since with Ajax/remotescripting in play, the client *is* the server. People are experimenting with the best way to pass data back and forth -- pass eval()able JS, pass XML and then parse it with a DOM clientside, pass formatted HTML to be slammed into the document. This is much the same as server-side things were, and templating is a good match there, so I see no reason why it wouldn't be so on the client as well.&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>Blimey. The templating stuff sounds cool. I&#8217;m less convinced by the minilang idea, since the SQL example given is a bit contrived, but I do like the idea of client-side templating, since with Ajax/remotescripting in play, the client *is* the server. People are experimenting with the best way to pass data back and forth &#8212; pass eval()able JS, pass XML and then parse it with a DOM clientside, pass formatted HTML to be slammed into the document. This is much the same as server-side things were, and templating is a good match there, so I see no reason why it wouldn&#8217;t be so on the client as well.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: pd</title>
		<link>http://www.sitepoint.com/blogs/2005/03/01/javascript-and-domain-specific-languages/#comment-3739</link>
		<dc:creator>pd</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">1833825942#comment-3739</guid>
		<description>&lt;p&gt;and the point of processing data on the client that inevitably needs to come from the server is?&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>and the point of processing data on the client that inevitably needs to come from the server is?</p>]]></content:encoded>
	</item>
	<item>
		<title>By: maetl</title>
		<link>http://www.sitepoint.com/blogs/2005/03/01/javascript-and-domain-specific-languages/#comment-3740</link>
		<dc:creator>maetl</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">1833825942#comment-3740</guid>
		<description>&lt;p&gt;People often mention the DOM as the Drudgery Object Model. Combine that with Model-View-Confusion, and it's easy to miss the whole point of what an application interface is supposed to be doing. &lt;/p&gt;

&lt;p&gt;The traditional hypertext model of the server delivering a document to the browser is still as relevant as ever, but for some reason it is usually assumed that the more data intensive an application, the more work is required on the server.&lt;/p&gt;

&lt;p&gt;If we turn this idea on its head - the data has to come from the server, but the reason to emphasise processing on the client, is when the interface needs to wrap and manipulate that data as directly as possible (or: the interface is the data - the spreadsheet case being the best example).&lt;/p&gt;

&lt;p&gt;Steve Yen's arguments are pretty convincing - but I think there is always going to be a question of where to draw the separation between client and server.&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>People often mention the DOM as the Drudgery Object Model. Combine that with Model-View-Confusion, and it&#8217;s easy to miss the whole point of what an application interface is supposed to be doing. </p>
<p>The traditional hypertext model of the server delivering a document to the browser is still as relevant as ever, but for some reason it is usually assumed that the more data intensive an application, the more work is required on the server.</p>
<p>If we turn this idea on its head - the data has to come from the server, but the reason to emphasise processing on the client, is when the interface needs to wrap and manipulate that data as directly as possible (or: the interface is the data - the spreadsheet case being the best example).</p>
<p>Steve Yen&#8217;s arguments are pretty convincing - but I think there is always going to be a question of where to draw the separation between client and server.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Alex Kapranoff</title>
		<link>http://www.sitepoint.com/blogs/2005/03/01/javascript-and-domain-specific-languages/#comment-3741</link>
		<dc:creator>Alex Kapranoff</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">1833825942#comment-3741</guid>
		<description>&lt;p&gt;"The point of processing data on the client that inevitably needs to come from the server" is that we now can send the data QUICKLY. Most of Google Suggest responses fit into a single IP packet.&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>&#8220;The point of processing data on the client that inevitably needs to come from the server&#8221; is that we now can send the data QUICKLY. Most of Google Suggest responses fit into a single IP packet.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick Schriner</title>
		<link>http://www.sitepoint.com/blogs/2005/03/01/javascript-and-domain-specific-languages/#comment-3742</link>
		<dc:creator>Patrick Schriner</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">1833825942#comment-3742</guid>
		<description>&lt;p&gt;Javascript has an even rarer construct that makes it even better:&lt;br /&gt;
try - catch blocks&lt;br /&gt;
I only found out a couple of weeks ago (allthough I´ve been working with JS for years), as there are allmost no tutorials or samples that use try-catch.&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>Javascript has an even rarer construct that makes it even better:<br />
try - catch blocks<br />
I only found out a couple of weeks ago (allthough I´ve been working with JS for years), as there are allmost no tutorials or samples that use try-catch.</p>]]></content:encoded>
	</item>
</channel>
</rss>
