<?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: jQuery plugins: Who needs &#8216;em?</title>
	<atom:link href="http://www.pathf.com/blogs/2008/06/jquery-plugins-who-needs-em/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pathf.com/blogs/2008/06/jquery-plugins-who-needs-em/</link>
	<description>Running commentary about agile development, user experience design and Ajax.</description>
	<pubDate>Fri, 05 Dec 2008 07:50:59 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Pathfinder Development &#187; jQuery plugins: Five tips for separating the good from the bad and the ugly</title>
		<link>http://www.pathf.com/blogs/2008/06/jquery-plugins-who-needs-em/#comment-2567</link>
		<dc:creator>Pathfinder Development &#187; jQuery plugins: Five tips for separating the good from the bad and the ugly</dc:creator>
		<pubDate>Mon, 21 Jul 2008 21:41:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=975#comment-2567</guid>
		<description>[...] opined recently that jQuery plugins can be more trouble than they're worth. That said, they're often indispensable. True, the worst plugins suffer from bloated code, [...]</description>
		<content:encoded><![CDATA[<p>[...] opined recently that jQuery plugins can be more trouble than they&#8217;re worth. That said, they&#8217;re often indispensable. True, the worst plugins suffer from bloated code, [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason Huck</title>
		<link>http://www.pathf.com/blogs/2008/06/jquery-plugins-who-needs-em/#comment-2134</link>
		<dc:creator>Jason Huck</dc:creator>
		<pubDate>Fri, 20 Jun 2008 11:24:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=975#comment-2134</guid>
		<description>I agree with the sentiment, and often make the same decision, but I think it comes down to being able to assess how useful a given plugin really is for a given situation, and properly budgeting your time to make that assessment.

As we're developing, if we identify a need so general in nature that we suspect a plugin might have already been written to meet it, of course we'll look, and more often than not, we'll find at least one, if not more, options available. 

It's easy enough to try them out, and if they don't meet our exact needs, it's usually just as easy to determine whether it would be faster/simpler to tweak the plugin or write our own solution. I certainly appreciate having the choice, as well as the opportunity to contribute alternative solutions to the community from time to time.

Scan through the plugin code, identify places where the modifications you need might be applied, and take a quick stab at it. The key is giving yourself a limited amount of time to patch the plugin (admittedly hard to do sometimes once you get into problem-solving mode) before dropping it in favor of a different solution. After all, if it's not saving you time, what's the point?</description>
		<content:encoded><![CDATA[<p>I agree with the sentiment, and often make the same decision, but I think it comes down to being able to assess how useful a given plugin really is for a given situation, and properly budgeting your time to make that assessment.</p>
<p>As we&#8217;re developing, if we identify a need so general in nature that we suspect a plugin might have already been written to meet it, of course we&#8217;ll look, and more often than not, we&#8217;ll find at least one, if not more, options available. </p>
<p>It&#8217;s easy enough to try them out, and if they don&#8217;t meet our exact needs, it&#8217;s usually just as easy to determine whether it would be faster/simpler to tweak the plugin or write our own solution. I certainly appreciate having the choice, as well as the opportunity to contribute alternative solutions to the community from time to time.</p>
<p>Scan through the plugin code, identify places where the modifications you need might be applied, and take a quick stab at it. The key is giving yourself a limited amount of time to patch the plugin (admittedly hard to do sometimes once you get into problem-solving mode) before dropping it in favor of a different solution. After all, if it&#8217;s not saving you time, what&#8217;s the point?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason Wehmhoener</title>
		<link>http://www.pathf.com/blogs/2008/06/jquery-plugins-who-needs-em/#comment-2123</link>
		<dc:creator>Jason Wehmhoener</dc:creator>
		<pubDate>Fri, 20 Jun 2008 00:22:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=975#comment-2123</guid>
		<description>I completely agree. I feel this also applies to other libraries that have a "core" and then multiple layers on top. In YUI I use yahoo-dom-event, and the rest I do myself. I know those three libraries are rock solid, and they do exactly what I want a JavaScript library to do: abstract away the browser differences. The rest is just plain old JavaScript, which is exactly how I want it.</description>
		<content:encoded><![CDATA[<p>I completely agree. I feel this also applies to other libraries that have a &#8220;core&#8221; and then multiple layers on top. In YUI I use yahoo-dom-event, and the rest I do myself. I know those three libraries are rock solid, and they do exactly what I want a JavaScript library to do: abstract away the browser differences. The rest is just plain old JavaScript, which is exactly how I want it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jörn Zaefferer</title>
		<link>http://www.pathf.com/blogs/2008/06/jquery-plugins-who-needs-em/#comment-2120</link>
		<dc:creator>Jörn Zaefferer</dc:creator>
		<pubDate>Thu, 19 Jun 2008 20:34:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=975#comment-2120</guid>
		<description>If nothing else, you can use plugins to reuse your own code. And borrow from anyone else to learn how to do that properly. I think that alone makes plugins already worthwhile.

Anyway, you hit a good spot. Most plugins do a lot, but not what you actually need. Mails like "yeah, great plugin, but..." are the standard for most plugin author.

So the really hard problem is to find the right abstraction, like jQuery did: Identify a problem, and provide an abstraction that adapts to all variations of that problem.

The plugins I consider really good abstractions are those low-level components in jQuery UI, and my validation plugin. Both abstractions adapt to a lot of variations, though surely not all of them.

What plugins did you find worthwhile?</description>
		<content:encoded><![CDATA[<p>If nothing else, you can use plugins to reuse your own code. And borrow from anyone else to learn how to do that properly. I think that alone makes plugins already worthwhile.</p>
<p>Anyway, you hit a good spot. Most plugins do a lot, but not what you actually need. Mails like &#8220;yeah, great plugin, but&#8230;&#8221; are the standard for most plugin author.</p>
<p>So the really hard problem is to find the right abstraction, like jQuery did: Identify a problem, and provide an abstraction that adapts to all variations of that problem.</p>
<p>The plugins I consider really good abstractions are those low-level components in jQuery UI, and my validation plugin. Both abstractions adapt to a lot of variations, though surely not all of them.</p>
<p>What plugins did you find worthwhile?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: T.J.</title>
		<link>http://www.pathf.com/blogs/2008/06/jquery-plugins-who-needs-em/#comment-2116</link>
		<dc:creator>T.J.</dc:creator>
		<pubDate>Thu, 19 Jun 2008 14:56:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=975#comment-2116</guid>
		<description>I'm a mootools user myself, but the plugin system is essentially identical.  I've often attempted to "customize" some plugins to fit my needs, but then realize (after spending too much time learning the code) that I might as well write my own that accomplishes what I need it to from the get-go.  Not only do you learn from the experience (everyone loves finding more IE6 quirks), but later down the road when you get that flash of inspiration you can jump right into the code without having to learn any logic.  In fact, I can only think of one plugin that I was ok using "out of the box", and that was using &lt;a href="http://www.digitalia.be/software/slimbox" rel="nofollow"&gt;Slimbox&lt;/a&gt; for image links on product pages.

The only plugin that I think would be a real pain to code yourself would be a WYSIWYG editor.  I spent a week just back-porting &lt;a href="http://code.google.com/p/mooeditable/" rel="nofollow"&gt;MooEditable&lt;/a&gt; to be &lt;a href="http://code.google.com/p/mooeditable/source/browse/trunk/mootools-1.11/MooEditable-1.11.js" rel="nofollow"&gt;compatible with mootools 1.11&lt;/a&gt; (admittedly I also spent some that time adding extra regular expression parsing to make the html output w3c valid and identical across browsers).</description>
		<content:encoded><![CDATA[<p>I&#8217;m a mootools user myself, but the plugin system is essentially identical.  I&#8217;ve often attempted to &#8220;customize&#8221; some plugins to fit my needs, but then realize (after spending too much time learning the code) that I might as well write my own that accomplishes what I need it to from the get-go.  Not only do you learn from the experience (everyone loves finding more IE6 quirks), but later down the road when you get that flash of inspiration you can jump right into the code without having to learn any logic.  In fact, I can only think of one plugin that I was ok using &#8220;out of the box&#8221;, and that was using <a href="http://www.digitalia.be/software/slimbox" rel="nofollow">Slimbox</a> for image links on product pages.</p>
<p>The only plugin that I think would be a real pain to code yourself would be a WYSIWYG editor.  I spent a week just back-porting <a href="http://code.google.com/p/mooeditable/" rel="nofollow">MooEditable</a> to be <a href="http://code.google.com/p/mooeditable/source/browse/trunk/mootools-1.11/MooEditable-1.11.js" rel="nofollow">compatible with mootools 1.11</a> (admittedly I also spent some that time adding extra regular expression parsing to make the html output w3c valid and identical across browsers).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
