Spry... prospector or real gold?

Question

OK... when will SPRY go solid gold? It seems over due now.
Missing currently "for my development needs":
Great docs on event integration
(granted, spry was built for designers... but in the end this needs
to be documented because design alone doesn't get the job done
enough of the time. Either that or we need to depend on another
library.)
Spry still needs the type of things
in the EXT library (editable grids that work with the
server).
Again, this is just based on my needs. It seems a bit
frustrating to me that CF is heading one direction with AJAX and
that one direction isn't SPRY. There may be business reasons for
that... but logistically that also means there are business reasons
to think twice about using the AJAX in CF if we believe SPRY is the
road to take. This is confusing with ref. to the long term goals
Adobe has for SPRY.
Could you give us a clarification on the "business use case"
for SPRY?

Answer 1

Hey John,
I was going to blog about this stuff next week, but I can
expound on some topics here.
First, we decided to push off on a gold release for now. We
have a high level of confidence in our code as it stands,
understanding that there are some known issues to solve and
enhancements to make.
But we still feel that there are some features we want to add
before we can call it gold on a conceptual level.
We want to add more options for unobtrusive js, including CSS
selector utils and more HTML fragment integration. We have those
features in progress now.
Stability-wise, people have been using Spry in production
environments for some time now, and that is a good sign..
So the current plan is to release 1.6 in a few months and
then think about a gold release.
As for your feature wish list, can you give examples of the
event integration you are looking for and feel that is lacking?
I am continuing to add to the API as we speak and am always
looking for document suggestions.
We do need more real-world samples that show working with the
server, as you mention. The ability is there, but we need to show
it off a bit more.
With CF8, there is some nice Spry integration, but they are
also using YUI for some things. This as to do with CF's needs and
also the state of Spry during their development cycle. We are
working with the CF team and wished we had more time to get more
Spry features in there. There were simply things that they wanted
that Spry didn't have at the time. Remember that software releases
need long lead times before the public sees them. We were working
with the CF team last fall, when Spry was only a few months old...
We expect integration to grow as both products progress.
As for the business use case, that depends on your business.
Our goals are to make Ajax accessible to designers, at the
same time, creating a toolkit that can be leveraged by developers.
It's been gratifying to see CF users adopt Spry as quickly as they
have.
I see it as our task to make a framework that is innovative
and easy to use, that fits the needs of web designers and
developers.
Whether Spry is right for your scenario, that is up to you. I
want to make sure that you have the features and documents in order
to make that decision clearly.
And you, John, have been an early and active member of the
Spry community, and we thank you for that and for bringing up
big-picture questions like this.
Let's continue this discussion.
Don