Spry 1.6 Came out on 1 Oct 2007. It has been 1 1/2 years since any major update of the Spry framework.

I can understand that DW CS4 took a lot of time for the SPRY team, but since then we have only one little update, the SpryData.js on 11 Dec 2008. That's it…

I need to know if Spry is dead so I can move on to another framework.

Spry is the best AJAX framework for data related websites. And that is the kind of website I have. Nothing is better!!! But if Spry is dead, I have to look into using something else that will meet all my needs in all areas, not just data.

We all choose Spry because we were told it's in pre release and the developers were looking at adding new functions and features by listening to the community that uses Spry. This was the main benefit of Spry for everyone.

But it looks more and more like it's dead. The developers will not comment on any of the threads that ask about the future of Spry, and to me this is a big indicator of it's state.

If just one of Kin or Donald came out and said "… we have something big around the corner…" then many of us would be excited and continue to use it. But until then I will start to look into JQuery or Mootools to see how difficult it will be to change all my pages to a framework that is expected to keep evolving….

Where I work are moving most of our projects over to jQuery since it has a roadmap and keeps you up to date on where it is heading and more importantly WHEN.

Don't get me wrong I LOVE Spry, but no real support or regular update for over a year has left them with no other option than to migrate, I'm actually really upset with Adobe on this as I much prefer Spry to jQuery syntax and a simple blog post twice a month is not too much to ask at all in my opinion, but I can understand why Adobe may have given up on Spry in favour of the more common frameworks since most people would want jQuery support in Adobe products regardless.

So the company I work for gave up on Coldfusion this year because they wanted to use something as powerful as Visual Studio as their IDE for team management purposes and StyleCop and now Spry is also going to be discontinued in production. Quite disappointing for me after supporting Allaire/Macromedia/Adobe for over ten years.

Kin has yet to login since these forums were updated to the new format and Donald hasn't bee on since 9 April...

I will continue to use SPRY for my tabular data (as there is no match out there) but I'm not going to wait for Spry to add features like a lightbox, progressbar, textarea autosize or drag and drop sorting.

I'm exreamly disapointed. This is just like ADDT, get all out hope up, then nothing. Now I know how my wife feels...

Allow me a little stand up for the project. I understand development is not only to add new widgets, but optimization. It is also necessary to prepare a complete set of documentation and usage examples. What is also important. And that's not all. The close integration with other products of Adobe. I agree on some issues. Not enough features lightbox, resize textarea, upload file, etc. But very much hope that the developers will listen and make efforts in this direction. Special thanks to V1 for assistance in solving problems, Massimo, and everybody who wants to help newcomers. Sorry for my English. Google translate:)

Kin and I have too been frustrated by our lack of time to commit to the process.

As you probably know, we work on the Dreamweaver team as well and that always takes a priority.

We are both bummed that we haven't been able to put out 1.7 in a timely manner.

Due to the usual rules, I can't give details about many of our plans and that leads me to give you positive but likely unsatisfying news.

We are working on plans to strengthen Spry and align it with other projects in Adobe. This will allow us more time to work on Spry.

We are aware of jQuery's defacto dominance of the Ajax market and we are also aware of the strengths of Spry (data for instance).

We are investigating new ways of putting widgets together and making them more flexible and skinable. We are also throwing around ideas for Spry/jQuery interactions. Nothing solidified yet but we are looking at things.

This means that Spry is not dead. We are working on things that we hope will be interesting and innovative.

It also means that we can't really give a roadmap for Spry. I am hoping that for the near future, we will be able to release some new things as we perfect them: smaller periodic releases that let's us keep innovating and let's you know that we are investing in the framework.

We thank you for your patience and continued interest in our project. And we thank V1, Massimo and the others that have continued to invest time and effort into this forum. Kin and I still read frequently and post when we can but we are also pleased that the forum is self sustaining pretty well, as a good forum should.

We welcome these sorts of threads and we do discuss them internally. We have tried from Day 1 to be responsive to your wants and as always, we appreciate the feedback.

I'm very happy that Spry is 'Not Dead' and that development will still progress, but at the same time sad that it's not getting attention it deserves by Adobe.

