Amcom Home Page

 AJAX/JS Framework Showdown - jQuery vs Spry

In an ongoing effort to put together our development standards at Amcom, we're currently researching AJAX/JS frameworks. The choices have been essentially narrowed down to Spry or jQuery.

I haven't done a considerable amount of work with either, but my personal preference leans towards jQuery. I'm more familiar with it than Spry (while I haven't really gotten my hands too dirty with it, I've used a number of jQuery plugins), and being someone who likes JavaScript I'm comfortable with the syntax.

The boss, however, being a big Flex guy, really gravitates towards the Spry syntax, as it's more familiar to him. The boss, being a fair and noble kind of boss (yes, he reads the blog), told me to go out and do an objective analysis of the two and see if one comes out significantly ahead of the other.

I built a few demo apps using each ( and from a technical perspective I have to admit, it's still kind of a tie.

In putting together comparable demos of each, they both allowed me to put together some pretty slick functionality in a relatively short period of time. Neither required significantly more (or less) code to implement than the other.

In the table-striping example, here's the relevant jQuery code:

$(function() {
	$('#striped tbody tr:even').addClass('odd');
	$('#striped tbody tr:odd').addClass('even');

...and the relevant Spry snippet (which goes right into the HTML, not JavaScript):

<tr spry:repeat="dsEmployees" spry:even="even" spry:odd="odd">

Both are pretty straightforward. The advantage to the Spry code is that, if you're not familiar with or comfortable with JavaScript, you can easily implement the effect in HTML. The downside that I can see is that you lose the ColdFusion context of the output data. They're now Spry variables. Being comfortable with ColdFusion and knowing how to manipulate those values (should the need arise) seems like a pretty big loss to me.

In the filter function comparison, both are pretty even as well. Both the jQuery and Spry solutions require some JavaScript to be written. Although with the jQuery solution I'm essentially just showing/hiding table rows as opposed to applying a true filter to the data. The Spry solution appears to actually manipulate the result set. In fact, it provides a built variables ({ds_RowCount} and {ds_UnfilteredRowCount}) that make it very easy to say, "Displaying 'x' of 'y' Records". The same thing could be done in jQuery, but it'd be a manual process to calculate the value.

Loading external content into a div was also equally as simple. 1 liner for jQuery, 2 liner for Spry. Not a significant difference there.

So it seems that from an implementation perspective, it's still a pretty tight race. There's no compelling reason to choose one over the other. Time to broaden the scope of the evaluation.

As far as I can tell, jQuery is a bit more... robust, shall we say. There's huge support for it in the community. New plugins are developed and released on a pretty regular basis. As I alluded to before, I've not really written much jQuery myself, but I've been able to incorporate some pretty cool effects by grabbing some of the available jQuery plugins.

There are also (to my knowledge) 2 books published on jQuery. It's got a high-traffic mailing list (to be fair, Spry may have one as well... have not looked). I would think that support for jQuery would be more readily available.

It's also my belief (or feeling) that beyond the samples that are available for Spry (auto complete, various widgets, etc), that jQuery is more robust in allowing you to manipulate the elements on the page. In the sample app that I put together, I used a frameset with a list of links to each demo on the left. I wanted to have some sort of indicator in that navigation to show which page the user is currently on. I've done this plenty in ColdFusion, using a series of conditionals. But using jQuery, it was as simple as:

$(function() {
	$('a').click(function() {

That's it, in its entirety. No convoluted conditionals in the markup making it difficult to read. I'm not sure that Spry allows for that kind of manipulation of elements on the page.

So, the (semi) conclusion that I've drawn is that both frameworks make it painfully easy to incorporate some pretty nice client side features. I can honestly say that I was pleasantly surprised by how easy Spry made it. Not that it was any easier (or any more difficult) than jQuery... I just had a different set of expectations going in :)

What it will likely come down to is the community. The community will be that compelling argument that I can present to show that there's justification in choosing jQuery over Spry. The support is there. The documentation is there (in the way of both web site and books, as well as hundreds of blog entries by so many different jQuery users). I think that during development, when we hit a wall (and we hit 'em hard when we do), there will be more avenues available to us to get us around (or through) the wall.

What say you? Agree? Disagree? Is there anything that I've overlooked or anything that I've looked at incorrectly? Thoughts would be greatly appreciated, as I don't think the vote has been quite decided yet (although we are waiting on the ballots from FL and expect that will clear everything right up).

As an aside, I've zipped up the demo files and attached them to this entry. They should work out of the box, as long as you put them under your web root in a directory called "labs". You can also view them online at

A new page has been added to the sample code online (as well as included in the zip) to demonstrate a more "pure" JavaScript approach to table striping via Spry. Thanks to Ray Camden.

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
Your first code comparison is a bit off. The first code block shows using jQuery to add a css class to even an dodd rows. But that's all it does. Your second code block does that _and_ handles displaying data. You would need more jQuery code to do that as well. Certainly not a _lot_ more of course, but Spry is doing more in that example than jQuery is.

I've used both - and I agree jQuery is more robust, but I like the simplicity of Spry quite a bit.
# Posted By Raymond Camden | 10/29/08 2:16 PM
Having used both I have to say that I really like jQuery for applications. Spry has proven to be excellent for smaller apps and widgets because it is quick and easy to implement. I have found jQuery to be a lot more flexible and familiar, and there is a huge community base to assist in your support. Spry, on the other hand, has a relatively small user base.

Objectively, I would say that you should analyze your project and determine the needs for that project and base your choice of framework upon your needs. I would say this applies to any framework you choose.
# Posted By TJ Downes | 10/29/08 2:18 PM
Just curious....what would display with the spry code if the user didn't have javascript enabled?
# Posted By Marlon | 10/29/08 2:24 PM
@ray - understood about Spry also displaying the data, although that's the one part of it that makes me uncomfortable. I'd rather stick with using a ColdFusion dataset, since that's what I know. If I need to do a quick <cfif len(trim(firstName)) eq 0> or if i just want to show the first initial by doing left(firstName, 1), etc... I have that option. I know that Spry has the concept of conditionals, but now instead of simply using Spry (or jQuery) for the AJAX/JS stuff, I have to learn how to use it to format my output as well. That's something I already know how to do :)
# Posted By Charlie Griefer | 10/29/08 2:26 PM
@Marlon - I didn't try either without JS, to be honest. That's not something we discussed internally, although it's probably something we should. Feel free to turn off JS and try out the demos I posted. I'll do the same, but I'm guessing it won't be pretty for either :)
# Posted By Charlie Griefer | 10/29/08 2:29 PM
You still are using CF data Charlie, the only difference, whether you use Spry or jQuery, is how you get and present the CF data. For string formatting, you can either do it in JS, or do it server side before you return the data. For dates I find it much easier to do in CF. For things like, "Display LastName, FirstName", I'll do it on the client side.
# Posted By Raymond Camden | 10/29/08 2:30 PM
I agree with TJ. Right tools for the right job. For a larger app I would generally go with jquery for its robustness, and the fact that larger apps are always evolving and I won't know exactly what I'll need. Spry is great for a quick and dirty little app imho.
# Posted By Dana K | 10/29/08 2:34 PM
That nails it for me...without javascript, the data isn't there in the spry example. In the jquery one, the data is there, just not striped.

When I do websites, I design it first without javascript and then later I go in and tweak it with javascript here and there.....unobtrusive js....

Spry doesn't seem to be very unobtrusive.
# Posted By Marlon | 10/29/08 2:40 PM
Wow - the complete failure of Spry with no JS would be a huge dealbreaker for me as well.
# Posted By Jim Priest | 10/29/08 2:47 PM
Being the web standards junkie that I am, and specifically, I am of the XHTML Strict type, I detest Spry from the standpoint that it does exactly what I feel an Ajax/JavaScript library should *not* do: it forces you to add to the markup itself.

Take a look at your striping example. Spry requires you to add namespace markup to the (x)HTML. (x)HTML is designed to serve one purpose and one purpose only: to provide display instructions to the browser. It should never be used to provide behavioral instructions, as (x)HTML is stateless. Behavioral instructions should be left up to JavaScript and CSS, as that is where the behavior comes from.

It should also be noted that Spry markup will cause your XHTML to fail validation. Failed validation causes the browser to render in quirks mode. Ever tried to get a display to look nice across multiple browsers? Good luck doing that when your markup won't validate.

Coming from a ColdFusion perspective, I would use this analogy:

Spry is the equivalent of stuffing all of your logic into the top of your .cfm template, whereas jQuery is the equivalent of using an MVC framework (e.g. ColdBox, Model-Glue, Mach-ii) to separate the various concerns of the application into layers.

If you believe in the separation of concerns in your application architecture, why would you not also believe in the separation of concerns in your markup?

+1 to jQuery and CSS.
# Posted By Matt Quackenbush | 10/29/08 2:50 PM
@Matt - agreed there. One thing I *really* liked about what I did in the navigation (modifying the class to indicate which page the user is viewing) is that it didn't touch the markup. At all. If I want to pull that out or change it in any way, I don't need to touch the HTML. That there is one huge separation and I like it a lot.
# Posted By Charlie Griefer | 10/29/08 2:54 PM
I agree w/ Matt regarding XHTML markup.

Use jQuery if you want control of your markup.
# Posted By John Hodorowicz | 10/29/08 3:01 PM
Charlie, two points that I'd like to make:

1) jQuery is by far the hottest JS framework on the net right now with a massive community and an extremely involved team. We focus our features on what the *community* wants and strive to ensure that jQuery developers have all of the resources possible to support their development

2) Spry, and JS for that matter, is *NOT* a priority at the moment for Adobe. jQuery is a priority for us and pushing open web capabilities is what we focus on.

3) There are 3 jQuery books on the market at the moment which will help you and your team to become successful with jQuery

4) We have support via mailing list & IRC

