<?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 Isn&#8217;t Evil</title>
	<atom:link href="http://www.sitepoint.com/blogs/2007/02/23/javascript-isnt-evil/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sitepoint.com/blogs/2007/02/23/javascript-isnt-evil/</link>
	<description>News, opinion, and fresh thinking for web developers and designers. The official podcast of sitepoint.com.</description>
	<pubDate>Thu, 04 Dec 2008 23:58:19 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: AN</title>
		<link>http://www.sitepoint.com/blogs/2007/02/23/javascript-isnt-evil/#comment-187339</link>
		<dc:creator>AN</dc:creator>
		<pubDate>Fri, 23 Feb 2007 17:19:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/23/1857/#comment-187339</guid>
		<description>I can't say I really understand why it is that you think that you get to decide what the web should be and what it shouldn't be.

The reason it's been tough for most of the other technologies you list to get traction is that the vast majority of both users and developers are okay with ajax technologies as a platform for web applications, so few people choose to use separate technologies that are less-widely supported.

Information should be freely available for anyone to access -- this is the premise behind the fight for web standards and accessibility, and it's a good goal. Sites whose purpose is the public access of information should indeed try to make their sites as accessible as possible.

You've already acknowledged that (at least some) web applications are different. But why does that mean they need to go live in the applications ghetto if the existing technologies work for application development? Because you say so?</description>
		<content:encoded><![CDATA[<p>I can&#8217;t say I really understand why it is that you think that you get to decide what the web should be and what it shouldn&#8217;t be.</p>
<p>The reason it&#8217;s been tough for most of the other technologies you list to get traction is that the vast majority of both users and developers are okay with ajax technologies as a platform for web applications, so few people choose to use separate technologies that are less-widely supported.</p>
<p>Information should be freely available for anyone to access &#8212; this is the premise behind the fight for web standards and accessibility, and it&#8217;s a good goal. Sites whose purpose is the public access of information should indeed try to make their sites as accessible as possible.</p>
<p>You&#8217;ve already acknowledged that (at least some) web applications are different. But why does that mean they need to go live in the applications ghetto if the existing technologies work for application development? Because you say so?</p>]]></content:encoded>
	</item>
	<item>
		<title>By: MikeSchinkel</title>
		<link>http://www.sitepoint.com/blogs/2007/02/23/javascript-isnt-evil/#comment-187147</link>
		<dc:creator>MikeSchinkel</dc:creator>
		<pubDate>Fri, 23 Feb 2007 11:37:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/23/1857/#comment-187147</guid>
		<description>momos: Thanks.  My partner wrote the Javascript, I don't even known Javascript that well (I'm a ASP/VBScript/SQL developer learning Python at the moment...)  But I would love it if you could &lt;a href="http://lists.t.oolicio.us/toolicious-discuss/" rel="nofollow"&gt;join our mailing list&lt;/a&gt; and give my partner some more details on how they are not XHTML compliant, as well as any other concerns you might have.</description>
		<content:encoded><![CDATA[<p>momos: Thanks.  My partner wrote the Javascript, I don&#8217;t even known Javascript that well (I&#8217;m a ASP/VBScript/SQL developer learning Python at the moment&#8230;)  But I would love it if you could <a href="http://lists.t.oolicio.us/toolicious-discuss/" rel="nofollow">join our mailing list</a> and give my partner some more details on how they are not XHTML compliant, as well as any other concerns you might have.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: momos</title>
		<link>http://www.sitepoint.com/blogs/2007/02/23/javascript-isnt-evil/#comment-187127</link>
		<dc:creator>momos</dc:creator>
		<pubDate>Fri, 23 Feb 2007 10:45:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/23/1857/#comment-187127</guid>
		<description>Your javascripts for t.oolicio.us are not XHTML compliant yet. (document.write)</description>
		<content:encoded><![CDATA[<p>Your javascripts for t.oolicio.us are not XHTML compliant yet. (document.write)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: MikeSchinkel</title>
		<link>http://www.sitepoint.com/blogs/2007/02/23/javascript-isnt-evil/#comment-187023</link>
		<dc:creator>MikeSchinkel</dc:creator>
		<pubDate>Fri, 23 Feb 2007 06:57:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/23/1857/#comment-187023</guid>
		<description>&#62;&#62; I agree with everything you’ve said, except that I believe it means the “web of applications” is a good idea, not a bad one.

Well I'm glad you agree with part of it. :-)  But I still think a separate space for applictions outside for the web, but launchable by the web, is inherently a bad idea. Just like Tim Berners-Lee makes the point that there needs to be one and only one web (i.e. one DNS and one global namespace), there ideally shouldn't be a set of apps that are not reachable by URL.

BTW, myself (I an in the US) and a parter from the UK have been working on an open-source project whose underlying goals are to foster the creation of infrastructure for significantly improving the web. Mind you it is a lofty goal, but if we don't reach for the stars, we'll certainly never make it. :)  Although it is a bit premature, I have actually been planning to recruit your feedback and recommendations on the project because I believe it will address many of the goals you write so passionately about. I was inspired to reply to this post in general and not because of the project, but since we'd started a dialog I'm going to use the opportunity to ask you to look at it, and ideally, sign up for the mailing list (there is almost no traffic on the list, at the moment.)

But before I point you in the direction of the project, your first impressions will almost certainly mislead you. To understand our demo really requires you to understand our goals, which we've written about somewhat on the site, but we expect once deployed on websites it will look much different than our demo which is just a proof-of-Javascript-concept.

Check it out at &lt;a href="http://t.oolicio.us" rel="nofollow"&gt;http://t.oolicio.us&lt;/a&gt;. If you have questions *please* ask them, and do so either on our mailing list or on our posts.  We *need* questions so we can understand what we need to write an FAQ.

BTW, our Toolicious logo is from a &lt;a href="http://www.sitepoint.com/marketplace/contest/838?" rel="nofollow"&gt;SitePoint contest&lt;/a&gt;. ;-)

P.S. I sure wish your comment system thing had a preview mode...</description>
		<content:encoded><![CDATA[<p>&gt;&gt; I agree with everything you’ve said, except that I believe it means the “web of applications” is a good idea, not a bad one.</p>
<p>Well I&#8217;m glad you agree with part of it. :-)  But I still think a separate space for applictions outside for the web, but launchable by the web, is inherently a bad idea. Just like Tim Berners-Lee makes the point that there needs to be one and only one web (i.e. one DNS and one global namespace), there ideally shouldn&#8217;t be a set of apps that are not reachable by URL.</p>
<p>BTW, myself (I an in the US) and a parter from the UK have been working on an open-source project whose underlying goals are to foster the creation of infrastructure for significantly improving the web. Mind you it is a lofty goal, but if we don&#8217;t reach for the stars, we&#8217;ll certainly never make it. :)  Although it is a bit premature, I have actually been planning to recruit your feedback and recommendations on the project because I believe it will address many of the goals you write so passionately about. I was inspired to reply to this post in general and not because of the project, but since we&#8217;d started a dialog I&#8217;m going to use the opportunity to ask you to look at it, and ideally, sign up for the mailing list (there is almost no traffic on the list, at the moment.)</p>
<p>But before I point you in the direction of the project, your first impressions will almost certainly mislead you. To understand our demo really requires you to understand our goals, which we&#8217;ve written about somewhat on the site, but we expect once deployed on websites it will look much different than our demo which is just a proof-of-Javascript-concept.</p>
<p>Check it out at <a href="http://t.oolicio.us" rel="nofollow">http://t.oolicio.us</a>. If you have questions *please* ask them, and do so either on our mailing list or on our posts.  We *need* questions so we can understand what we need to write an FAQ.</p>
<p>BTW, our Toolicious logo is from a <a href="http://www.sitepoint.com/marketplace/contest/838?" rel="nofollow">SitePoint contest</a>. ;-)</p>
<p>P.S. I sure wish your comment system thing had a preview mode&#8230;</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Yank</title>
		<link>http://www.sitepoint.com/blogs/2007/02/23/javascript-isnt-evil/#comment-186985</link>
		<dc:creator>Kevin Yank</dc:creator>
		<pubDate>Fri, 23 Feb 2007 05:50:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/23/1857/#comment-186985</guid>
		<description>Mike,

I agree with everything you've said, except that I believe it means the "web of applications" is a good idea, not a bad one.

As you say, the web is not architected to support the statefulness that desktop-like applications require. So remove these applications from the Web, and let them run where they belong—on the desktop.

The hard part is making these applications launchable on any Internet-connected desktop (and, over time, other devices) as easily as it is to walk into an Internet café and log into Gmail today.</description>
		<content:encoded><![CDATA[<p>Mike,</p>
<p>I agree with everything you&#8217;ve said, except that I believe it means the &#8220;web of applications&#8221; is a good idea, not a bad one.</p>
<p>As you say, the web is not architected to support the statefulness that desktop-like applications require. So remove these applications from the Web, and let them run where they belong—on the desktop.</p>
<p>The hard part is making these applications launchable on any Internet-connected desktop (and, over time, other devices) as easily as it is to walk into an Internet café and log into Gmail today.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: MikeSchinkel</title>
		<link>http://www.sitepoint.com/blogs/2007/02/23/javascript-isnt-evil/#comment-186969</link>
		<dc:creator>MikeSchinkel</dc:creator>
		<pubDate>Fri, 23 Feb 2007 05:24:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/23/1857/#comment-186969</guid>
		<description>I think this concept of a "Web of Applications” would be really harmful to the web. It is in many ways like the WhizBang visual features Flash offers that completely bastardizes that which makes the web work so well and be so scalable.  Study the &lt;a href="http://wiki.welldesignedurls.org/REST" rel="nofollow"&gt;REST architecture style&lt;/a&gt;, which is essentially a codification of best practices on the web and you'll find the web works best when web sites, and web applications, are architectured as a series of state transfers using a stateless protocol.  This "web of applications" you speak of would require significant client side state and would by its very nature encourage developers to create highly coupled systems that would not scale. 

What's more, these "web of applications", like Flash, would almost certainly encapsulate and make opaque the URLs that identify state, if not eliminate them for some less universal linking mechanism. That would make it impossible for people to use URLs to link to those states, having search engines index those states, having users tag and Digg those states, and so on. In other words, this "web of applications" concept could quickly eliminate this network effect and send us in a direction opposite of all the power unleashed by the web and its RESTful architecture.

In addition Flash, and potentially also this "web of applications" eliminates the "view source effect" which has been one of the strongest drivers for allowing people to learn how to implement things on the web.

&#62;&#62; "So, in the absence of a suitably ubiquitous platform for desktop-like applications, do Ajax-powered desktop-like web applications fall under the umbrella of “Evil JavaScript?” Personally I think they do, but depending on your particular situation, they might be a necessary evil."

I think the real answer is both "Yes" and "No."  People who use AJAX to build "one page applications" (shudder) are at the height of evil. But those who use it for field validation (i.e. is that username been taken yet?) and other UI streamlining functionality are doing good, not evil.

So I think it is incumbent upon people like you to educate web developers *how* to create non-evil AJAX-based web applications. And to me that means respecting the web and it's page metaphor while incorporating functionality that still improves the user interface. 

Though it is difficult to give clear and objective guidelines, we can follow the US Supreme court's approach when defining pornography (they "Know it when they see it!") If the user clicks the back button and doesn't get what he expects, the interface is evil. If the user cannot bookmarket a state that they should reasonably be able to bookmark, then again the use of AJAX is evil. For examples of both these types of evil, go no further than &lt;a href="http://www.hostingrails.com/forums" rel="nofollow"&gt;http://www.hostingrails.com/forums&lt;/a&gt; and try searching for something. While their search interface is "cool", it creates tons of problems. The same *benefits* could have been delivered via a different implementation if they had considered all of the issues I mentioned when they were designing this page.</description>
		<content:encoded><![CDATA[<p>I think this concept of a &#8220;Web of Applications” would be really harmful to the web. It is in many ways like the WhizBang visual features Flash offers that completely bastardizes that which makes the web work so well and be so scalable.  Study the <a href="http://wiki.welldesignedurls.org/REST" rel="nofollow">REST architecture style</a>, which is essentially a codification of best practices on the web and you&#8217;ll find the web works best when web sites, and web applications, are architectured as a series of state transfers using a stateless protocol.  This &#8220;web of applications&#8221; you speak of would require significant client side state and would by its very nature encourage developers to create highly coupled systems that would not scale. </p>
<p>What&#8217;s more, these &#8220;web of applications&#8221;, like Flash, would almost certainly encapsulate and make opaque the URLs that identify state, if not eliminate them for some less universal linking mechanism. That would make it impossible for people to use URLs to link to those states, having search engines index those states, having users tag and Digg those states, and so on. In other words, this &#8220;web of applications&#8221; concept could quickly eliminate this network effect and send us in a direction opposite of all the power unleashed by the web and its RESTful architecture.</p>
<p>In addition Flash, and potentially also this &#8220;web of applications&#8221; eliminates the &#8220;view source effect&#8221; which has been one of the strongest drivers for allowing people to learn how to implement things on the web.</p>
<p>&gt;&gt; &#8220;So, in the absence of a suitably ubiquitous platform for desktop-like applications, do Ajax-powered desktop-like web applications fall under the umbrella of “Evil JavaScript?” Personally I think they do, but depending on your particular situation, they might be a necessary evil.&#8221;</p>
<p>I think the real answer is both &#8220;Yes&#8221; and &#8220;No.&#8221;  People who use AJAX to build &#8220;one page applications&#8221; (shudder) are at the height of evil. But those who use it for field validation (i.e. is that username been taken yet?) and other UI streamlining functionality are doing good, not evil.</p>
<p>So I think it is incumbent upon people like you to educate web developers *how* to create non-evil AJAX-based web applications. And to me that means respecting the web and it&#8217;s page metaphor while incorporating functionality that still improves the user interface. </p>
<p>Though it is difficult to give clear and objective guidelines, we can follow the US Supreme court&#8217;s approach when defining pornography (they &#8220;Know it when they see it!&#8221;) If the user clicks the back button and doesn&#8217;t get what he expects, the interface is evil. If the user cannot bookmarket a state that they should reasonably be able to bookmark, then again the use of AJAX is evil. For examples of both these types of evil, go no further than <a href="http://www.hostingrails.com/forums" rel="nofollow">http://www.hostingrails.com/forums</a> and try searching for something. While their search interface is &#8220;cool&#8221;, it creates tons of problems. The same *benefits* could have been delivered via a different implementation if they had considered all of the issues I mentioned when they were designing this page.</p>]]></content:encoded>
	</item>
</channel>
</rss>
