<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments for DanNorth.net</title>
	<atom:link href="http://dannorth.net/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://dannorth.net</link>
	<description>embracing uncertainty</description>
	<lastBuildDate>Thu, 02 Feb 2012 20:47:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>Comment on The rise and rise of JavaScript by planetgeek.ch &#187; The Future smells like JavaScript</title>
		<link>http://dannorth.net/2011/12/19/the-rise-and-rise-of-javascript/#comment-10077</link>
		<dc:creator><![CDATA[planetgeek.ch &#187; The Future smells like JavaScript]]></dc:creator>
		<pubDate>Thu, 02 Feb 2012 20:47:07 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/?p=650#comment-10077</guid>
		<description><![CDATA[[...] Of course I am only repeating what others are preaching about the recent rise of JavaScript. [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Of course I am only repeating what others are preaching about the recent rise of JavaScript. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The perils of estimation by Liz Keogh&#039;s blog &#187; The Real Cost of Change</title>
		<link>http://dannorth.net/2009/07/01/the-perils-of-estimation/#comment-10064</link>
		<dc:creator><![CDATA[Liz Keogh&#039;s blog &#187; The Real Cost of Change]]></dc:creator>
		<pubDate>Mon, 30 Jan 2012 19:27:09 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/?p=117#comment-10064</guid>
		<description><![CDATA[[...] isn&#8217;t helped by common practices of estimation and the associated promises, which often lead to that pressure building up in the first place. Rather than making these [...]]]></description>
		<content:encoded><![CDATA[<p>[...] isn&#8217;t helped by common practices of estimation and the associated promises, which often lead to that pressure building up in the first place. Rather than making these [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Introducing Deliberate Discovery by Liz Keogh&#039;s blog &#187; The Real Cost of Change</title>
		<link>http://dannorth.net/2010/08/30/introducing-deliberate-discovery/#comment-10063</link>
		<dc:creator><![CDATA[Liz Keogh&#039;s blog &#187; The Real Cost of Change]]></dc:creator>
		<pubDate>Mon, 30 Jan 2012 12:37:59 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dannorth.net/?p=431#comment-10063</guid>
		<description><![CDATA[[...] Dan North wrote an excellent post on Deliberate Discovery, and I&#8217;ve been using it to manage risk on my projects for a while now. It&#8217;s one of the most important tools in my toolbox, along with Real Options to which it&#8217;s strongly related, so I want to cover how I use it here. [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Dan North wrote an excellent post on Deliberate Discovery, and I&#8217;ve been using it to manage risk on my projects for a while now. It&#8217;s one of the most important tools in my toolbox, along with Real Options to which it&#8217;s strongly related, so I want to cover how I use it here. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on On craftsmanship by Liz Keogh&#039;s blog &#187; The Real Cost of Change</title>
		<link>http://dannorth.net/2011/01/15/on-craftsmanship/#comment-10062</link>
		<dc:creator><![CDATA[Liz Keogh&#039;s blog &#187; The Real Cost of Change]]></dc:creator>
		<pubDate>Mon, 30 Jan 2012 12:37:50 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/?p=572#comment-10062</guid>
		<description><![CDATA[[...] with hard-coded data behind them, designed to get some feedback about techology or requirements. Dan North, who gave me the term, might write more about this later if we ask nicely, but for this post, we can simply bear in mind [...]]]></description>
		<content:encoded><![CDATA[<p>[...] with hard-coded data behind them, designed to get some feedback about techology or requirements. Dan North, who gave me the term, might write more about this later if we ask nicely, but for this post, we can simply bear in mind [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The rise and rise of JavaScript by Tim Stokes</title>
		<link>http://dannorth.net/2011/12/19/the-rise-and-rise-of-javascript/#comment-10054</link>
		<dc:creator><![CDATA[Tim Stokes]]></dc:creator>
		<pubDate>Fri, 27 Jan 2012 17:29:50 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/?p=650#comment-10054</guid>
		<description><![CDATA[Dan, 

What about more conventional web sites with larger pages sizes using tempting? From my own tests, it seems that, even if an API call to get data is asynchronous, the parsing of the data and rendering of the template is still enough work to dramatically affect throughput.

Yes I understand that work can be passed to handed off to another thread but then how much are you gaining for having to programatically manage threads? From my tests, in this scenario, it&#039;s dramatically faster to use even 10+ year old JSPs with a reasonable size thread pool and let the OS and Processor balance the workload. Throw into the mix some non-blocking IO with Netty and some Actor pattern to instruct the workers threadpool and it leaves Node.js in the dust.

Can&#039;t argue against people just wanting to use JavaScript only.

Sorry to bust your chops but seriously...
When would you not use Node.js?

Tim]]></description>
		<content:encoded><![CDATA[<p>Dan, </p>
<p>What about more conventional web sites with larger pages sizes using tempting? From my own tests, it seems that, even if an API call to get data is asynchronous, the parsing of the data and rendering of the template is still enough work to dramatically affect throughput.</p>
<p>Yes I understand that work can be passed to handed off to another thread but then how much are you gaining for having to programatically manage threads? From my tests, in this scenario, it&#8217;s dramatically faster to use even 10+ year old JSPs with a reasonable size thread pool and let the OS and Processor balance the workload. Throw into the mix some non-blocking IO with Netty and some Actor pattern to instruct the workers threadpool and it leaves Node.js in the dust.</p>
<p>Can&#8217;t argue against people just wanting to use JavaScript only.</p>
<p>Sorry to bust your chops but seriously&#8230;<br />
When would you not use Node.js?</p>
<p>Tim</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The rise and rise of JavaScript by Sergio Kas</title>
		<link>http://dannorth.net/2011/12/19/the-rise-and-rise-of-javascript/#comment-10017</link>
		<dc:creator><![CDATA[Sergio Kas]]></dc:creator>
		<pubDate>Fri, 13 Jan 2012 03:01:30 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/?p=650#comment-10017</guid>
		<description><![CDATA[And don&#039;t forget underscore.string (http://epeli.github.com/underscore.string/) which addresses one of the missing JavaScript features that I miss the most: proper string manipulation.]]></description>
		<content:encoded><![CDATA[<p>And don&#8217;t forget underscore.string (<a href="http://epeli.github.com/underscore.string/" rel="nofollow">http://epeli.github.com/underscore.string/</a>) which addresses one of the missing JavaScript features that I miss the most: proper string manipulation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The rise and rise of JavaScript by Göran Krampe</title>
		<link>http://dannorth.net/2011/12/19/the-rise-and-rise-of-javascript/#comment-10012</link>
		<dc:creator><![CDATA[Göran Krampe]]></dc:creator>
		<pubDate>Thu, 12 Jan 2012 09:18:10 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/?p=650#comment-10012</guid>
		<description><![CDATA[Nice article indeed. Since it is so popular these days with languages compiling to js I thought I should mention Amber:

http://www.amber-lang.net

It not only compiles to js and is a full Smalltalk, it also has an IDE running directly in the browser which is what makes it unique I think. And interacting with js and js libraries is very transparent. And it also has a command line compiler so you can easily use it to build node apps etc, examples are in the git clone. If you find it interesting, do show up on #amber-lang at freenode.

cheers, Göran]]></description>
		<content:encoded><![CDATA[<p>Nice article indeed. Since it is so popular these days with languages compiling to js I thought I should mention Amber:</p>
<p><a href="http://www.amber-lang.net" rel="nofollow">http://www.amber-lang.net</a></p>
<p>It not only compiles to js and is a full Smalltalk, it also has an IDE running directly in the browser which is what makes it unique I think. And interacting with js and js libraries is very transparent. And it also has a command line compiler so you can easily use it to build node apps etc, examples are in the git clone. If you find it interesting, do show up on #amber-lang at freenode.</p>
<p>cheers, Göran</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The rise and rise of JavaScript by Paul Batum (@paulbatum)</title>
		<link>http://dannorth.net/2011/12/19/the-rise-and-rise-of-javascript/#comment-9996</link>
		<dc:creator><![CDATA[Paul Batum (@paulbatum)]]></dc:creator>
		<pubDate>Tue, 10 Jan 2012 01:59:06 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/?p=650#comment-9996</guid>
		<description><![CDATA[Its still a mischaracterization. C# has had anonymous functions (delegates) with true closures since C# 2. The syntax got nicer in C# 3 and as Rob G pointed out above it gets even nicer again (even nicer than JavaScript, I&#039;d argue) for async operations in C# 5. 

I&#039;m a JavaScript fan and plenty of your other points are valid, but it is just incorrect to state that C# is at some degree of uselessness when it comes to closures and working with async operations.]]></description>
		<content:encoded><![CDATA[<p>Its still a mischaracterization. C# has had anonymous functions (delegates) with true closures since C# 2. The syntax got nicer in C# 3 and as Rob G pointed out above it gets even nicer again (even nicer than JavaScript, I&#8217;d argue) for async operations in C# 5. </p>
<p>I&#8217;m a JavaScript fan and plenty of your other points are valid, but it is just incorrect to state that C# is at some degree of uselessness when it comes to closures and working with async operations.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The rise and rise of JavaScript by HTML5 Game Development &#187; News Archive &#187; The rise and rise of JavaScript</title>
		<link>http://dannorth.net/2011/12/19/the-rise-and-rise-of-javascript/#comment-9960</link>
		<dc:creator><![CDATA[HTML5 Game Development &#187; News Archive &#187; The rise and rise of JavaScript]]></dc:creator>
		<pubDate>Wed, 04 Jan 2012 12:41:51 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/?p=650#comment-9960</guid>
		<description><![CDATA[[...] http://dannorth.net/2011/12/19/the-rise-and-rise-of-javascript/ ShareFacebookRedditDiggStumbleUponPrintEmail [...]]]></description>
		<content:encoded><![CDATA[<p>[...] <a href="http://dannorth.net/2011/12/19/the-rise-and-rise-of-javascript/" rel="nofollow">http://dannorth.net/2011/12/19/the-rise-and-rise-of-javascript/</a> ShareFacebookRedditDiggStumbleUponPrintEmail [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The rise and rise of JavaScript by Rodrigo Rosenfeld Rosaso</title>
		<link>http://dannorth.net/2011/12/19/the-rise-and-rise-of-javascript/#comment-9956</link>
		<dc:creator><![CDATA[Rodrigo Rosenfeld Rosaso]]></dc:creator>
		<pubDate>Tue, 03 Jan 2012 16:09:42 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/?p=650#comment-9956</guid>
		<description><![CDATA[I also find OO programming to be more maintainable, and this is one more reason for me to adopt CoffeeScript. It provides a common syntax for OOP so that you wouldn&#039;t be fighting with other developers to decide what is the best way of implementing OOP in JS...]]></description>
		<content:encoded><![CDATA[<p>I also find OO programming to be more maintainable, and this is one more reason for me to adopt CoffeeScript. It provides a common syntax for OOP so that you wouldn&#8217;t be fighting with other developers to decide what is the best way of implementing OOP in JS&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
