Developer

Spry Interrogation

Greg Rewis, Senior Evangelist for Web Tools at Adobe, discusses their designer centric Ajax framework Spry.

Builder AU sat down during WebDU with Greg Rewis, Senior Evangelist for Web Tools at Adobe, to find out more about their designer centric Ajax framework Spry.

Builder AU: What is Spry and why is it unique?

Rewis: To understand what is unique about Spry we need to first understand the traditional, shall we say challenges, in developing traditional Ajax applications.

So Ajax has been around for a long time, it's not something new. It's just a combination of technologies that have existed for quite some time. But have now been implemented in a new way, but the problem with any Ajax application is you first, well you have two choices — you can either do it all by hand from scratch which no one is going to do, or you can choose a framework.

Now there's a number of frameworks out there in the world on the web that we can choose from. The problem that we solved from the side of Adobe is that each and every one of these frameworks requires that a JavaScript developer get involved. That your JavaScript skills are really up to par.

On top of that then you have to have an understanding of XML and the whole backend way in which the browser works and so on, which is very unapproachable for let's say 90 plus precent of the web designer developer market. Even as a web developer today I may not have the top level skills that are needed for a good Ajax application.

So we said "well how can we help", so we developed the Spry framework which is basically, just as any framework is, and I'm using a word that maybe someone doesn't understand — a framework is really nothing more than a collection of the JavaScripts already prewritten.

So we developed the Spry framework, this collection of JavaScripts, with the designer in mind. With the ease of use in mind. Now we put that out to the community and as part of our labs.adobe.com and it was amazingly successful in downloads, interest that was shown by the community.

And one of the great things about that was that it gave us the opportunity to also shape the Spry framework. So we're already up to, well now they're going on the fifth release of the Spry framework. So we've updated it based upon feedback from the community. Added things like effects to the framework, again an initiative that came from the community itself.

Is the process to use Spry becoming simpler?

Oh the process is absolutely becoming simpler. When we put this out the idea was hey let's, to use an American expression, throw it against the wall and see if it sticks. And it very definitely stuck and resonated and we got that community involvement. Granted, up until now, the process of implementing that Spry framework was still a handcoding experience.

So you could download it today off of labs.adobe.com, you would get the framework — the JavaScripts, tutorials, sample files and so on that you could deconstruct. But the actual implementation was still a text based process. Now obviously, we hope that you're implementing that with Dreamweaver. But the fact of the matter is since it is nothing more than a collection of JavaScripts you could be using Notepad or any HTML authoring tool to implement this framework.

Now in order to make this better, simpler, easier for our users as a part of Dreaweaver CS3 it all becomes visual. And so that's where the true productivity in creating Ajax based applications is going to really come to the forefront.

Will Spry remain available as a framework?

Right, one of the key considerations that we have internally at Adobe was "OK, exactly how are we going to handle this product. Is it a product, is it not a product, is it part of a product". You know from a software developer's standpoint, if we were to roll it into Dreamweaver and make it only available through Dreamweaver, then how do we make updates? Then we're basically locked in for the lifecycle of Dreamweaver.

So instead we took a different approach, and we said "you know what we're going to keep this as a separate development initiative" and the entire Ajax Spry framework for Dreamweaver is actually nothing more than a bunch of JavaScript files and XML files that tell Dreamweaver how to handle this.

What that means for us is that over the lifecycle of this upcoming version of Dreamweaver we're going to be able to continue to develop Spry on a completely independent path. So you might see Spry 2.0 or 3.0 or whatever it happens to be we can make available for downloads for any Dreamweaver user. And by downloading it you get all the new widgets, you get the new effects or whatever it might be that comes to be.

Why did you choose to use Google's code for XML parsing rather than build your own?

Right, so one of the prime aspects of Ajax is the XML connection, it's entirely possible to build an Ajax application and we see a lot of applications being built today where people go "oh it's an Ajax application". Well no because the data is actually static, it's coded into the HTML page. For a true Ajax application you are truly dealing with XML and loading XML in.

So that then becomes then the issue, how do you parse that XML? And of course we could have gone out and written our own, rolled our own as it were, but you know why do that when Google has already invested a lot of money in the process of understanding and parsing XML properly, so we decided hey let's take their initiative and use that as our XML parsing.

Can Spry be used to build Ajax applications for Apollo?

Absolutely, one of the misconceptions I guess it was when we announced Apollo back at the MAX conference was everyone thought OK that we're dealing with a new Flash player. While it could be considered that in broad strokes Apollo is much more than just a new way of displaying Flash content because of it's ability to show and display HTML, JavaScript and so on.

So yes, Apollo applications could very well have a large part built entirely using Ajax and the Spry framework.

Could Spry be more standards compliant?

Absolutely, I was recently at a conference in Vancouver and had a chance to hang out with some of the standardistas within the community and talk about that very subject and interestingly enough the comments that are being thrown around could be applied to many of the frameworks that are out there.

The approach that we took was, after seriously weighing the pros and cons of every individual possible approach... It's been said "well you should have used the class attribute", well you know - yes. But how many of us as designers think in those terms.

I think of a class as something related to my CSS and by introducing something else in there, I'm really confusing my designers a lot more. So yes it is very designer centric in the approach. And I think that standards are fantastic, and I'm a full supporter of standards and we believe heavily in standards at Adobe. However at some point some trade offs can or maybe have to be made in order to make something more approachable.

So what we've tried to do is to find that proper balance, that proper trade off. It's going to work for some people, some people it's not going to work for. I guess that's the nature of the beast in software development.

Will we see more sites using Spry once the new CS3 suite becomes available?

Well we would hope so, but as an evangelist my motto is just because you can doesn't mean that you should. We've already seen some applications using Spry. The American broadcaster NBC is using Spry on it's web site, if you go to NBC.com and look for shows you'll see one area of the page updating independently of the rest of the page and that was built using Spry — we are seeing real world applications from very large organizations already today.

But obviously yes once CS3 is on the streets I think that we'll see a lot more interesting examples of what might be possible.

Editor's Picks

Free Newsletters, In your Inbox