As far as I can see Spry is a crucial part of Dreamweaver's future, so I don't see it lacking attention. But we have definitely a visibility problem. The team isn't allowed to talk about the roadmap, leaving us in the cold... A very uncomfortable situation, both for Spry's team and the users community.

There comes a point where you have to look elsewhere for products that keep up with technology and serve the user. If Spry is not updated soon it will go the same way as ADDT, and we all know what happened there.

Spry is dying. If Adobe were serious about this as a product it wouldn't be leaving on the back burner from 1 1/2 years. Just look at the Flash, Flex, Air products and you'll see where the REAL development is being focused.

Time to look at the leaders not the followers. Adobe Spry isnt even managing to follow - a year and a half of stagnation on the web is a lifetime - and Spry looks like an old age pensioner wearing the occasional baseball cap (widget) to try and look cool.

Words and best wishes from the developers are great, but after such a long time without development, only prompt action will prove SPRY is worth consideration for on going and future projects.

If Adobe leaves a product from more than a year without development that means only one thing - the product is either unworthy of development, or, indeed, it is dying.

I must put some to this topic too, our team using Dreamweaver for website developing, thrust or not in old asp vbs :-).

Spry integration is very good step but spry developing is slow, im for spry is dying, no roadmap no public testing environment (svn) no clear bugtracer.

All this things make jquery better, but spry have big potential have adobe and his products AIR, just make some work on spry, or if spry team have not free, people which using spry can work on it. Just make environment or connection..

When developers thing spry is dead, will not continue use it, then spry die.

I think some of the comments that have been made here are more out of frustration than a genuine desire to see Spry come to an end. I for one am incredibly appreciative for all the work that the Spry team has done to provide a good foundation for a great, easy-to-use framework that doesn't come with all the overhead and bloated plug-ins, add-ons and who-knows-what that characterizes some of the other, more mature frameworks out there.

The frustration I see from people is, I think, based on a deep desire to see this project continue, realizing the potential that is clearly evident in what is currently available.