5) Our release cycle is substantially faster than Adobe Spry's

6) The jQuery project has the jQuery UI project to provide effects and UI controls. Spry does not.

7) The # of sites using jQuery reads like a who's-who in the web world:

8) We have extremely robust documentation and with Media Temple's help, we're now hosted on 4 servers ensuring uptime.

9) We have a strong following in the CF community, due in part to my efforts along with other notables such as Rob Gonda, Joe Dazinger, John Farrar and others.

10) Adobe is now including jQuery UI into Dreamweaver which in itself, is a huge testament to the work being done on our projects

11) Our plugin repository is second to none providing more user-contributed features than most any projects that I know. If you need some type of capability, chances are there's a control for it

12) We are true OSS project dual licensed under GPL & MIT giving you complete freedom in how you use the library and ensuring that you have a massive community to always support it. Note, Spry is licensed under BSD but does not have anywhere near the community that jQuery has.

13) I personally have a vested interest in CF developers being successful w/ jQUery since I've been a CF developer for the last 10 years.

I hope all of this information helps.

# Posted By Rey Bango | 10/29/08 3:11 PM
Yep and I noticed it was much more than two points! :D
# Posted By Rey Bango | 10/29/08 3:12 PM
Great chatting with you on the phone Charlie. Let me know if you or your boss need follow-up info and I can schedule a call w/ members of the jQuery team.

