<?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: Clipperz review</title>
	<atom:link href="http://goesping.org/archives/2008/07/22/clipperz-review/feed/" rel="self" type="application/rss+xml" />
	<link>http://goesping.org/archives/2008/07/22/clipperz-review/</link>
	<description>Pinging stuff I care about.</description>
	<pubDate>Thu, 08 Jan 2009 09:44:05 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Tara Kelly</title>
		<link>http://goesping.org/archives/2008/07/22/clipperz-review/comment-page-1/#comment-17843</link>
		<dc:creator>Tara Kelly</dc:creator>
		<pubDate>Sat, 26 Jul 2008 14:56:42 +0000</pubDate>
		<guid isPermaLink="false">http://goesping.org/archives/2008/07/22/clipperz-review/#comment-17843</guid>
		<description>@Joel
That's fascinating. I'm not the JS developer on the team, so my knowledge probably spottier than anyone else's. I know there were some experiments (since abandoned) going on here with Jaxer which takes another approach altogether by running a JS directly on the server. I'll ask around and see if anyone has tried playing with SproutCore yet.

As for HTML5, yes, the client-side storage is promising, though not fully supported yet. But I think you can get most of the browser/OS combination covered by combining both native HTML5 support and Google Gears.

Thanks for the info! I'll look into it.</description>
		<content:encoded><![CDATA[<p>@Joel<br />
That&#8217;s fascinating. I&#8217;m not the JS developer on the team, so my knowledge probably spottier than anyone else&#8217;s. I know there were some experiments (since abandoned) going on here with Jaxer which takes another approach altogether by running a JS directly on the server. I&#8217;ll ask around and see if anyone has tried playing with SproutCore yet.</p>
<p>As for HTML5, yes, the client-side storage is promising, though not fully supported yet. But I think you can get most of the browser/OS combination covered by combining both native HTML5 support and Google Gears.</p>
<p>Thanks for the info! I&#8217;ll look into it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: joel boonstra</title>
		<link>http://goesping.org/archives/2008/07/22/clipperz-review/comment-page-1/#comment-17834</link>
		<dc:creator>joel boonstra</dc:creator>
		<pubDate>Thu, 24 Jul 2008 13:49:48 +0000</pubDate>
		<guid isPermaLink="false">http://goesping.org/archives/2008/07/22/clipperz-review/#comment-17834</guid>
		<description>@Ed, if you don't want this thread to become a giant javascript framework discussion, just let me know and we can I'm sure take our conversation offline.

@Tara, no, it's aimed at a different development model.  jQuery and Prototype and their ilk try to smooth out browser inconsistencies in event handling, provide cross-browser AJAX capabilities, and allow for quickly adding behavior that would be complex to create by hand.  Prototype also infests (I say that in a non-pejorative way) the Javascript language with added functionality, providing new, Ruby-like syntax.

Those JS frameworks also tend to provide widgets for interaction that are not provided by stock (X)HTML, like accordion controls, sliders, combo boxes, etc.  However, they all still rely on the server for most of the heavy-lifting for data storage, business logic, and forth; they add the UI shine to something that could (or should?), in theory, function without JS enabled.

SproutCore, OTOH, is an application development framework along the lines of Rails, Symfony, CakePHP, etc., except that it's implemented in Javascript.  It uses Ruby to generate code during development, but when you "deploy" you're actually sending just XHTML and Javascript to the server to be run.  If a user cannot run Javascript, then there is no possible way they could use a SproutCore-run website (by design).

I don't fully understand all that it does, but I've seen references to SproutCore doing data storage entirely client-side, using some new features of HTML5.  You can, of course, communicate with a backend server, but I get the impression that you use largely RESTful URLs to sync data with from the client back to the server.

My knowledge of the specific implementation of SproutCore is fairly spotty and shouldn't be relied upon, but I think the difference is that SproutCore enables entirely in-browser applications like http://280slides.com/ (though I think that site uses a similar-in-concept project called Objective-J), where as thin frameworks like jQuery (I love jQuery, btw) focus on enhancing and easing Javascript authoring without providing a full-fledged development environment.</description>
		<content:encoded><![CDATA[<p>@Ed, if you don&#8217;t want this thread to become a giant javascript framework discussion, just let me know and we can I&#8217;m sure take our conversation offline.</p>
<p>@Tara, no, it&#8217;s aimed at a different development model.  jQuery and Prototype and their ilk try to smooth out browser inconsistencies in event handling, provide cross-browser AJAX capabilities, and allow for quickly adding behavior that would be complex to create by hand.  Prototype also infests (I say that in a non-pejorative way) the Javascript language with added functionality, providing new, Ruby-like syntax.</p>
<p>Those JS frameworks also tend to provide widgets for interaction that are not provided by stock (X)HTML, like accordion controls, sliders, combo boxes, etc.  However, they all still rely on the server for most of the heavy-lifting for data storage, business logic, and forth; they add the UI shine to something that could (or should?), in theory, function without JS enabled.</p>
<p>SproutCore, OTOH, is an application development framework along the lines of Rails, Symfony, CakePHP, etc., except that it&#8217;s implemented in Javascript.  It uses Ruby to generate code during development, but when you &#8220;deploy&#8221; you&#8217;re actually sending just XHTML and Javascript to the server to be run.  If a user cannot run Javascript, then there is no possible way they could use a SproutCore-run website (by design).</p>
<p>I don&#8217;t fully understand all that it does, but I&#8217;ve seen references to SproutCore doing data storage entirely client-side, using some new features of HTML5.  You can, of course, communicate with a backend server, but I get the impression that you use largely RESTful URLs to sync data with from the client back to the server.</p>
<p>My knowledge of the specific implementation of SproutCore is fairly spotty and shouldn&#8217;t be relied upon, but I think the difference is that SproutCore enables entirely in-browser applications like <a href="http://280slides.com/" rel="nofollow">http://280slides.com/</a> (though I think that site uses a similar-in-concept project called Objective-J), where as thin frameworks like jQuery (I love jQuery, btw) focus on enhancing and easing Javascript authoring without providing a full-fledged development environment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tara Kelly</title>
		<link>http://goesping.org/archives/2008/07/22/clipperz-review/comment-page-1/#comment-17833</link>
		<dc:creator>Tara Kelly</dc:creator>
		<pubDate>Thu, 24 Jul 2008 11:46:26 +0000</pubDate>
		<guid isPermaLink="false">http://goesping.org/archives/2008/07/22/clipperz-review/#comment-17833</guid>
		<description>Thank you Ed. :)

@Joel, sproutcore looks cool. Would you say that it is a competitor for JQuery and other js frameworks? Or is it something more than that?</description>
		<content:encoded><![CDATA[<p>Thank you Ed. :)</p>
<p>@Joel, sproutcore looks cool. Would you say that it is a competitor for JQuery and other js frameworks? Or is it something more than that?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ed Heil</title>
		<link>http://goesping.org/archives/2008/07/22/clipperz-review/comment-page-1/#comment-17824</link>
		<dc:creator>Ed Heil</dc:creator>
		<pubDate>Wed, 23 Jul 2008 15:32:12 +0000</pubDate>
		<guid isPermaLink="false">http://goesping.org/archives/2008/07/22/clipperz-review/#comment-17824</guid>
		<description>Thanks, I will check it out!</description>
		<content:encoded><![CDATA[<p>Thanks, I will check it out!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: joel boonstra</title>
		<link>http://goesping.org/archives/2008/07/22/clipperz-review/comment-page-1/#comment-17823</link>
		<dc:creator>joel boonstra</dc:creator>
		<pubDate>Wed, 23 Jul 2008 15:27:34 +0000</pubDate>
		<guid isPermaLink="false">http://goesping.org/archives/2008/07/22/clipperz-review/#comment-17823</guid>
		<description>Tangentially related: check out &lt;a href="http://www.sproutcore.com/" rel="nofollow"&gt;sproutcore.com&lt;/a&gt; for a "thick-client" javascript application framework that does most stuff in-browser.  It's apparently what's powering Apple's new MobileMe, and looks pretty neat, both from a nifty UI perspective and a shift in application design perspective.</description>
		<content:encoded><![CDATA[<p>Tangentially related: check out <a href="http://www.sproutcore.com/" rel="nofollow">sproutcore.com</a> for a &#8220;thick-client&#8221; javascript application framework that does most stuff in-browser.  It&#8217;s apparently what&#8217;s powering Apple&#8217;s new MobileMe, and looks pretty neat, both from a nifty UI perspective and a shift in application design perspective.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
