Skip navigation

Is Spry dead?

Apr 18, 2009 3:40 AM

  Latest reply: daslicht, Jun 20, 2012 1:35 PM
Replies 1 2 Previous Next
  • Currently Being Moderated
    Jun 12, 2009 3:15 AM   in reply to Massimo Foti

    I don't think Spry is doomed, not at all. I am willing to bet there is some serious developing efforts behind it, because Spry is a crucial part of Dreamweaver. Problem is that effort isn't visible, and, at this point, I am afraid it's not going to get better until next Dreamweaver's release will hit the street.

     

    I think one of the problems is that the Spry team is part of the Dreamweaver team. So there time is also spend in Dreamweaver instead of a full focus on Spry. Other JavaScript frameworks purely focusses on the Framework not the applications that comes with it

     

    I am 100% sure Adobe see real value in Spry, since it has been one of the

    very few innovations in Dreamweaver's recent history. Most likely Adobe

    doesn't see any value in investing in Spry as a stand alone Ajax framework,

    outside of Dreamweaver, and that's a shame. Of course we all know Spry

    doesn't generate any revenue as a stand alone project, and we all know what

    really matters in the enterprise world. I still think it's a shame, because

    all that we need and keep asking for is just more comunication.

    Well as stand alone project it could drive more developers to the project, making it bigger and new widgets would be created. That could again make its way back to Dreamweaver. Spry has allot of enterprise potential but I doubt Adobe wants to market such way.

     

    Please note all the above is just pure speculation on my side, I don't have

    access to any inside information, I am in the same boat as everybody else.

    So I may be totally wrong!

     

    Massimo

    I'm on same ship. I might have a expert status but that doesn't mean I got access to some hidden source of information. (sometimes I wish I did)

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 12, 2009 3:18 AM   in reply to Massimo Foti

    coldfusion.lugano wrote:

     

    One thing that could help out Spry in its development is if they where to

    release its code base on opensource.adobe.com.

     

    Amen brother. That would be great. But I don't see it happening any time

    soon

    I do wonder what the Spry team thinks of that. (hint, hint, we know you guys are reading this )

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 12, 2009 3:24 AM   in reply to Arnout Kazemier

    I am sure they have some widgets up there sleeves, but I would love to know whats really going on.

     

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 12, 2009 5:08 AM   in reply to Arnout Kazemier

    I do wonder what the Spry team thinks of that. (hint, hint, we know you

    guys are reading this  )

     

    I am afraid the Spry team is in a position where they can't even comment

     

    Massimo

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 12, 2009 6:05 AM   in reply to Massimo Foti

    I'm afraid you are right about that, I guess we just have got to wait until Adobe / Spry / Dreamweaver shines some light on this matter.

    Personally I cannot wait to submit some patches.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 12, 2009 6:10 AM   in reply to Arnout Kazemier

    I guess we just have got to wait until Adobe / Spry / Dreamweaver shines

    some light on this matter.

     

    In the meantime plenty of people will keep declaring Spry as dead... And

    there is very little we can do about it

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 12, 2009 10:55 AM   in reply to Kevin 05

    Let us look at this issue to the company Adobe. Maybe they can clarify the situation
    For example the Microsoft did not hesitate to speak to the masses and to answer their questions.

     

    I am sure I want to receive information about the fate of SPRY much more than those who said in this topic.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 17, 2009 8:26 PM   in reply to Arnout Kazemier

    Hi V1,

     

    I didn't want to jump into here but I needed to correct you on a point you made here:

     

    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")}]);

     

    You make it sound as if the jQuery syntax can only be coded in a chaining format which is incorrect. Chaining is meant for convenience, hence the reason that so many libraries support it.

     

    It's extremely easy to break out

     

    $("div").css("background", "#b4b0da").append("<b>Hi Spry</b>");

     

    to something like this:

     

    var foo = $("div");
    foo.css("background", "#b4b0da");
    foo.append("<b>Hi Spry</b>");

    It's really up to your personal preference but it's not a requirement to do massive chaining to successfully
    use jQuery. I'd like to ensure that other readers understand this.

    Rey
    jQuery Team


     
    |
    Mark as:
  • Currently Being Moderated
    Jun 18, 2009 5:12 AM   in reply to BangoMan

    Hello Rey Bango,

     

    I'm well aware of the fact that you format a chained function in different ways. Making it more readable.

    But not everybody uses it in that way, I have seen countless of scripts doing().chaining().like().this()

    Probably because you have to write less lines, so sure it can be a convenience but what convenience is for

    one, can still be nightmare for others.

     

    I have nothing against the chaining principle, but when people starts to "abuse" the syntax to create this

    unreadable piles of chained code, I might get a little bit wonky ;). But that is my personal opinion.

     

    It wasn't a personal attack on the jQuery framework. It was a rant about the chaining syntax that was jQuery

    helped to make populair. It's not a requirement to do massive chaining to successfully use jQuery but its

    "advertised" by jQuery to do so, as examples are listed in that way. Even the "learn jquery" on front page

    uses this. Not just the jQuery website but also third party communitys.

     

    So once again, its not an attack on the jQuery framework it self. Its code base is great and I have nothing

    against that, its about the syntax that its users produce in result of using the jQuery framework.

     

    But I think its wise to keep the rest of this discussion off lists before we clutter this topic with offtopic messages.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 18, 2009 8:21 AM   in reply to Arnout Kazemier

    HI V1,

     

    No need to be so formal. You can call me Rey.

     

    We do advertise it and many developers do love it. It comes down to personal preference and with jQuery, we give you that flexibility.

     

    As long it's clear that chaining is not a requirement, then we can move on.

     

    Cheers,

     

    Rey

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 18, 2009 9:32 AM   in reply to BangoMan

    I use jQuery and I don't chain. I think it's not easily readable.

     

    But the above is right. You don't have to chain. But it's expected that you do. And that's cool. But it does make it harder for newbs or someone who doesn't chain to read the code.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 22, 2009 8:09 PM   in reply to Kevin 05

    I thought I would pipe up for what its worth.

     

    I came to this forum on Saturday (two days ago) and was going to ask a question but bumped into this thread.  It echoed questions I already had.

     

    I'm a ruby on rails freak and so I use prototype and scriptaculous mostly.  I tried to plop spry into RoR about six months ago and I took a wrong turn early on.  I learned a lot but that particular attempt died.

     

    This weekend, I tried again and succeeded.  In about 4 hours I turned on page into using spry.  It is using the region and repeat features in particular.  The web server has a very large database and the page is essentially just a table presenting the results of a query.  I say basically because after the basic table, I needed links in most of the entries.  Then I needed a right click feature.  Then, etc... So I puttered and toyed all weekend.  Prototype is still in my code so I'm using both packages.  Perhaps an all Spry solution is possible but it would not benefit me to remove prototype completely.

     

    I've looked at but not really used JQuery as well as YUI version 3.  Spry has a few special affects and other eye candy that the others do not have but the reverse is also true.  What spry has that the others do not have (at least, I haven't found them implemented in the base product) are Spry's region and repeat facilities.  Spry is also one of the view (perhaps only) that implements the concept of implementing the view in the browser.  The server effectively has no view processing at all when using Spry.  This *is* the future.  But there are clearly some twists and turns ahead.

     

    For example, to sort the table using the tablesort.js file found on the net is just as easy and much more flexible.  There is no way to define a custom sort method.  The function:: method needs to be able to take arguments.  etc etc.  So, while I found implementing the table and that part to be super cool and easy, I found many other things awkward.

     

    But it gets worse.  I was testing on a table with 10 or so entries.  When I test on a table of 1800 entries (rows), it takes firefox on a Mac book pro 2.33GHz Intel Core 2 Due a half a minute to render the page.  Firefox gets pretty upset with this and flashes the "Golly this javascript is taking a long time" message.  And, to top that off, if you do that just a few times, Firefox becomes really doggy for everything.  Perhaps this is some firefox issues but it leads to the need for more features.  Perhaps it is already there but there needs to be an "endless page" type facility where the page is filled out as the user scrolls through it.  I did not see any mention of this in the documentation I looked at so far.  This seems pretty basic to me.

     

    One comment in this thread is that Spry is needed for Dreamweaver.  Admittedly I do non-normal web development but I've tried to use DW in my Rails projects and it is just too awkward and clumsy.  In what is very normal Adobe fashion, there are a lot of options that are not really documented unless you are doing exactly what those features are intended to do.  I don't use Cold Fusion.  I have no idea what it is really.  Nor have I used any of the other backend server DW "supports".  Don't tell me about particular backend server technologies that are likely to be obsolete in a few days.  Tell me how to get DW to work with my server that I have today right now.  It seems so basic too.  I should be able to teach DW how to make a query to any server with minimal work.

     

    So, I have my doubts about DW for the work I do.  And for the web sites that focus on mostly static content, what DW seems to focus on, those sites don't need Spry.

     

    In DW, I need to be able to completely draw out the page and make it look like I want it.  Only when I go into test do I need to actually point it to a server.  WIth DW, there is no way I can do that.  I can't put {field} into the web page and then design the look of the web page.  I need to be able to put dummy data as I edit the page.  Otherwise, I am just doing trail and error which I can do quicker / faster with emacs.

     

    Last, as others have already pointed out in this thread, Spry isn't open development. And given the state of the world, it is utter folly to think that some small team of people can keep up with true open source Javascript packages like JQuery, Prototype, and YUI.  Technically, as far as speed, robustness, and flexibility, Spry can not hold a candle to the others at this point.  And a closed team of people are never going to catch up with projects driven by a vibrant open source community like all of the other major Javascript packages have at this point.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 23, 2009 2:28 AM   in reply to Perry Smith
    But it gets worse.  I was testing on a table with 10 or so entries.  When I test on a table of 1800 entries (rows), it takes firefox on a Mac book pro 2.33GHz Intel Core 2 Due a half a minute to render the page.  Firefox gets pretty upset with this and flashes the "Golly this javascript is taking a long time" message.  And, to top that off, if you do that just a few times, Firefox becomes really doggy for everything.  Perhaps this is some firefox issues but it leads to the need for more features.

     

    JavaScript it self isn't really build to handle such large chunks of data. Its not really a Spry thing. If you are in need of handling such large amounts of data client side. It wise to do some pre - filtering and sorting client side.

     

    Perhaps it is already there but there needs to be an "endless page" type facility where the page is filled out as the user scrolls through it.  I did not see any mention of this in the documentation I looked at so far.  This seems pretty basic to me.

     

    Spry has the paged view class for that. Its metioned in the samples and API:

    http://labs.adobe.com/technologies/spry/articles/pager/index.html

     

    One comment in this thread is that Spry is needed for Dreamweaver.  Admittedly I do non-normal web development but I've tried to use DW in my Rails projects and it is just too awkward and clumsy.  In what is very normal Adobe fashion, there are a lot of options that are not really documented unless you are doing exactly what those features are intended to do.  I don't use Cold Fusion.  I have no idea what it is really.  Nor have I used any of the other backend server DW "supports".  Don't tell me about particular backend server technologies that are likely to be obsolete in a few days.  Tell me how to get DW to work with my server that I have today right now.  It seems so basic too.  I should be able to teach DW how to make a query to any server with minimal work.

     

    So, I have my doubts about DW for the work I do.  And for the web sites that focus on mostly static content, what DW seems to focus on, those sites don't need Spry.

     

    (small side note on this, Aptana Studio also provides for Spry)

     

    In DW, I need to be able to completely draw out the page and make it look like I want it.  Only when I go into test do I need to actually point it to a server.  WIth DW, there is no way I can do that.  I can't put {field} into the web page and then design the look of the web page.  I need to be able to put dummy data as I edit the page.  Otherwise, I am just doing trail and error which I can do quicker / faster with emacs.

     

    You got CS4's live view and live code for that. It renders your page just like any other browser would do.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 23, 2009 5:43 AM   in reply to Arnout Kazemier

    .V1 wrote:

     

    But it gets worse.  I was testing on a table with 10 or so entries.  When I test on a table of 1800 entries (rows), it takes firefox on a Mac book pro 2.33GHz Intel Core 2 Due a half a minute to render the page.  Firefox gets pretty upset with this and flashes the "Golly this javascript is taking a long time" message.  And, to top that off, if you do that just a few times, Firefox becomes really doggy for everything.  Perhaps this is some firefox issues but it leads to the need for more features.

     

    JavaScript it self isn't really build to handle such large chunks of data. Its not really a Spry thing. If you are in need of handling such large amounts of data client side. It wise to do some pre - filtering and sorting client side.

     

    Perhaps it is already there but there needs to be an "endless page" type facility where the page is filled out as the user scrolls through it.  I did not see any mention of this in the documentation I looked at so far.  This seems pretty basic to me.

     

    Spry has the paged view class for that. Its metioned in the samples and API:

    http://labs.adobe.com/technologies/spry/articles/pager/index.html

     

    One comment in this thread is that Spry is needed for Dreamweaver.  Admittedly I do non-normal web development but I've tried to use DW in my Rails projects and it is just too awkward and clumsy.  In what is very normal Adobe fashion, there are a lot of options that are not really documented unless you are doing exactly what those features are intended to do.  I don't use Cold Fusion.  I have no idea what it is really.  Nor have I used any of the other backend server DW "supports".  Don't tell me about particular backend server technologies that are likely to be obsolete in a few days.  Tell me how to get DW to work with my server that I have today right now.  It seems so basic too.  I should be able to teach DW how to make a query to any server with minimal work.

     

    So, I have my doubts about DW for the work I do.  And for the web sites that focus on mostly static content, what DW seems to focus on, those sites don't need Spry.

     

    (small side note on this, Aptana Studio also provides for Spry)

     

    In DW, I need to be able to completely draw out the page and make it look like I want it.  Only when I go into test do I need to actually point it to a server.  WIth DW, there is no way I can do that.  I can't put {field} into the web page and then design the look of the web page.  I need to be able to put dummy data as I edit the page.  Otherwise, I am just doing trail and error which I can do quicker / faster with emacs.

     

    You got CS4's live view and live code for that. It renders your page just like any other browser would do.

    (Sorry to quote the whole previous reply -- I couldn't figure out how to snip it into pieces)

     

    Hmm... I SO want to be able to use DW or something like that.  I have CS3 and I posted and posted on various Ruby / Rails forums asking if anyone had successfully used DW with Rails and everyone told me to not walk but run away.  (CS4 came out maybe a week after I had done all this investigation.)

     

    Really, I don't want to use DW myself.  I can't design pages that I like.  But my son can (and obviously others can).  I want them to be able to design the page while I work on the backend stuff.  With my son as an example, I couldn't find a way to do that well given his knowledge and skill set using CS3.

     

    And... another obstacle was me not knowing DW.  The two universes seemed too far apart at the time.

     

    The referenced pager feature of Spry is at least close to what I was looking for.  Thank you for the pointer.  I figured it was there somewhere.

     

    Also, I posted a note to the Prototype google group.  One reply mentioned using innerHTML rather than dom manipulation to add elements.  The sample test page with 1800 rows went from 30 seconds to render using DOM manipulation to 300ms.

     

    If you are curious, the thread is here:

    http://groups.google.com/group/prototype-scriptaculous/browse_thread/t hread/f25924d94f321f08

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 23, 2009 9:55 AM   in reply to Perry Smith

     

    (Sorry to quote the whole previous reply -- I couldn't figure out how to snip it into pieces)

     

    Hmm... I SO want to be able to use DW or something like that.  I have CS3 and I posted and posted on various Ruby / Rails forums asking if anyone had successfully used DW with Rails and everyone told me to not walk but run away.  (CS4 came out maybe a week after I had done all this investigation.)

     

    Really, I don't want to use DW myself.  I can't design pages that I like.  But my son can (and obviously others can).  I want them to be able to design the page while I work on the backend stuff.  With my son as an example, I couldn't find a way to do that well given his knowledge and skill set using CS3.

     

    And... another obstacle was me not knowing DW.  The two universes seemed too far apart at the time.

     

    The referenced pager feature of Spry is at least close to what I was looking for.  Thank you for the pointer.  I figured it was there somewhere.

     

     

    Also, I posted a note to the Prototype google group.  One reply mentioned using innerHTML rather than dom manipulation to add elements.  The sample test page with 1800 rows went from 30 seconds to render using DOM manipulation to 300ms.

     

    If you are curious, the thread is here:

    http://groups.google.com/group/prototype-scriptaculous/browse_thread/t hread/f259 24d94f321f08

    Have you checked out the http://rubyweaver.gilluminate.com/features/ plugin? It might be worth checking out.

    When there are things that DW can't handle. Perl, Python, RoR i always use Aptana Studio. And they always mix fine for me.

     

    Also, I posted a note to the Prototype google group.  One reply mentioned using innerHTML rather than dom manipulation to add elements.  The sample test page with 1800 rows went from 30 seconds to render using DOM manipulation to 300ms.

     

    If you are curious, the thread is here:

    http://groups.google.com/group/prototype-scriptaculous/browse_thread/t hread/f259 24d94f321f08

    Spry uses .innerHTML to insert the data (if you check out the SpryData.js file you will see that it uses the Spry.Utils.setInnerHTML() function.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 24, 2009 12:22 AM   in reply to Kevin 05

    @V1 -

     

    "You got CS4's live view and live code for that. It renders your page just like any other browser would do."

     

    ...but it only supports the WebKit Engine.  (Safari/ Chrome)

     

    You won't be able to test for the Gecko or Trident Engines. (FF or IE)

    _

     

    @Perry Smith -

     

    The SPRY Framework is not reliant on DW or vice-versa - they are both stand alone projects that can integrate with each other.  Massimo had a valid point saying that SPRY is a crucial part of DW - but more to the point that it is a crucial extension of DW's capabilities.  As - maybe at a future point in time "the web experience" migrates to something new and unrelated and AJAX "tech" becomes deprecated.  As the user web experience is more and more in demand of AJAX (and similar) capabilities online.  Adobe simply would be remiss to not support it.

     

    You can use DW with pretty much any Framework.  I've used Prototype and Scriptaculous for several things.  I know MooTools and JSON have no problems.  I don't know much about RoR but seeing as how it integrates with Prototype and Scriptaculous there shouldn't be much issue using it in DW.  I guess it's an alternative to PHP and ASP?  Those work great in DW as well.

    _

     

    I do think that partly why the SPRY project is not at Adobe's Open Source Site is simply because that still have it stuffed in the Labs as a Beta.  Maybe this will change when/ if it comes out of Beta ever?  Seems like they are taking a cue from Google here and keeping a stagnant project in Beta for 4+ years now.

     

    People were mentioning that we haven't heard much of anything significant in 1.5+ years.  I have been following SPRY development at the Labs from the start. I would agree with those folks.  But my reasoning is this:  Adobe's own internal development cycle for pretty much anything is 18-24 months.  Over-hauling all of CS4 for 3 platforms (Mac PPC/ Intel and Win - I have my priorities :- )) is no small under-taking.  That's what 24+ serious titles X 3 (for all we know) during their normal development cycle.

     

    Not only did they do all of this - they had to make certain CS4 was stable and as bug free as possible before they started selling DVDs.

     

    But - the attention they have publicly given SPRY in the past year and a half is akin to Microsoft not updating IE6 for 5+ years AND notice I mentioned the normal Adobe project development cycle of 18-24 months? I said this because not only has Adobe claimed this over and over again in various public statements - but SPRY is hitting 18 months (or past).  And No! The JavaScript 1.7 Preview File they outed in Dec '08 does not count.  So they are pushing past their own timeframe - which nothing says they are not allowed to.

     

    But Microsoft woke up and and started developing IE rather actively again.  2 versions in 2 years - wish they'd bring back Mac support.  IF Adobe doesn't keep up with this in some fashion and at a better pace then Yes - the open-source projects - the technology and user interest are going to out-pace the company's own Framework.  And that keeps them in line with Microsoft making leaps every few years and trying to play catch up.

     

    There is no reason why Adobe cannot implement the SPRY Framework/ Dreamweaver tool set in the same fashion that Apple handles Safari and WebKit.  There is a steadily advancing open-source project that is the core of their web browser and any advancements made on WebKit are incrementally integrated into Safari at a regular pace.  Granted Safari is free - but it also incorporate much more than WebKit which is mostly proprietary.

     

    The Framework is already in place.  Could it be streamlined more - Yes.  Does it support "features" that are not currently available in the Adobe Release - Yes.  I know many people that have taken SPRY as a Springboard and modified the code to do what they want.  The point of a Framework is be a starting point.  Why re-invent the wheel when it's already there?  Take it and tweak - change alter and modify it to your will.

     

    Granted it sucks that if we want a SPRY Calendar or a SPRY Photo Gallery (akin to Lightbox) that we have to basically create out own.  But as I mentioned above with the interoperability of DW with some of the mentioned technologies - projects such as Lightbox can integrate just fine into a SPRY project with little effort.

     

    I think most of the ******** is coming from the fact that SPRY being integrated into DW like it is - people with lesser skills sets can now throw in some AJAX implementations without knowing how to code all that JavaScript.  Just drop it in a folder and link it up - maybe tweak a variable or 2.  But then they see all these new and crazy effects all over the internet and wonder why Adobe hasn't caught up.

     

    Someplace on an Adobe Blog I read where they were also working on a better solution to integrate SPRY into DW.  It talked about the Extension they released a while back that allowed us to update to 1.6.1 instead of having to manually place files inside of the Application (as we did going from 1.4.x to 1.5.x - that was fun).  Thank goodness for the extension.  But they also mentioned that the current method wasn't ideal.  As what the Extension did was act as a half-assed add-on.  IF you disable it DW CS3 reverted back to 1.5 or 1.4 (i can't remember).  And the active extension would only affect future projects made while it's active.  You'd still have to go back and convert (pain in the rear) old projects from 1.4/ 1.5 to 1.6.

     

    I don't agree with the way they're handling this.  Donald Booth above posting was commendable.  However - seeing as how the Forum for User interoperable support is not the official channel for News from Adobe or it's various Teams - it would have been nice to hear about this on the Official SPRY Blog.  As I am just now finding out about his message 2 months later.  I check the Blog Site regularly (that's what it's there for).  I didn't realize that I should have been instead scouring thru the User Forum trying to find an "un"-official message from a member of the SPRY team buried deep inside of a User complaint Thread.

     

    That's just stupid.  We're all adults here - there's no need to sugar coat it to be something that it's not.

     

    My question is this.  Why is the SPRY project open-source if the Team cannot discuss it as if it were an internal proprietary project (akin to Photoshop)?

     

    Go over to John Nack's Photoshop Blog:

    http://blogs.adobe.com/jnack/

     

    ...and skim thru some of the relevant commentary right before the release of CS4 - during when they had the PS Beta out.  He was mentioning many different aspects of what might or might not make it into the next release (CS4).  He even showcased some of them during a presentation prior to the Beta going public.

     

    Because That!  And the fact that Donald repeatedly mentions they haven't had time to work on SPRY - which is also mentioned on a Blog post at the SPRY Blog in October 2008 that they just finished CS4 - announcements for release and everything - you'd think they'd have time to mention something in the 8 months since.

     

    By contrast tho - logic dictates that they are 9 months into CS5 development.  So which is it?  The fact remains they are heading down the same path as Google and Microsoft before them.

     

    My problem is that I really like DW more and more with new releases.  It's convenient - easy - many options and features.  And I can go from a Design layout to Code on the fly when I need to.  The SPRY is great.  I click a button and DW plops it in the page.  Then I go and screw with it.  I like this much better than having to hunt down code - then copy - paste and finally edit it - like using Prototype or Lightbox (yes I know the 2 are not the same category).  And if I want to do that - then there is a "Snippet" feature that lets me store a library of code snippets - which is again - a button click away.

     

    My solution lately - Lightbox example - is well - SPRY has no Gallery - so go grab Lightbox (or whatever) and drop it into the SPRY stuff I already have going.  There's nothing stopping any of us from using several Frameworks (yes - I know - it's late - leave me alone) to accomplish what our end goals are.  No one is putting a gun to your head and forcing you to use JQuery if you don't want to.

     

    If SPRY goes away - since everyone was mentioning JQuery and it's bad structure - is this the next best alternative to SPRY?  And everything else is drastically pale by comparison?  You all mentioning the chaining issues - you can set DW to do that same thing with SPRY it's a setting in the App Prefs on how DW writes out the code - and there are several options for this.

     

    I don't see it going away and I simply use what's available - starting with SPRY then onto what ever tool does a good job for whatever I'm trying to do.  Simple as that.

     

    But Yes - Adobe needs to stop being the silent 500 pound Purple Gorilla in the room and speak up about something.  At least tell us not to jump ship.

     

    The End.

     

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 19, 2010 2:53 AM   in reply to Jp Cooper

    Just thought I'd check this thread after a year!!!

     

    yup - still no development - just look at what the other frameworks have achieved in the same timeframe!

     

    conclusion - investing in Spry is a potential dead end disaster.

     

    Spry is dead!

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 19, 2010 2:54 AM   in reply to Paul_Taylor

    Well than I might as well throw away the Spry 1.7 files we found.. http://groups.adobe.com/posts/d690df2300

     

     

    No, spry is not dead. They are actively developing it.. With a 

    complete rebuild of the widget model as a result.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 19, 2010 3:29 AM   in reply to Arnout Kazemier

    I fear its too little too late....

     

     

    The users have been treated like musrooms - In the dark, trying to grow, but ultimately left covered in.....

     

     

    Judging by development posts to date (esp. over the last YEAR!!) - Spry looks and feels like a one man project. And it also appears, that one man can't work on Spry while the next big thing in DW is being developed.

     

     

    Still no official announcement to give the faithful some sense of security in its development path.

    Is Spry open to true developer input - no

     

     

    Take a leaf out of the Yahoo books, be more open AND get developers involved - it shouldn't be a closed shop!

     

    And its certainly not by any stretch of the imagination, a professional  way to treat its users

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 19, 2010 6:54 AM   in reply to Paul_Taylor

    Yeah it's dead.

     

    And even if Abode manages to bring it back, I wont use it. There are better frameworks out there now. With better support.

     

    Actually I think Dreamweaver is on it's last legs too. At least in it's current state. Adobe needs to drop ASP (why would any ASP developer use Dreamweaver? When you have VS AND the Expression tools from MS. And both are either cheap or free?)

     

    And on the Mac, you have Coda, and Flux. Both way below $100. Not to mention all the open source apps you can use.

     

    Adobe needs to lower the price of DW a lot. Drop Spry and add jQuery, and dojo support. Support more them MySQL in it's PHP model. Update the PHP to current versions. And use current PHP coding styles.. like the PDO.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 23, 2010 6:49 AM   in reply to Stephen Cox

    I use ASP in CS3, its buggy but it works. I use CS3 for its productivity enhancements, my work flow is so much quicker. All the various ASP extensions help me do stuff quicker.

     

    I agree that CS5 will need to overhaul the server bahviours and bring them up to date, and that will probably mean dropping ASP, but thats fine, I can still use CS3.

     

    Spry only has a future if it goes Open Source and let the community take part and help shape its future.


    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 26, 2010 8:43 AM   in reply to Kevin 05

    I'm definitely the new guy here, but I'm afraid I'm going to have to side with the "Spry is Dead" crowd. If Adobe refuses to talk about it, or give any indications about its future, I'd rather invest my time in JQuery or Scriptaculous. It's too bad, really. I am quite the adobe zealot on a lot of fronts. This is not going to be one of them though.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 26, 2010 9:00 AM   in reply to Gabriel Landes

    I think we'd all like to use products that integrate well. But its too little too late.

     

    Adobe have told us with ADDT that 'times are a changin' and we need to embrace technologies that are open source etc. So why o why is Spry such a closed product. NO development for 2 years - how on earth are developers supposed to heed advice to embrace open source when Adobe themselves are keeping similar technologies all so secret. 2 years is an eternity in the web world.

     

    No doubt Spry has been updated for CS5 - but in the mean time YUI3 has a community and open development that is streets ahead. Not much point in waiting and hoping for Adobe to pull the rabbit out of the hat - especially when someone else has a bigger hat, the magic show is always on and you can even bring your own tricks to the show.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 24, 2010 10:04 PM   in reply to Paul_Taylor

    Is this - http://bit.ly/ibgLMA - and/or this - http://twitter.com/jquery/status/28813866424 - a coincidence?

     

    As much as I hate to admit it Spry is ............

     

    Gramps

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 25, 2010 12:56 AM   in reply to Ben Pleysier

    Or did you mean: https://github.com/jblas/jquery-dataset

    Kinblas is working on a jquery data set.. Seems like the conversion has begun..

     

    But only time will tell

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 25, 2010 2:02 AM   in reply to Arnout Kazemier

    Thank you Arnout!

     

    With several sites still running that use InterAkt Ajax Toolbox and further sites having been built with other InterAkt products not to mention the ill fated ADDT, I thought I was coming to another dead end by using Spry.

     

    At the time of searching for a replacement for the Ajax Toolbox, I had assured myself that the Spry framework was the easiest to implement especially because of its integration with DW. I found it hard initially because of the lack of centralised information and documentation, but thanks to you and Elizabeth on this forum, I was able to overcome those initial problems.

     

    I was also very excited when the so-called Spry version 1.7 was introduced. Thinking this was an upgraded and improved version of version 1.6, I soon realised that the initial structure of the widget had been lost to a structure as used by JQuery. Listening to others, this change is supposed to enhance usability and execution. I have yet to experience that. What I have noticed is that there seems to be some interference between the old and the new, reason why I have stuck with the old wherever possible.

     

    My initial thought, after having read the two articles in my previous post, was to ditch Spry in favour of JQuery. After having read your post and the included link, I have come to the conclusion that Spry is not dead, its going to take another, perhaps more exciting, turn which can only enhance both frameworks and to quote you, only time will tell.

     

    All the best for Christmas and a safe, healthy New Year to you and your family.

    Ben

     

    PS. It looks like my wife and I will be visiting your area of the globe in the coming year and are looking forward to a real kopje koffie. The accent on kopje, we are used to drinking out of 300ml mugs.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 5, 2012 8:07 AM   in reply to Ben Pleysier

    Will CS6 have spry? or will Adobe finely admit defeat and pull the plug?

     

    The last blog entry for the spry team was April 29, 2010! Is there any point in spending time on developing sites with spry?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 5, 2012 9:16 AM   in reply to GSNet

    Keep your chin up and all is well.

     

    Gramps

     
    |
    Mark as:
  • Currently Being Moderated
    Calculating status...
    Jun 20, 2012 1:35 PM   in reply to GSNet

    >Adobe finely admit defeat and pull the plug?

    as they did with catalyst ! booooo

     
    |
    Mark as:
1 2 Previous Next
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points