jQuery Project
# Posted By Rey Bango | 10/29/08 3:56 PM
Hey Rey - Appreciate the call. That's the kind of community support that I was talking about in the post. Actually that's way more than the kind of community support that I was talking about :)

Very cool. Thanks again!
# Posted By Charlie Griefer | 10/29/08 4:23 PM
Point #14...

Spry does NOT have a Rey Bango!!! :)
# Posted By Jim Priest | 10/29/08 4:30 PM
Having not used Spry personally, I don't know this. In the following Spry example, would the Spry specific attributes remain in the HTML code?:

<tr spry:repeat="dsEmployees" spry:even="even" spry:odd="odd">

That's another point for jQuery as it does all of it's manipulation after the DOM has loaded leaving your HTML nice and clean.
# Posted By Andy Matthews | 10/29/08 4:56 PM
@Andy - yes, that's the final markup and that's what you see viewing source in the browser. And yeah, that leaves me with that oogy feeling. The Spry just seems too tightly coupled with the markup. Make the decision down the road to move away from Spry, and it seems that you have to dig deeper into the markup than one would reasonably expect. The jQuery samples wouldn't require that. Point for jQuery :)
# Posted By Charlie Griefer | 10/29/08 5:06 PM
The other angle that I'd also throw in there is the business perspective. Technical people strive for that goal of utopia, which is an honorable goal, but the reality of time is reality.

