Adobe have released a JavaScript framework/library/toolkit/whatever called Spry. It does all the usual Ajax stuff, all based around parsing XML—reusing Google’s implementation of XPath in JavaScript.
Reading through some documentation, it looked like a reasonable timesaver if you’re using XML as your data format. Weirdly, the XML gets transformed—or “flattened”—into something that looks like JSON. It seems strange not to use JSON to begin with.
At the end of the documentation, there’s a nod to progressive enhancement. Hijax is mentioned specifically. Great! But looking at the example given, this is clearly a different form of Hijax than I’m used to.
It’s overly-complex, still insisting on XML as the data format even when plain ol’ HTML would be quicker:
To progressively enhance this page with Spry, so that you don’t have to load an entirely new page when clicking on the links, you would first have to make sure that the page fragments of each page that the links referred to were accessible via XML.
Worst of all, it requires invalid custom attributes (the namespace URL for the extensions is currently 404):
<div spry:detailregion="dsNotes" spry:content="{note}">
<p>This is some <b>static content</b> for note 1.</p>
</div>
This is something that Drew previously picked up on over at the Web Standards Project.
I don’t get it. (X)HTML already provides attributes that, according to the specs, are for general purpose processing by user-agents
: class and id. I really don’t see the need to muddy markup with proprietary junk.
I’m sure that the code for the Spry framework is very good but the implementation seems extremely restrictive with its insistence on XML and custom attributes. This is not Hijax.
Posted by Jeremy on Sunday, December 24th, 2006 at 12:54am
Comments
I think we might be in for a wave of this stuff. I remember the very first article/tutorial I read on Ajax, maybe a year ago, provided a very simple request object that ran a callback to parse the response. That’s the heart of Ajax. "Hijax," or progressive enhancement, should be a given.
Now we have an onslaught of ‘frameworks’ that attempt to make something very simple even simpler, which just makes it more complex. The ‘spry’ namespace just seems to be more about Adobe marketing than having any real practical benefits. I think Adobe said, "How can we ‘brand’ a framework and get some sort of ROI?" and ended up with Spry.
# Posted by Colin on Sunday, December 24th, 2006 at 1:49am
Some comments to both the post and to the last comment.
Spry does not force you to use XML for data. In the latest release you can load HTML just as easy. However, if you want to use datasets, then yes, it requires XML. I’m not sure why someone would want to use HTML for data as XML seems to be a much better fit. It also allows you to do some nice manipulation of the data on the client side - for example, flagging rows of data where some condition is met.
As for the 404 for the namespace - do remember Spry is still in development so that is just a temporary problem. This hasn’t stopped me from using the code successfully on a few sites already.
Colin - I’m not sure why you think Spry is complex. I’ve taught Spry classes a few times now - and time and time again folks tell me they are amazed at how easy it is to use. It certainly seems a lot easier than Prototype, although I’ll admit to not looking at Prototype quite closely yet.
# Posted by Raymond Camden on Sunday, December 24th, 2006 at 8:35pm
Is it simpler than a request object and a callback? And, I don’t mean ‘complex’ as ‘difficult.’ I think Spry is purely a marketing thing. I don’t yet see it’s value over the basics. Just get ‘spry’ all over the source code and it’s like viral marketing.
# Posted by Colin on Monday, December 25th, 2006 at 1:19am
Yes, I think it is. You can have one line pointing to the XML and then your HTML which uses the dataset. No need for creating a callback (although you can use one if you want one), no need to make a HTTP object (Spry does it all for you). Spry is far from just a marketing thing. Even though it is still in development it is being used in production sites already. I’m probably pretty biased as a Spry user (been using it since the first release), but I truly think is a great framework.
# Posted by Raymond Camden on Monday, December 25th, 2006 at 5:18am
I think one of Jeremy’s main points is that it’s insisting on XML as the data format, and then parsing that into some serialised notation on the client. That’s far from ideal in every situtation except one where you’re forced into using an XML data format ( why would this be? ).
Google’s JavaScript XPath implementation teriffies me, and I notice they’ve taken it out of their maps API, along with the JavaScript XSL piece. I believe it’s some 60K before compression.
As people get more and more excited about the possibilities of client-side scripting, lets make sure there some that keep their feet on the ground and remember that some processes are far better suited to being run on the server and some suited to the client. Just because you can, doesn’t mean you should.
# Posted by Andy Hume on Tuesday, December 26th, 2006 at 11:48pm
Sorry. Comments are closed.