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 (http://amcomtech.net/labs/ajaxframeworks/) and from a technical perspective I have to admit, it's still kind of a tie.
I've used both - and I agree jQuery is more robust, but I like the simplicity of Spry quite a bit.
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.
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.
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.
Use jQuery if you want control of your markup.
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: http://docs.jquery.com/Sites_Using_jQuery
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.
Rey
Rey
jQuery Project
Very cool. Thanks again!
Spry does NOT have a Rey Bango!!! :)
<tr spry:repeat="dsEmployees" spry:even="even" spry:odd="odd">
<td>{employeeID}</td>
<td>{lastName}</td>
<td>{firstName}</td>
</tr>
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.
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.
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.
http://livedocs.adobe.com/en_US/Spry/SDG/WSFBB15A0...
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.
$('#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.
"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) :)
Did you know that Spry has DOM utilities? See SpryDOMUtils.js or http://www.dojochina.com/book/spry/articles/data_a...
@Matt, using Spry in ColdBox is easy.
Take a look at http://evdlinden.behindthe.net/sprysample/
Concerning MVC: I don't see any difference of using jQuery instead of Spry.
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?
http://www.houseoffusion.com/groups/cf-talk/messag...
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.