Wednesday, November 5th, 2008

SproutCore: From MobileMe to 1.0

Category: Library

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:

Posted by Dion Almaer at 9:59 am
1 Comment

++---
2.3 rating from 55 votes

1 Comment »

Comments feed TrackBack URI

In particular we think of Prototype, jQuery, and others as “DOM manipulation libraries”; somewhat like low-level drawing APIs.

Prototype and jQuery are more like “convenience functions” than a drawing library. If SproutCore wants to live on top of Prototype, then they are going to greatly limit the amount of stuff they can achieve if they’re expecting a drawing API.

SproutCore should live above this layer, allowing you to choose whichever drawing library you like to create custom views.

I think they’ve overestimated the power of those libraries. If you want to be able to change library providers, you’re going to have to write a proxy layer. And by the time you’ve done that, you already have enough code equal to the weight of those libraries. You might as well just write your own library as it’s not that hard. The hardest part is just the querySelector engine.

Comment by Jordan — November 6, 2008

Leave a comment

You must be logged in to post a comment.