The amount of plugin and general lack of quality control over them is also something that bothers me. I wish there was a little more control over what plugins get published - although I know that is a silly statement since it's OS and well, anyone can publish anything. I know I'm a bit misguided so I'm anticipating some clarification from Bango or someone here - but if a plugin is on the 'official' jQuery site, it should have a little more QA done on it to make sure it's "up to par" for mass release.

I'd also like to see 'required version' of jQuery listed with the plugin. I was using one just the other day and it wasn't working - so on a hunch I upgraded to jQuery 1.latest and it worked. Maybe there needs to be a site like RIAForge for the plugins. It doesn't need to be quite as elaborate as RIAForge, but something that allows for forums and a place to submit enhancements/bug reports for the plugins. For example, I really like the half star rating plugin, but it would be really nice to have a way to enhance it to 'freeze' the rating once it's been submitted. It would also be nice to pass a callback function in so that action can be taken once the rating is complete (which I modded the plugin myself to do).

Sorry for rambling here - and please understand, I'm not knocking jQuery. I'm with Ray, I really like what I've seen so far. All of this may already exist - but my limited experience hasn't led me to find it yet.

jQuery is just pure awesome *without* any plugins :) If you want to do DOM manipulation, jQuery is your tool. It's hard to believe the dozens of lines code we used to write to just select a few nodes, loop over them and change them can now sometimes be done in 1 to 3 lines of code. Awesome.

BTW, the plugins site does have recommended versions for most plugins: http://plugins.jquery.com/

They could probably do with an official "recommended" list of plugins though. TBH, the Forms plugin is just about the only one I use.

We have been working with Ajax for about two years, and shied away from Spry for a variety of internal reasons.

That being said, we had a LOT of success w/ Rob Gonda's AjaxCFC. Extremely easy to use, and highly flexible. For the UI components that Ray mentioned as coming w/ Spry, we use Jack Slocum's ExtJs - a product which, if you are unfamilair with, I STRONGLY recommend you _become_ familiar with - and it has awesome AJAX/JSON capabilities built right in (grid, tree, etc), and is fairly lightweight (ok, you got me, maybe not as lightweight as I'd like). Oh, and it looks absolutely fantastic.

I know jQuery is the buzzword of the day, and Spry - being the Adobe product - will get heavily pushed, but in my humble opinion, that is vastly overcomplicating the issue.

jQuery is one of those things that blew my mind - I can't believe how much easier it has made my life. It's combination of succinct syntax and power has almost brought me to tears of joy on many occasions.

If you have a decent handle on CSS, it's amazing what you are able to do. I've found that it has been very easy for developers I've worked with, even with limited JS experience, to pick up.

Examples of features:

$("input[@type=checkbox]:checked") - grabs all checked checkboxes

$("div#menu li.main") - grabs all list items with a class of main within a div with an id of "menu"

$("div.short_content").hide() - hides all divs with a class of short_content

$("#myDiv").after('<span class="error">This field is required</span>') - adds a span with a class and content after a div with an id of myDiv

$("#divToLoadContent").load( "content.cfm" ) - AJAX call to content.cfm, and inserts it into the divToLoadContent

I've actually found it made my JavaScript much more readable, because it uses CSS selectors and very obvious method names ("show", "hide", "append", etc.), and there is so much less code.

With methods that are chained, for readability, I'll do something like this (using Ray's example):

something
.hide("quick")
.move("slowly")
.dance("aluringly")
.somelastaction("end")

I'm usually annoyed by excessive fanboy excitement over languages and technologies, but with jQuery, I don't mind annoying myself.

@Justin: No disrespect intended, but ExtJS is far from lightweight... For full fledged applications it can't be beat, but for simple stuff I think jQuery is the winner hands down...

Ray, we both picked up SPRY before either of us looked at jQuery. I seem to remember a hand full of us there from the start.

SPRY: It has a data oriented DOM manipulator that is king at this time. So if someone is looking for those features then it is hard to beat. It also has a bracket variable syntax similar to CF variable pound syntax or the ActionScript syntax for bound variables.

