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