So, say for example Tech-A theoretically was more powerful, more compliance based, etc... but due to that power was more complicated to work with, steeper learning curve, requires skills that the team doesn't currently have, and you only a need 25% of the features vs. compared to a Tech-B.

If the bottom line is that Tech-B yields the same (business) result in a faster amount of time, that's a major consideration. Development time is very costly, opportunity costs, time to market, etc... It's all about results in the end.

Well you could say Tech-B could cost you more in the end in maintenance costs. That's true, but if say Tech-B gets the initial version done in 2mos vs. 4mos on Tech-A, and Tech-B's maint cost is 100hrs/yr vs. Tech A's 80hrs/yr... Tech B is strategically a better choice.

I'm not saying that that's the situation for jQuery vs. Spry - just throwing that out there as a hypothetical situation. But for example the XHTML validation issue - from a business perspective, as long as it works, then it's a low priority item. More important would be availability of knowledge and support.
# Posted By Tariq Ahmed | 10/29/08 8:19 PM
Charlie - I'm not so sure that jQuery does the layout better. If you look at LHP, I had to generate all my layout in JS. Generating HTML via JS isn't hard, but it isn't easy to follow either. The Spry markup is much simpler for designers to work with and update.
# Posted By Raymond Camden | 10/29/08 8:46 PM
@Ray - y'know... all I wanted to do was a table-striping comparison :)

Unless I'm mistaken (and it's entirely possible), the only way to do it via Spry was to be in a repeat region based on a Spry dataset. That's why the first example wasn't entirely apples-to-apples (to paraphrase your initial comment).

While I haven't used jQuery (yet) to output HTML, I've used JavaScript to manipulate AJAX return values on the page and you're right that it's not pretty.

So in trying to make a more apples-to-apples here, my guess would be doing the same thing via jQuery (or JavaScript in general) still wouldn't require me to tightly couple the JS with the HTML. I'd probably have empty div elements and populate them via JS functions. To me, that's still "better".

Yeah, "better" being subjective. I'm not a designer. I'm a developer (at least, I aspire to be). I'd rather manipulate the JavaScript to generate the HTML than have the JS framework coupled that tightly with the markup. Altho I do definitely get that it's better for designers, and I'm aware that was Spry's initial focus (not sure if it still is or not).

Bottom line for me (and I intend to blog this in more detail) is that I don't dislike Spry. I thought I would. I definitely went into this having a bias towards jQuery (but I was aware of the bias, so that makes it OK). I came out thinking that there's a lot of nice stuff in Spry. I don't really have anything bad to say about it as a technology. After the evaluation, the reason we're leaning towards jQuery is less about the technology and more about the support that surrounds jQuery. It's also a little because of the loose coupling, but largely because of the community and the support.
# Posted By Charlie Griefer | 10/29/08 9:24 PM
Tsk tsk. Read the docs. ;)

Spry supports selectors like jQuery. If all you wanted to do was add class X to IDs that match Y, then its much like jQuery.