jQuery: The data handler features of SPRY could be built into a plugin for jQuery. (You and I just need one more project, eh?) Also, jQuery does more outside of the data handling. It is easier to learn IMO... but if you were trying to replace the data DOM manipulation of SPRY it would be harder to learn until someone builds that plugin. I also agree with splitting the chaining on to different lines like Daniel and find myself doing that often. It is also true that there are some bad plugins. (They are rated... but having an official cert may be possible with the UI work, not saying to expect it but they are doing good with the new UI.)

@Niel
If people have problems with the magnitude of features in jQuery then EXTJS is going to be a worse case scenario yet. I have no problem with it but that is a consideration. Learning either Spry or jQuery is much more "approachable". There is also the issue that EXTJS is harder to get community support in my experience than I have found in both jQuery and SPRY. That is just one user's experience but since Jack's stuff is paid support... it's up to each project manager to make that decision for himself.

P.S.
Spry and jQuery can share space fine... sometimes you may want both. :)

Really interesting comments. Just adding my 2 pence...

I really like jQuery, but agree about the plugins point. The main reason that I choose jQuery over Spry is that Spry relies on adding a namespace to your HTML and then adding attributes to HTML tags. It seems a little bit backwards in terms of thinking as we have moved towards separation of code and presentation (CSS and HTML, MVC design patterns etc). Perhaps I missing the point (I often do!)

Having said that I think that (as with CF frameworks) you should use which ever one suits your needs best.

Since I used to write my own JavaScript routines before adopting jQuery, I can't refute the notion that folks who are already comfortable with JavaScript will find it easier to learn jQuery. But like Daniel alluded to, I think that one's knowledge/comfort-level with CSS (or lack thereof) is more of a factor.

I don't understand this issue with the plugins. There are a lot of them out there and some work better than others, but they're completely optional: if the plugin you downloaded and tested turns out to be less than ideal or perhaps even a total dud, you can either tweak, learn enough from it to write your own routines, or ditch it. How is this different from the plugins written for FireFox, or even the custom tags and CFCs folks have written for ColdFusion?

Lots of great comments here. I was a bit surprised to see so many on a Saturday. Don't you guys have a life? ;)

@BrianS: There are a lot of plugins for Firefix, but not many per function (imho). Ie, I don't see a lot of duplication in FF plugins, but there do seem to be a lot for jquery ui. Let me be clear - choice is good. I don't mind that. I'm just speaking as someone who is unfamiliar w/ jQuery. It can be overwhelming. Again - the jQuery UI project seems to be fixing this.

@John: Odd - to me - Spry seems more direct. I can "see" the html with the {} stuff in it and it makes sense. But in jQuery if I have to loop over and write out stuff like <td> tags, then to me that's harder to read. It's also harder for someone not familiar with JS to update the look and feel. I 100% agree with your point about using the one you are most conformtable with.

@BrianS: The plugins are not a bad thing, it can just take a bit of time to find the good ones. But as they are all free I can't really complain!

@Raymond: did you actually mean Firefix?! As for my Spry comments, I see your point about being able to see what Spry is doing. I'm coming from the angle of preaching standards and accessibility to my development team so HTML should validate against validator.w3.org. I also think it works better if aesthetics and functionality can be developed independently.
I have a young son so by the time I get to the end of Saturday, I'm too tired for a life :)

When the choice is between doing work/chores or messing around online... :)

Maybe the better/best way to learn jQuery is to ignore the plugins (and consequently all those choices) at first. I don't think I was even aware of the existence of the plugins until after I'd been using jQuery for a few weeks.

But that might be easier said than done depending on what you want to do with jQuery, and adding functionality or effects to tables (something that Spry was specifically designed for) is one area where writing your own jQuery routines could be challenging: table elements are atypical in some regards and don't "follow the rules" in some cases.

So table manipulation is one area where I would say the existing plugins are an important (maybe even crucial) part of the toolset.

@John - typo. I meant Firefox. Spry _can_ validate if you include the DTD. Most of my examples don't, but the Spry docs show it.

