<?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: The problem with JavaScript frameworks</title>
	<atom:link href="http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/</link>
	<description>designs stuff and writes code.</description>
	<lastBuildDate>Tue, 27 Jul 2010 16:02:00 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Henrik Vendelbo</title>
		<link>http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/comment-page-1/#comment-3508</link>
		<dc:creator>Henrik Vendelbo</dc:creator>
		<pubDate>Wed, 28 Jun 2006 10:42:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/#comment-3508</guid>
		<description>I think you have been getting too used to having everything you need built in. That situation is no different to any serverside platform out there.
AJAX/DHTML is growing wildly now. Once people run out of crucial features to implement, they will start to discuss how to standardise  the APIs, making them more similar.
Just count yourself lucky that JavaScript libraries never can become truely bloated or the download overhead will unacceptable. Unlike most other programming environments that are approaching three digit megabyte sizes.</description>
		<content:encoded><![CDATA[<p>I think you have been getting too used to having everything you need built in. That situation is no different to any serverside platform out there.<br />
AJAX/DHTML is growing wildly now. Once people run out of crucial features to implement, they will start to discuss how to standardise  the APIs, making them more similar.<br />
Just count yourself lucky that JavaScript libraries never can become truely bloated or the download overhead will unacceptable. Unlike most other programming environments that are approaching three digit megabyte sizes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brenden</title>
		<link>http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/comment-page-1/#comment-3341</link>
		<dc:creator>Brenden</dc:creator>
		<pubDate>Sat, 24 Jun 2006 19:01:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/#comment-3341</guid>
		<description>I agree with what Matthew wrote. Imagine a group of math students all using different brands of calculators. If they only think in terms of the buttons they press, they won&#039;t be able to share and compare work with eachother. However, if they understand the mathematical principles behind what the calculator is doing, what brand of calculator they use shouldn&#039;t be much of an issue. The same idea could be applied to javascript frameworks.</description>
		<content:encoded><![CDATA[<p>I agree with what Matthew wrote. Imagine a group of math students all using different brands of calculators. If they only think in terms of the buttons they press, they won&#8217;t be able to share and compare work with eachother. However, if they understand the mathematical principles behind what the calculator is doing, what brand of calculator they use shouldn&#8217;t be much of an issue. The same idea could be applied to javascript frameworks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Elliot Swan</title>
		<link>http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/comment-page-1/#comment-3340</link>
		<dc:creator>Elliot Swan</dc:creator>
		<pubDate>Sat, 24 Jun 2006 18:42:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/#comment-3340</guid>
		<description>Some standard calls would be nice, or perhaps some sort of converter that can convert as much code as possible, then somebody else would have to do the rest.</description>
		<content:encoded><![CDATA[<p>Some standard calls would be nice, or perhaps some sort of converter that can convert as much code as possible, then somebody else would have to do the rest.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matthew Pennell</title>
		<link>http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/comment-page-1/#comment-3319</link>
		<dc:creator>Matthew Pennell</dc:creator>
		<pubDate>Sat, 24 Jun 2006 06:28:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/#comment-3319</guid>
		<description>A point that was made in the @media Javascript Libraries panel (and one I happen to agree with) is that unless you understand what the Javascript in the libraries is doing, you have no business using a library.

The function of a library should be to make your development work quicker and easier, not to provide an easy shortcut to actually learning anything.

With that point in mind, any serious Javascripter should be able to translate an example posted using YAHOO or Dojo or jQuery or Prototype or whatever into their own chosen library.

That said, it would be nice if common API calls became standardised across libraries, so that you could be pretty confident that Ajax.send (for example) will work regardless of the library.</description>
		<content:encoded><![CDATA[<p>A point that was made in the @media Javascript Libraries panel (and one I happen to agree with) is that unless you understand what the Javascript in the libraries is doing, you have no business using a library.</p>
<p>The function of a library should be to make your development work quicker and easier, not to provide an easy shortcut to actually learning anything.</p>
<p>With that point in mind, any serious Javascripter should be able to translate an example posted using YAHOO or Dojo or jQuery or Prototype or whatever into their own chosen library.</p>
<p>That said, it would be nice if common API calls became standardised across libraries, so that you could be pretty confident that Ajax.send (for example) will work regardless of the library.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Elliot Swan</title>
		<link>http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/comment-page-1/#comment-3314</link>
		<dc:creator>Elliot Swan</dc:creator>
		<pubDate>Sat, 24 Jun 2006 04:38:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/#comment-3314</guid>
		<description>You&#039;ve got a good point there as well, one I never thought of. Those who haven&#039;t used any frameworks are also going to have a tough time--probably tougher.</description>
		<content:encoded><![CDATA[<p>You&#8217;ve got a good point there as well, one I never thought of. Those who haven&#8217;t used any frameworks are also going to have a tough time&#8211;probably tougher.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AdamD</title>
		<link>http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/comment-page-1/#comment-3305</link>
		<dc:creator>AdamD</dc:creator>
		<pubDate>Sat, 24 Jun 2006 03:18:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.elliotswan.com/2006/06/23/the-problem-with-javascript-frameworks/#comment-3305</guid>
		<description>Wow. A problem I hadn&#039;t even considered. Maybe that&#039;s because Javascript frameworks sort of came out of nowhere to me. Whenever I add any Javascript to something, I&#039;m still doing it the old fashioned way, in plain ol&#039;, framework-free Javascript.

Yeah, I&#039;m behind the times: I just got rid of the outhouse last year!

Seriously, that makes what Elliot has to say all the more important. Someone using no framework is just as in the dark as someone who is using a different framework from an example.

So, I think the &quot;ambidextrous&quot; coders will give multiple examples and others will only give the example they know. And I think that&#039;s fine. ASP.NET has done a-okay, with some people using VB.NET and others C#.

If I really want to do what a tutorial explains, I&#039;ll use my brain and translate the concepts to the technology I know. Otherwise, I&#039;ll move on to the next how-to that speaks to my Byzantine ways. I mean, who does Javascript without a framework these days? I&#039;m so incredibly out-dated... at 27.</description>
		<content:encoded><![CDATA[<p>Wow. A problem I hadn&#8217;t even considered. Maybe that&#8217;s because Javascript frameworks sort of came out of nowhere to me. Whenever I add any Javascript to something, I&#8217;m still doing it the old fashioned way, in plain ol&#8217;, framework-free Javascript.</p>
<p>Yeah, I&#8217;m behind the times: I just got rid of the outhouse last year!</p>
<p>Seriously, that makes what Elliot has to say all the more important. Someone using no framework is just as in the dark as someone who is using a different framework from an example.</p>
<p>So, I think the &#8220;ambidextrous&#8221; coders will give multiple examples and others will only give the example they know. And I think that&#8217;s fine. ASP.NET has done a-okay, with some people using VB.NET and others C#.</p>
<p>If I really want to do what a tutorial explains, I&#8217;ll use my brain and translate the concepts to the technology I know. Otherwise, I&#8217;ll move on to the next how-to that speaks to my Byzantine ways. I mean, who does Javascript without a framework these days? I&#8217;m so incredibly out-dated&#8230; at 27.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