"So in trying to make a more apples-to-apples here, my guess would be doing the same thing via jQuery (or JavaScript in general) still wouldn't require me to tightly couple the JS with the HTML. I'd probably have empty div elements and populate them via JS functions. To me, that's still "better"."

So you would put your HTML down and write custom JS code to 'fill' it. Spry puts your hTML down and simply replaces {token} with a value. No JS needed. (To handle the replacements. Loading the data takes a line of JS.) I don't see how jQuery is better here at all.

Why do you say jQuery isn't coupled to the HTML? Aren't you outputting the HTML from jQuery? Isn't that coupled? In Spry the HTML is 'tired' via the spry: tag, but outside of that, its plain HTML.

Don't get me wrong - I love jQuery. I'm doing more in jQuery now than Spry. But I think some of the assumptions you have about Spry are fundamentally wrong.
# Posted By Raymond Camden | 10/29/08 9:31 PM
@Ray - dude! _Now_ I gotcha about the apples-to-apples. No, I didn't know that Spry supports selectors. So, whereas the jQuery code for the table striping is:

$('#striped tbody tr:even').addClass('odd');
$('#striped tbody tr:odd').addClass('even');

the corresponding Spry code is:

Spry.$$('table#striped > tbody tr:nth-child(2n+1)').addClassName('odd');
Spry.$$('table#striped >tbody tr:nth-child(2n)').addClassName('even');

Nice. I'm going to add a new sample page to the online demo to reflect this, and will update the zip file as well.
# Posted By Charlie Griefer | 10/30/08 12:09 AM
@Ray (con't) -

"So you would put your HTML down and write custom JS code to 'fill' it. Spry puts your hTML down and simply replaces {token} with a value. No JS needed. (To handle the replacements. Loading the data takes a line of JS.) I don't see how jQuery is better here at all."

"better" is of course, subjective. That's why I put it in quotes :)

It's the {token} pieces being in the HTML that i'm getting hung up on. That's the "coupling" aspect that I keep coming back to. But with the understanding that Spry supports selectors, that does change things quite a bit. Yes, you were right in that some of the assumptions I had about Spry were fundamentally wrong. The realization that Spry supports selectors changes a lot of my thinking.

I'd imagine if I were to use Spry, I'd probably use it more like jQuery (or plain ol' JS). I'd likely try to minimize (or altogether eliminate) the use of the {token} variables in favor of more of a JS approach (via selectors) to populate HTML entities with specific values.

For example, in a JS function, let's say I'd return some JSON from the server. I'd then use something like:

Spry.$$('#someElement').setProperty('innerHTML', my_new_value);

... where 'my_new_value' would be data retrieved from the server.

That's unobtrusive and doesn't require me to tightly couple the Spry code in with the HTML by way of {token} values.

Does that help clarify what I meant by the coupling (even though it's now a moot point, I guess) :)
# Posted By Charlie Griefer | 10/30/08 3:00 AM
Did you know that Spry has DOM utilities? See SpryDOMUtils.js or

@Matt, using Spry in ColdBox is easy.
Take a look at
Concerning MVC: I don't see any difference of using jQuery instead of Spry.
# Posted By Ernst van der Linden | 10/30/08 5:46 AM
Rey Bango wrote:

10) Adobe is now including jQuery UI into Dreamweaver which in itself, is a huge testament to the work being done on our projects

How so? Where in DW?
# Posted By JJ | 11/11/08 6:44 PM
@JJ - I don't think it's actually built in. According to this thread from cf-talk, you can add some intellisense for various JS frameworks in via an extension:
# Posted By Charlie Griefer | 11/11/08 6:56 PM
10) Adobe is now including jQuery UI into Dreamweaver which in itself, is a huge testament to the work being done on our projects

CS4 has JS code introspection, which means that once you have included the JS library into your page, CS4 will be able to show code hinting.
# Posted By Dooza | 11/12/08 5:37 AM

BlogCFC was created by Raymond Camden. This blog is running version 5.9.002. Contact Blog Owner