I just wrote a post on my blog listing the jQuery plugins that I use and would recommend to others, and asked folks to list their favorite/not-so-favorite plugins. Maybe we can come up with a "starter list" of reputable plugins.

In my evaluations of JavaScript libraries/frameworks for my team, I've asked what the intention and strengths of each of them were.

IMO, Spry and EXT focuses on specific solutions - data grid populuation and UI elements - and accomplishes them quite well (not to say that they do not have other functions).

Comparing them to jQuery is somewhat misleading because jQuery provides a broader solution - being able to interact and manipulate with the entire DOM more easily. That said, it plays well with others - whether other libraries with the same broad focus, with libraries with a more UI element focus, or with a (as already mentioned) huge plugin community.

When asked, I'd recommend to developers who wants to start with a JS library to begin with jQuery. It provides a relatively easy way to be exposed to, and accomplish, many of the fundamental DOM interactions such as creating and modifying elements, their attributes and position, as well as working with AJAX calls and callbacks.

In regards to quantity/quality of jQuery plugins, I think it is one of its greatest strengths. As Ray mentioned, the jQuery UI library looks very promising as the "official" UI/effects plugins, but I do have to say, one of the big kicks in my day, are the feeds I receive from new open source project sites - whether RIAForge or the latest jQuery Plugin Releases ( http://plugins.jquery.com/l... ). I agree it is a little overwhelming when trying to choose one option out of five, but it's nicer than choosing out of none.

First, let me do the full disclosure thing by letting people know that I'm part of the jQuery Project Team.

Now, I think John, Brian & Daniel have done a fine job of outlining the reasons that the jQuery experience is a great one. I think that even new JS developers can become VERY effective in a short amount of time through the use of jQuery's extensive docs, tutorials, books (2 of them), & mailing list. Quite honestly, I believe the jQuery project has the most attentive team and community of any JS library out there and it's the reason that so many people have flocked to use jQuery. I'm sure that there are some features of Spry that are really compelling but when you really need to get something heavy done and you need that support structure, Spry cannot compare to jQuery at all.

In terms of the plugins, we pride ourselves on our add-ons ecosystem because we believe in empowering our community to build the extensions that they need. Being a OSS project, there's no way that we can effectively monitor and QA every plugin submitted. As Ray alluded to, this is one the reasons that we started the jQuery UI project. But when new plugins are announced to the list, believe me that they are HEAVILY scrutinized by the community. Dan Switzer recently submitted the awesome mcDropDown plugin and immediately updated it based on community feedback.

Finally, if you want to get feedback on a good plugin (or support period) the mailing list is available for all. When I hear an argument that jQuery isn't easy to learn or info isn't readily available, that's a very good indication that the mailing list hasn't been used. I see this daily when I check jQuery tweets via Summize. It's amazing how users will post a negative comment about jQuery and when asked if they've posted to the mailing list, they acknowledge that they haven't.
The really good thing about the jQuery project is that you don't have to learn by the school of hard knocks. We do our best to help everyone, regardless of skill level, and that also sets us apart from 99% of the JavaScript libraries. The tools to find that information you need are there but it's up to you to use them.

With thas said, I am really happy to see jQuery continue to grow within the CF community and I can assure you that making CF developers successful w/ jQuery is important to me. So I know that a member of the jQuery team is also a devoted member of the CF community and I'm watching out for you guys.

As I recall, Spry required changing your structure to support it, whereas jQuery sits separate from your structure.

Not having to change your structure with proprietary attributes seems desirable.

The following just feels off:

&lt;div spry:region="ds1">
&lt;ul spry:repeatchildren="ds1">
&lt;li>{name} - {function::FormattedPrice} </li>
&lt;/ul>
&lt;/div>

Rey - I hope you didn't think I was complaining. I'm only a bit frustrated when a plugin doesn't suit my needs 100% because I'm not comfortable enough to tweak it because of my skill level/comfort with jQuery yet.

Let's be honest - with OS there is the potential for crap code (hell, look at PHP :). But at least with CF I can a.) fix it or b.) roll my own. I'll get there with jQuery eventually... :)