So rather than us all wringing our hands, wondering and venting about when updates will continue (and I'm plenty guilty of this...), perhaps we should be asking the Spry team what we--as the Spry community and developers who are committed to its success--can do to help.

I mean, many of the peices of a well-developed framework are here. Instead of waiting around for updates, perhaps we should be developing our own widgets and packages that can be shared in the community. This is what happens all the time for other frameworks--why not for Spry? Sure, there are some key components that still need to be developed from the top down, but there is plenty that can be done in terms of creating eye-candy that will lure in other users. The more that the community can develop to add-on to what has been provided, the better the reception will be. And as more people use it, perhaps Adobe will see the value in allocating more resources to developing this further.

If we are content, however, to merely sit around while already busy Adobe developers try to find the time to give us more cool toys to play with, then Spry probably is dead.

So rather than us all wringing our hands, wondering and venting about when updates will continue (and I'm plenty guilty of this...), perhaps we should be asking the Spry team what we--as the Spry community and developers who are committed to its success--can do to help.

Without a public code repository, bugtracker and roadmap, there is very little the community could do. Spry has an open source license, but its developing model is completely closed. I already did some work with extensions and add-ons for Spry (see my website). But since all the developing happens behind closed doors, people from the community can't contribute, unless we fork, but that's an option I wouldn't consider (not at this stage at least).

I don't think anyone would want SPRY to 'die' - but it is getting to the point in time where it seems rather pointless having it as part of the DW application. If the very job its supposed to do, and technology its supposed to lead, is handled in a more comprehensive and developer friendly way by third parties, it WILL die through neglect.

DW needs all the help it can get - with Server Behaviours that mostly go back unchanged since Macromedia DW MX and the demise of the ADDT, the current version of DW now looks more like a glorified code prompt and Interface for Adobe's Incontext Edting Service than a true web development environment/tool.

BTW - look how many hits this thread is getting - Adobe, I think your users are desperately trying to tell you something. I'm at the point where I'm looking at YUI and JQuery rather than SPRY. The developers need to step up to the plate or pack up shop.

Kin and I have too been frustrated by our lack of time to commit to the process.

As you probably know, we work on the Dreamweaver team as well and that always takes a priority.

We are both bummed that we haven't been able to put out 1.7 in a timely manner.

If I may ask, why isn't there a seperated Spry team than? Iknow Spry is just a small part of Dreamweaver, but I think the future of DW might even depend on a good rock solid ajax framework. Especially after I had seen "Atlas" from 280 North. It could be come an hard punch for Adobe.

We are investigating new ways of putting widgets together and making them more flexible and skinable. We are also throwing around ideas for Spry/jQuery interactions. Nothing solidified yet but we are looking at things.

Please, do not use the jQuery syntax. Its one big reason why I absolutely hate the framework sure the code base is allright but It almost make all code unreadable. do().stuff().here().and().try().to().de().bug().my().issue("please").dont().you().love([" chaining",functions(like,this){alert("no")}]);

This means that Spry is not dead. We are working on things that we hope will be interesting and innovative.

It also means that we can't really give a roadmap for Spry. I am hoping that for the near future, we will be able to release some new things as we perfect them: smaller periodic releases that let's us keep innovating and let's you know that we are investing in the framework.

I already knew this, but I'm still happy when I see you posting this . I love Spry and use it on a daily basis both personal and in an enterprise enviourment.

As far as I can see Spry is a crucial part of Dreamweaver's future, so I don't see it lacking attention. But we have definitely a visibility problem. The team isn't allowed to talk about the roadmap, leaving us in the cold... A very uncomfortable situation, both for Spry's team and the users community.

Massimo

Yeah, so true. But I would also love to see it intergrated in to ColdFusion as default ajax framework . And I fully agree on the visibility problem. I'm in a team of 10 programmers at work. And they are like what is the Spry Framework you are Community Expert in. +_+" ofcourse after few slaps and presentation they where up to date..

But I think this is mainly because all "major" frameworks aren't as issolated as Spry currently is. Typing in jQuery.com is allot easier than labs.adobe.com/technologies/spry and even than the information presented is minimal and requires further investigation to find the info that you want. It might even bee in 5 different locations, API, Samples, LiveDocs, Articles or Devnet and if you are unlucky its not even there at all.

The frustration I see from people is, I think, based on a deep desire to see this project continue, realizing the potential that is clearly evident in what is currently available.

I agree on that point.

I mean, many of the peices of a well-developed framework are here. Instead of waiting around for updates, perhaps we should be developing our own widgets and packages that can be shared in the community.

There are already a few people doing that. Me and Massimo for example have both released some widgets for Spry. And I'm still working a few widgets that will be "released" soon. Such as JSONP support for the SpryJSON dataset this will allow us to some crossdomain JSON requests etc..

Sure, there are some key components that still need to be developed from the top down, but there is plenty that can be done in terms of creating eye-candy that will lure in other users.

Theres actually allot that can be reused, SpryDOMUtils.js and the SpryEffects.js provide almost for what is needed to created custom widgets on your own. A example is an article series the i created for insideRIA:

Without a public code repository, bugtracker and roadmap, there is very little the community could do. Spry has an open source license, but its developing model is completely closed. I already did some work with extensions and add-ons for Spry (see my website). But since all the developing happens behind closed doors, people from the community can't contribute, unless we fork, but that's an option I wouldn't consider (not at this stage at least).

Massimo

Yeah its such a shame that Spry isn't listed at opensource.adobe.com It would be a great candidate for it. And I would love to provide some patches to existing issues in the framework. But the closed development is kinda blocking that as we have no clue what Spry team is doing. Same thing actually counts for widgets. It would be a waste of time if we as 3rd Party developers started creating a Spry syntax based Drag and drop addon and the Spry team is working on the same over at the jQuery UI framework you can see in there wiki what they are working on.

BTW - look how many hits this thread is getting - Adobe,

Its been retweeted a couple times on twitter .

Anyways I will always be on Spry side what ever it will do, I absolutely love the framework and will not swap for any other. (yes even when they decide to implement().chaining().in().the().whole().framework())

More and more people keep migrating into JQuery this day... I was the one who one to migrate too, but the stupid chaining syntax examples on all over internet keep piss me off JQuery... Isn't there any "usual" ways to code in JQuery? Something that newbie friendly? Instead $(JQuery).i(really).hate(this).writing(styles)

And i still wait for 1.7 (pre)release...

Btw V1, how about Spry-it.com? When will it finally launch? I Hope it more community/wiki style so we can contribute our past experiences with Spry...

Oh yeah last time i see was someone create calendar widget for Spry (http://sprycalendar.riaforge.org/)And Massimo has released some nice plugin there, then why we didn't create any others? Sorry i'm not that experience :D, but it would be good if we can see some nice addition such as progress bar or modal box (lightbox?)

And Massimo has released some nice plugin there, then why we didn't create any others? Sorry i'm not that experience , but it would be good if we can see some nice addition such as progress bar or modal box (lightbox?)

As I said earlier in this thread, Spry is developed behind closed doors, it's not open to contribution outside Adobe. This doesn't prevent thrird party to build on top of it, but it doesn't help either. A public roadmap is missing too, that's another thing that drives third party away.

A modal dialog is the widget I miss the most, but it requires at least solid drag & drop capabilities that are missing from Spry right now. Doing such a widget from scratch would be a monumental task.

I'm afraid my project has been delayed once more. My son got taken to the hospital last month, and he still has to stay for at least one month more.

Also one of my co- creators stepped out the project so I got to do all the work my self now.

Anyways I took the day off today so I can fully focus on the project and getting some thing done, such as the design of the page. One of the things I wanted to supply is a complete and searchable API. The current Spry API only covers the base of it. And some vital information can only be found in the articles, some isn't even documented for example how many people do know that the SpryDOMUtils css selectors are also chainable?

So we can do Spry.$$('div.cookies').setStyle().forEach(function(n){n.innerHTML += 'O dear, the awfull unreadable syntaxes has been implemented';});

I personally hate chaining I have been using this pattern that makes it a bit more readable:

And Massimo has released some nice plugin there, then why we didn't create any others? Sorry i'm not that experience , but it would be good if we can see some nice addition such as progress bar or modal box (lightbox?)

As I said earlier in this thread, Spry is developed behind closed doors, it's not open to contribution outside Adobe. This doesn't prevent thrird party to build on top of it, but it doesn't help either. A public roadmap is missing too, that's another thing that drives third party away.

A modal dialog is the widget I miss the most, but it requires at least solid drag & drop capabilities that are missing from Spry right now. Doing such a widget from scratch would be a monumental task.

Sure it would be a big task, but its do able with the current functions they provide us. For example, did you know the SpryDebug.js window is dragable? Sure it might not be rock solid drag drop functionality but It is drag and drop functionality (http://labs.adobe.com/technologies/spry/samples/utils/debugger_demo.html). And it could be easily applied to a widget.

The rest of the widget could be created using Spry Effects for background fading, and effect for the popup it self. And SpryDOMUtils for eventlisteners and the css selector to target rel="SpryModal" links etc.

Sure it would be a big task, but its do able with the current functions they provide us. For example, did you know the SpryDebug.js window is dragable? Sure it might not be rock solid drag drop functionality but It is drag and drop functionality (http://labs.adobe.com/technologies/spry/samples/utils/debugger_demo.html). And it could be easily applied to a widget.

I personally wouldn't use that since other frameworks provide solid, proven alternatives.

There is also the issue of not having a public roadmap, we don't know if the Spry's team is working on something like that already, or plan to do it in the future. Lacking any kind of visibility about what's going on behind the doors means third party face the risk of duplicating efforts. I can live with that risk if I work on something simple, not if I have to work on complicated, time-consuming stuff.

Sure it would be a big task, but its do able with the current functions they provide us. For example, did you know the SpryDebug.js window is dragable? Sure it might not be rock solid drag drop functionality but It is drag and drop functionality (http://labs.adobe.com/technologies/spry/samples/utils/debugger_demo.html). And it could be easily applied to a widget.

I personally wouldn't use that since other frameworks provide solid, proven alternatives.

There is also the issue of not having a public roadmap, we don't know if the Spry's team is working on something like that already, or plan to do it in the future. Lacking any kind of visibility about what's going on behind the doors means third party face the risk of duplicating efforts. I can live with that risk if I work on something simple, not if I have to work on complicated, time-consuming stuff.

Massimo

Yeah a solid alternative would make allot of new widget possible, modals, sliders, list sorting etc. I was pointing out that It would be possible to create something like that.

And about the road map, that is exactly what is holding me back from fully working on third party widgets. I got a few widgets on my wish list that are just basically waiting to be created. I know exactly what you mean, we want to provide something for the community but it would be useless if all our invested time would go to waste when the Spry is releasing similar widgets.

But sometimes its worth it, for example I was in need for JSONP support in the JSON dataset. I can't go sit and wait for the Spry team to implement such a feature, after a hours of fiddling I found a solution (Had some issues with the Spry class Model, I had to edit the HTTP data set class to make this working.

One thing I would love if we could submit patches and features to the framework it self, for example your data set extensions should be add by default in the Spry Data. It will make certain jobs allot easier. Same could count for JSONP support etc.

But sometimes its worth it, for example I was in need for JSONP support in the JSON dataset. I can't go sit and wait for the Spry team to implement such a feature, after a hours of fiddling I found a solution (Had some issues with the Spry class Model, I had to edit the HTTP data set class to make this working.

If it's something that you can't find outside Spry you have to go that route. I've been there myself.

But when I had to use iframes inside modal dialogs I started elsewhere:

One thing I would love if we could submit patches and features to the framework it self, for example your data set extensions should be add by default in the Spry Data. It will make certain jobs allot easier. Same could count for JSONP support etc.

Among other things I would love to add proper time-out support for the XHR calls. Spry is one of the few frameworks still missing that crucial feature. It's not a big task, I've done it already internally, but there isn't a way I can easily share that with the community.

Open the code base to external commiters would be great, but I understand it's complicated. Right now even just a public roadmap would make me happy

Adobe seems focused on Flash. Period. Especially now that MS is hot on their heels with Silverlight. I've assumed Spry is dead. And moved to jQuery already. In fact, I wonder why I even use Dreamweaver now. I mean it's an expensive text editor.

I think now is the time for developers to submit something new ... even at the stage of testing. And to show that the SPRY alive. Sam looks forward to good news. SPRY primarily focused on beginners and gives them a chance to quickly build their applications.

cragthehack wrote:

ADDT also had a cost. Spry does not. So that is a big difference.

Adobe seems focused on Flash. Period. Especially now that MS is hot on their heels with Silverlight. I've assumed Spry is dead. And moved to jQuery already. In fact, I wonder why I even use Dreamweaver now. I mean it's an expensive text editor.

I do not want to know how the mechanism is designed electronic clock, I just want to know who is now time:)

I think now is the time for developers to submit something new ... even at the stage of testing. And to show that the SPRY alive. Sam looks forward to good news. SPRY primarily focused on beginners and gives them a chance to quickly build their applications.

cragthehack wrote:

ADDT also had a cost. Spry does not. So that is a big difference.

Adobe seems focused on Flash. Period. Especially now that MS is hot on their heels with Silverlight. I've assumed Spry is dead. And moved to jQuery already. In fact, I wonder why I even use Dreamweaver now. I mean it's an expensive text editor.

I do not want to know how the mechanism is designed electronic clock, I just want to know who is now time:)

Adobe is a huge company with huge assets - if it can't show a small part of its product line is actively being developed for such a long time - we can come to only one conclusion - is must be dead or dying.

Whichever way you look at it - its currently not a safe platform to develop future projects.

Does it matter? Spry lets me do stuff easily. If I need to go further I would probably just use JSP.

I would like to thank users here for their help getting me up to speed with Spry. I have used it on several sites and am happy with the current feature set.

Examples:

I used a php/js thing called "Topics anywhere" to grab the last 10 posts off a phpbb2 forum and show them on another web page. Unfortunately a phpbb3 version of this isn't available so I duplicated the effect with a Spry XMLData feed. http://www.bateau2.com

I think the future of Spry is to go Open Source, and let the community

help shape its future.

The only way to go this route would be to fork the current codebase. I don't

think this is a viable option at the moment since the amount of non-Adobe

developers and potential contributors is too small.

It's kind of a chicken-egg situation, since Spry doesn't follows an open

development model we don't have many third party developers. Since we don't

have third party developers, any attempt to fork would be doomed

Massimo

So unless Adobe get there collective arse into gear, Spry is doomed? I am sure it will still be used in its current form, but it would be great to see some news, or tit bits of information, just to reassure us that something is happening.