It’s been nearly four months since SproutCore launched to the public at WWDC and we couldn’t be happier with the results.  18,000 developers have installed SproutCore (sudo gem install sproutcore ftw), nearly 1,000 developers have joined the mailing list, and dozens of projects are underway at companies around the world.  One additional one has already gone public (OtherInbox).

During this time the developers working on SproutCore haven’t stood still either.  150 tickets closed, some major new features, and enhancements for Windows, IE7, Chrome, and others.  Many of the changes we’ve applied have come from you, the community.  In fact, over 20 people have contributed code to SproutCore now, which is outstanding for such a young project.

Now that I’m back from my trip, though, I thought we should spend a little time talking about where we are headed next.

Put simply, our next major milestone is SproutCore 1.0.  When I started planning SproutCore 1.0, here were the criteria I laid out for it:

• Make the common easy and the uncommon possible. Typical behavior for an application should be nearly automatic without limiting a developer’s ability to hack something cool.
• Support the whole application. SproutCore must support the whole application development process, including the model, view, and controller layers as well as design, testing, documentation, and deployment concerns.
• A small consistent API. Favor configuration over class-bloat.  Use consistent “guessable” design patterns.  The API should be vetted well enough that it will not need to change dramatically once released.
• Offer broad platform support. Perform well on all modern browsers.  Perform adequately on IE7 and earlier.

So far, we’ve come pretty close to achieving most of these goals.  In particular, SproutCore is the only open source web application framework that can help you build your model layer and your view layer, talk to your web server, and then tie it all together with bindings.  It is also one of the few that include documentation and unit testing right in the build tools.  The API is also pretty good when you consider how much functionality you can deliver with a few lines of code, thanks to bindings.

After watching nearly a dozen apps developed with SproutCore, though, we’ve definitely found some places we could improve both the API and the implementation.  To that end, we’ve undertaken a major review of the entire SproutCore framework over the last few weeks.  Based on that review, we are rewriting some of the oldest parts of our code to make them faster and more memory efficient and revisiting parts of our API to make them more consistent.

A lot of this work is taking place in different repositories, some of them private, so the code will not drop into the public repository until we have everything integrated.  In the mean time, I can tell you about some of the changes we have made.  Over the next few weeks, I will delve deeper into some of the specifics of our APIs, but here are some of the things we are doing at a high level:

Faster Observers and Bindings

Property observing and bindings underpin almost everything you do in the SproutCore framework.  Because of that it is really important to make this feature small and fast.  We have currently rewritten this code to make it almost 2x faster on its own, and to use significantly less memory.  More on this in the coming days.

DOM Library Independence

Currently, SproutCore depends on Prototype for a few cross-platform functions.  This really doesn’t make much sense.  In particular we think of Prototype, jQuery, and others as “DOM manipulation libraries”; somewhat like low-level drawing APIs.  SproutCore should live above this layer, allowing you to choose whichever drawing library you like to create custom views.  Additionally, removing this dependence will allow those who do not want to use Prototype to eliminate that page weight from their apps.

New Model Layer

The current implementation for SC.Store, SC.Collection, SC.Record and the servers have not been revisited since they were written almost two years ago. When these were first deployed, they worked fairly well for the small apps that used them.  Since then we’ve seen applications loading 40,000+ records into memory in a regular basis and a move towards investigating use of the coming local storage facilities on modern browsers.  This code is going to see a wholesale rewrite as we update the API to accommodate this new, larger scale world.

Better Documentation

During our revisiting of the API, we are also adding to and improving the inline documentation for all classes.  Combined with some new tutorials, the final SproutCore should be much easier to learn and to use.

And a whole lot more…

We have some other big changes in the works as well that we can’t talk about yet, but there is one more thing:

Compatibility

Even though SproutCore’s API will change, dramatically in some places, we know there is a lot of code already running on the current SproutCore API.  To support these older applications we are developing in tandem with the changes a “sproutcore-deprecated” framework.  This framework can be installed in your apps to support all of the existing API until you have a chance to update your code at your own pace.

We believe that the web is about to undergo a major revolution in terms of how we develop software.  As more applications move to the cloud, users will want to take the rich, desktop experience they are accustomed to with them.  We think that SproutCore can be one of the best options to deliver this kind of experience with our open source heritage, simple API, and focus on the whole application.  Our hope is that the new SproutCore 1.0 will solidify this case.

Tags: Announcements, New Features //