And again, I wasn't bashing anything. Right this very second I am signing up for the jQuery list. I was just waiting for someone like you to tell me about it :D

As far as the discussion on this vs. that - I personally use a mish mash of many different JS frameworks in my projects. I choose the right tool for the job - if Spry does something better I do it (as in the data manipulation side). If jQuery, then I use it... I'd rather use 2 frameworks in an application then force one of them to do something it's not best suited for.

For those interested in learning more about jQuery, here is a great list of resources that I've compiled:

jQuery Current Version: v1.2.6

jQuery Main Site:
http://jquery.com/

The compressed & uncompressed code:
http://code.google.com/p/jq...

SVN Info:
http://code.google.com/p/jq...

Plugins & UI Widgets/Controls:
http://plugins.jquery.com/

Documentation:
http://docs.jquery.com/Main...
http://remysharp.com/jquery...
http://jquery.bassistance.d...

Mailing Lists- jQuery Support, community news:
http://groups.google.com/gr...

Project Blog:
http://jquery.com/blog/

Learning Resources:
http://docs.jquery.com/Tuto...
http://www.learningjquery.com/
http://15daysofjquery.com/

Sites Using jQuery:
http://docs.jquery.com/Site...

Also, be sure to follow the following Twitter accounts for the latest jQuery and jQuery UI news:

http://twitter.com/jquery
http://twitter.com/jqueryui

Rey

@Calvin: And you see - this is where 'use what you are comfortable' really comes into play. In a non-Ajax app, I'd already have the div and li tags, perhaps driven by CF. Whatever it is - I'd have the content there. So in Spry the onoy change is the spry: tags and the use of {}. To me it feels much more like CF code.

But this is ONE use of Ajax (Get Data, render a table) and I still say Spry rocks the world at this. But I'm feeling more and more that for other uses I'm going to lean towards jQuery. (Well, no matter what, I'm going to use jQuery 100% for a while just to get more familiar with it.)

I made a decision earlier today. I've been meaning to do an update to LighthousePro for a while now. LHP makes heavy use of Ajax (Spry) to handle working with issues. The problem though is that 100% of the data is loaded up front. This makes sorting/filtering extremely fast, but doesn't scale when you go over 400 issues. So I know I need to re-architect the setup a bit, and I think I'll use this as an opportunity to work more with jQuery.

@Rey - I was wondering how long it would take you to chime in. ;) I get that there is a good mailing list. But imagine I'm a newbie - I need feature X via some plugin. I really don't want to have to do research. I just want to get the best X. Now "best" is obviously a point of view. My problem though is that if the goal is to get people going/developing quickly, having to stop and do research for every feature is a bit of a pain. Of course, it's much better to have N ways to skin the cat than 0. Please note that I don't think this bonanza of plugins is a horrible sin or anything. It's just a bit overwhelming. Imagine a guy learning CF and he needs to do a DB query. Imagine then that he would need to go to the Developers Exchange or RIAForge to find the best way to do that. That would (obviously) suck - which is why important stuff like cfquery is built it. I think the jQuery UI project is a good example of this thinking. Yes, a LOT of people need certain UI things, so they really need to be organized into a 'main' library.

I love me some jQuery. I'd have to say when I first started learning jQuery the mailing list rocked. I could post something and usually one of the jQuery pro's would show me how to do what I was doing 10x better and easier with less code - I too did a lot of extraneous chaining :)

I will say lately the mailing list has exploded and I don't think you get that same level of feedback. I could see them splitting the list up at some point into beginner, advanced and maybe plugin lists...

I also agree on the plugins things - I think it would be cool to have a list of 'recommended' plugins or something. I try to add new plugins to delicious when I see them but there are so many popping up every day it's difficult to keep track of let alone try them all out to see which one's 'best'.

That said - I think there is a bit of growing pain going on in the community but they have a great team (except for that Rey fellow) :) And they are getting things sorted out while dealing with the tremendous growth.

@Ray - I agree with you that there are certain similarities Spry has with CF, yet I find it interesting that there is such a large number of CF developers using jQuery and involved in its community - probably much more than you'd find with other communities outside of the Adobe world.

