Why Spry? Part 1

Hey Spry:fans,

I am going to have a couple themes running through my posts over the coming weeks and months.
The first is “Why Spry?”. In this, I will discuss how and why Spry came about, what our goals were and where we are going.
The second is “What’s Next?”. This will talk about some of the features and changes coming up in 1.5.

Today, we will start with “Why Spry?”

The Spry team is a small subset of the Dreamweaver team. In the fall of 2005, we were starting to think about the next set of new features. Ajax was making its name known and it was pretty obvious, as a web design tool, that we should look into it.

We started looking into the various frameworks that were available. After looking through a bunch, some themes developed:

  • Many had a lot of dependencies: many files had to be corralled to enable functionality.
  • It was hard to style: Markup was injected programmatically. It was hard to know what code ended up on you page.
  • It wasn’t easy. The learning curve was pretty steep.

But we didn’t want to make our own framework. We thought that maybe Dreamweaver could support a popular framework or two…

Then we thought about Dreamweaver.

  • Injecting markup wouldn’t be good. You want to see it and style it in Design View.
  • Custom tags wouldn’t be good. There’s a learning curve and rendering issues.
  • Lots of dependencies to track: no one likes that.
  • Tough to support something that someone else writes. Difficult to maintain code parity.

So 2 things came out of this:

  • There is room to innovate and simplify
  • We should write our own framework

As we started to think about this and prototype things, our Spry tenets began to develop:

  • Use what you know: Use HTML and CSS to markup and style the page. Avoid custom tags.
  • Don’t inject markup. You can’t style it if you can’t see it.
  • Keep it simple. Distill common functionality into an ‘easy to understand and use’ element. After all, computers are supposed to the hard stuff for us.
  • Keep dependencies to a minimum.
  • Make it page-centric. We saw that a lot of benefit to ajax was adding small pieces of advanced functionality to existing page. We aren’t creating an enterprise level application framework. We want to make HTML pages better.

With these ideas in mind, we started building the foundations of Spry.In future posts, I will get into more details about how we got to custom attributes and more details behind the development of the framework.Thanks,Don

5 Responses to Why Spry? Part 1

  1. Sammy Larbi says:

    Hi Don,Thanks for that post. I have to confess, I’ve yet to use Spry, but I have been following its development somewhat, and that question always cropped up in my head. I’m glad to have it answered.I do have a question though. You mentioned several of the teams goals, which all see worthwhile, especially from the developers’ who will use Spry point of view.Do you feel you’ve accomplished those goals, and if so, how? Perhaps that’s a question for an entire post, but it would be great to hear about.

  2. Don: Looking forward to more active Spry blogging! Spry is great so far, but it would really help to know what your vision and targeted audience for Spry is. What are the plans for Adobe project integration (DW?) in the future?

  3. Hannes Löhr says:

    Why i use spry.Some years ago i started my website http://www.hannes-renate.de (mostly pictures) with no knowledge of html. First i used frontpage, but i didn’t understand the generated html, so i began to simplify it and learned by trial and error. I used at that time a customized Photoshop picture gallery, later jalbum. Now i have some 7000 files on my server. and can no more manage the whole mess. My provider doesn’t allow PHP or MySQL, because the webspace and domain is without cost. Last year i stumbled over Spry. Spry gives me the chance to reduce the number of html files enormously. Instead of one html-file per picture in case of the former Photoshop gallery, i have with Spry one html-file for several groups of albums. Not telling about all the other possibilities. Thanks to the authors, especially for their willing response in the adobe labs spry forum.Hannes Löhr>

  4. Phillip Senn says:

    My initial impression of Spry is: Hide error messages until they need to be visible.To that end, I suggest simplifying the examples. And I’ve posted this on the forums, so you’ve probably seen my weekend rantings…But the validationwidgets show multiple examples on each page, kind of saying “Look at all the things you can do!”I’m just trying to grasp the concept of what new features Spry is offering. Just show me a simple example code.Oh, and don’t comment “the SELECT has a red background applied on it”, and then say “background-color: #FF9F9F;”, just say “background-color: red;” and END IT!

  5. Bernd says:

    The documentation for spry was the best, it feels simple to use. Therefore I am using spry, and not script.aculo.us.Thanks for a hopefully cool integration of spry in DW.