Wednesday, November 5th, 2008
SproutCore drove onto the scene when MobileMe launched using it.
Since that blast, the team has been diligently working on getting a 1.0 release, and Charles Jolley has
posted on the future of SproutCore:
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.
Charles then goes into detail on some of the bigger changes:
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.
There has been other SproutCore related news recently:
- Having SproutCore working with an Erlang backend
- How fast can a SproutCore app load? shows off a simple todo list application running on App Engine
- SproutCore 1.0: New Bindings and Observers
- Caching Computed Properties
- Using Computed Properties To Lazily Load Data
Posted by Dion Almaer at 9:59 am