Although there aren't syntactical similarities ( although these two projects try - http://cfjs.riaforge.org/ and
http://code.google.com/p/co... ), I do think they are both appealing in how they make hard things easy. Currently, I'm designing a scheduling app that will have drag and drop functionality. The fact that I can do this with jQuery UI:

$("div.task").draggable(
{ containment: "#calendar_container"
, opacity: .5
, revert: true
} );

makes me want back the weeks I spent a couple of years ago trying to get a div to be drag and droppable (in IE6!).

Our company uses Lighthouse Pro (it needs to always be said - thank you!), so I am really looking forward to seeing the updates with jQuery you will be making.

@todd: I didn't say ExtJS was lightweight - I know it's not :P

Let's get a JQuery Steering Committee going to decide which plugins make it the UI!

@Hatem: The jQuery and jQuery UI projects aren't in need of a steering committee. We do a great job of managing the projects and we're extremely in tune with the needs of the community. With that said, please feel free to offer your suggestions.

Rey...

Hi all,

just wondering if the built-in CF8 features of CFGRID delivers the same stuff Spry does in f.ex. Lighthouse Pro? BEN: Could you do the same with CFGRID as you have implemented it with Spry?

And isn't all the wonderful CF8 stuff done with ExtJS? Why aren't we as CF developers using that more?

And Ben, thanx 4 providing us with so much great OS software ;-) I agree this needs to be said more often!

@Seb: You mention "fex" - which I read as effects. In general, CF8's ajax support doesn't give you any effects. Like, you can't say "Take this div and fade it out." Although you then mention LHP - which doesn't have any effects at all - just simple data handling. So I may be reading you wrong.

You then ask - why aren't we all using CF8's Ajax stuff. Who says we aren't? ;) I think CF8's Ajax support kicks butt. However, I'd say it's mostly for people who don't know Ajax and want a quick and simple way to get stuff done. (Except for ajaxproxy, which I could see even Ajax experts using.)

Oh - and by Ben did you mean Ray? :)

Hi RAY ;-)

Yes, I've spent way too much time online today commenting here and there and reading lots of CF-stuff. My apologies for being so vague and dead wrong in addressing you Ray, the creator of so much nice OS software ;-) I've spent some time today over at Ben Nadel's website regarding his Kinky Calendar project, so that's the reason for my addressing you wrongly.

By f.ex I meant for example, meaning could you do with CFGRID what you do with SPRY in LHP?

I'm not so much an effects guy as a functionality guy. That's why I ask if I can achieve the same with the built in CF8 goodies as with the different JS-frameworks (like YUI f.ex. - for example).

Well, LHP's grid does sorting, paging, filtering. CF's grid does the sorting and paging built in. The filtering it does not do but it is possible. With binding, you could set it up so that when you changed a drop down, the data for the grid changes as well.

@Justin - actually I meant to address Neil with the ExtJS/lightweight comment. He stated above that it is "fairly lightweight", not you.

I'd have to say both Spry and JQuery have their place, depending on what you're trying to do and your background.

I've been immensely impressed with JQuery's documentation and tutorials online. They've really done them up right, and set a good standard for other projects to follow imho.

I agree with someone aboves point. The use of chaining and selectors, I feel, makes my code easier to read/decipher quickly.

Just a quick note to everyone, jQuery is spelled w/ a lowercase "j" and an upper case "Q". So it's "jQuery". :)

I'll talk w/ the team to see what we can do about organizing the plugins in a better way.

@Rey - I think the organization is OK. My problem is twofold:

1) Keeping up with new plugins
2) Knowing which plugin is 'best'

#2 is probably impossible but still a list of 'recommended plugins' for basic stuff like validation and autocomplete would be handy vs. digging though the extensive plugin listing...

Maybe #1 could be handled via a weekly post to the blog and mailing list with a compiled list?

@Rey - Heh, welcome to the ColdFusion/Cold Fusion problem. ;)

Long answer short, you should learn Ext. It's about 10 times as robust, feature-rich, and powerful as the other two combined.

@David: Let me preface this by saying that I was part of the Ext team as well.

Ext & jQuery play in to VERY different spaces and while Ext is great for building RIA applications, much like Flex, jQuery is definitely better suited for enhancing web applications that don't require the overhead of a massive UI library. And I know this because I was DEEPLY entrenched in the Ext project and helped Ext customers make the right choices based on their needs.

So no, you should not learn Ext and be done with it. You need to look at the library which is best suited for your application and learn that. Ext is *NOT* the best solution for all situations and neither is jQuery.

Amen!

In regards to the original question of the blog post, it would be hard for me to see EXT being easier to pick up for someone looking to get familiar with JavaScript and a JavaScript library.

I think EXT is ridiculously awesome at what it provides - I remember always right clicking EXT elements to confirm they were not SWFs. They provide some incredibly powerful UI elements, but there are some things to consider when deciding to choose it for a project:

- the core library is more cumbersome to use than jQuery's core, which is a huge deal if you are not specifically using a library for the UI elements

- the UI elements are relatively heavy - both in the download of js, css, and image files, and in its transformation of the DOM (a lot of times I want a table to be a table, not a bunch of divs)

- the difficulty of skinning (at least for me with my very limited graphics ability - it would probably take me a week to create a sprite, much less find all the css rules and images that I would need to change). this can sometimes force making a site conform to the look of UI elements, instead of the other way around. Contrast with this sweet project - http://ui.jquery.com/themer...

- the former fuzziness of their license, and their recent move to a "viral" GPL open source license with their dual licensing (have no problems paying for it if I need it for a commercial project, but this is not an issue with jQuery)

Given the nature of EXT, my choice generally isn't between it and jQuery - it would be between it and Flex.

Ray, thanks for your thoughtful and insightful response to a complex question. Based on your response, I'm inclined to start with Spry and eventually work my way up to learning jQuery. Spry appears to be a better choice for beginners like me who are manipulating and presenting data on the client-side, and this is something that I'm going to need in the near future. Although Spry doesn't have as many colorful and exciting UI widgets as jQuery I'm more interested in the data presentation capabilities for now, and I need this stuff to be as simple and approachable as possible while I'm learning.

Lastly, I wanted to mention that my boss at work has agreed to buy Dreamweaver CS3 for us. As you may know, Spry is built in to Dreamweaver CS3 and I think that this may be just the sort of hand-holding I'll need until I get up to speed on it. Yes, I'm one of those stubborn holdouts who still uses Dreamweaver (and not CFEclipse) to code my ColdFusion apps but, given that Spry is built into my IDE, I have even less reason to switch now. Thanks again.

ExtJs is definitely NOT what one would call "lightweight", and there is definitely a learning curve. That being said, it is the best JS UI package available, bar none (or, if there is a better one, I have yet to come across a better one :)

I am definitely not jumping on the back of Spry OR jQuery - in fact, I know less than next to nothing about either. We had played with flash forms internally when they first came out in CF...7?? And we were GROSSLY disappointed. We made an internal decision to go w/ AjaxCFC and a JS UI package (we had originally looked at YUI, and moved on to ExtJs).

I just wanted to clarify in case it had sounded like i was downing on jQuery (I couldn't pick jQuery out of a lineup) or Spry (same thing).

I too have a history of javascript avoidance! For the past few years I've found myself working either at the service layer with CF or UI work with Flex.

My current job requires 508 compliance for all applications. I decided to take a look at js libs that would be compliant.

In my very non-scientific research of the major libs, I found Spry to be the most lovable by accessibility checkers.

I understand future versions of jQuery and the like will be more better but for now Spry is the right tool for the job.

Do the following:

Ctrl+U
Ctr+F
jquery.js<intro>

Spry is scary. The documentation spans over multiple pages. The code is more "opaque" (to me) then the jQuery one.
jQuery is more minimalistic, which makes it less "scary" in some instances, but also more of a mind-twist to get it to do what you want.
BTW, I have only some jQuery experience, but non with spry.