SproutCore

SproutCore & Microservices @ Google

2008-11-14T22:12:24Z

We had a great SproutCore Meetup at Google a few nights ago in cooperation with our friends at SV-GTUG. Nearly 100 people attended, Peter showed his great SproutCore app, Ryan gave a talk on Google AppEngine, and I built an entire application, including the backend, and deployed it on stage. That was fun.

Google AppEngine is interesting, but I think it’s especially interesting when you combine it with a web-client style technology like SproutCore. It makes AppEngine apps easier to build and delivers outstanding performance.

We’ll have a full video up in a few days as I understand it. I’ll post a link here when we get it, but until then here are some photos to tide you over.

Thanks again to the fine folks at SV-GTUG and Google for hosting the event.

SproutSightings: PaperCube

2008-11-14T17:43:37Z

Peter Bergstrom has been working on a really interesting paper citation visualization tool called PaperCube for the last few months and its powered by SproutCore. Today he posted a detailed writeup on the app and how to use it, that you can check out for yourself.

PaperCube is a great example of using SVG and advanced CSS rendering to create a rich graphical experience. It’s a bit shocking when you use this app to realize that he has created this entire experience using only JavaScript and native web technologies. Who says you need Flash or Silverlight for a great visual experience!

PaperCube will be one of the example apps listed on our samples page soon also.

» Read Peter’s Instructions
» Try the app

SproutCore 1.0: Platforms

2008-11-12T05:42:56Z

Mobile is a really interesting area for any web developer. With the iPhone and Android, there are finally phones with serious browsers that can run actual app-like code. Very exciting.

Of course, developing an application for a phone has its own unique limitations. Bandwidth is an issue of course. As is memory constraints and the UI has to look completely different.

Nevertheless, I believe that the thick-client model that SproutCore is based upon holds great promise for the phone. Precisely because of the bandwidth constrained, memory limited environment, downloading and installing code that runs right in the web browser can produce a dramatically better experience than forcing the user to wait on regular HTTP or even Ajax requests to complete. All you need is the framework.

SproutCore was originally designed for desktop applications, where you can potentially display large amounts of data. Neither the UI controls nor some of the large-data technologies we use on the desktop make sense on the phone. This is why we are working on creating a mobile version of the framework.

Starting with SproutCore 1.0, you will have a few new options in the SproutCore build tools to let you output a version of your application just for the mobile phone. Rather than force you to create an entirely new app for mobile devices, SproutCore treats platforms a bit like creating multiple languages. That is, you simply add a “foo.platform” folder to your project. Anything you place in that folder will only be included in the build for that platform.

For example, let’s say you were designing a Contacts application. You might create some models and controllers for your app. These will live in the models and controllers folder just like before. But now you could also create a “desktop.platform” folder and a “mobile.platform” folder. Inside of these folders, you can add the views and view-level resources needed to build the unique UI for that platform. Here is how that folder structure would look:

contacts
  core.js <-- namespace
  models/
    contact.js  <-- Contact model object
  controllers/
    master.js  <-- typical controllers
    detail.js
  desktop.platform  <-- for the desktop browsers
    main.js <-- this main() is run when loading the app in the desktop
    english.lproj
      body.rhtml <-- view helpers for desktop
  mobile.platform <-- for the mobile browsers
    main.js <-- this main() is run when loading the app on the phone
    english.lproj
      body.rhtml <-- view helpers for mobile

When you run a build, SproutCore will output both the desktop and mobile directories in your bundles. Once your app is deployed, you can visit your two apps by going to either:

Desktop:	http://www.example.com/contacts/en/desktop
Mobile:	http://www.example.com/contacts/en/mobile

There is also a facility to add auto-detection code at the top of your template page so you can redirect to the correct version of your app whenever a user visits your app’s main URL.

Of course, this means that the SproutCore JavaScript itself will also come in desktop and mobile flavors. More on that as it develops.

This new feature in the build tools is still fairly primitive. I’m sure we’ll be adding many more features to it once we get into your hands, but in general this opens up a new and very exciting area for SproutCore. I can’t wait to see what you all do with it!

SproutCore 1.0: SC.Enumerable and SC.Array

2008-11-09T23:17:54Z

One of the trickier aspects of making SproutCore DOM-library independent is dealing with enhancements these libraries make to built-in JavaScript objects.

For example, Prototype adds some very useful iterator methods - such as uniq() and compact() - to Array.prototype that we use frequently. These helpers reduce our code size and make it easier to read. On the other hand, depending on them limits your ability to use other libraries. What if you want to load a library that defines these methods in a conflicting way? For example, the way each() (or forEach() in the JavaScript standard) is implemented by Prototype, jQuery, and built-in by Firefox each pass different parameters to your callback. Not pretty.

Some libraries, like jQuery, avoid modifying built-in objects altogether to work around this problem. I didn’t think we needed to be that dogmatic about it, because some of these are so useful. So I decided on a few simple rules:

Never, ever, modify Object.prototype. This breaks too many things.
Many of the more useful enhancements that libraries add, such as forEach(), map(), and reduce() on Arrays, are actually part of the new JavaScript standard but just unevenly implemented. SproutCore will provide implementations of these on all browsers that do not have them consistent with the standard. You can basically use any of the iterators described in JavaScript 1.8 on any browser with SproutCore.
A few of the more useful helpers defined by Prototype, such as compact() and uniq(), which have common, unambiguous functions, are provided by SproutCore as well. They are implemented in the same way as Prototype so that if you do not want to.
We will also enhance Array and String as needed to support property observing and localization. For these methods, we try to name them in a way that is unlikely to conflict with other libraries.

While I was at it, I decided to make these enhancements available as mixins as well. The SC.Enumerable and SC.Array mixins in SproutCore provide our uniform enumeration API. They are applied automatically to Array, but you can apply them to any other object as well to make it “array-like”. This opens up lots of possibilities for creating sets, sparse arrays, and other complex collection-oriented data structures that you can essentially pass in anywhere you might normally expect an Array.

Overall, I’m pretty happy with the results. SC.Enumerable implements common iterators such as forEach(), map(), filter(), every(), some() and reduce(). These methods are all implemented natively in Firefox and some are in WebKit. For all other browsers, SproutCore provides a generic implementation for you. In addition, we’ve come up with some really useful extra features, such as:

SC.Enumerator

Sometimes you don’t want to just iterate through an array. Instead, it is easier to pass around an “iterator” that can simply return the next value until you are done. For example, let’s say you are going to process a bunch of data to produce some graph results. This would potentially lock up the browser if you have a large data set. It would be better to schedule a timer and then process them one or two at a time. Here is how you could do this:

function processData(array) {
  var enumerator = array.enumerator(); // get an SC.Enumerator instance
  var process = function() {
    var next = enumerator.nextObject() ;
    if (next) {
      processItem(next);
      process.invokeLater(); // schedule to fire again
    } else process = enumerator = null; // cleanup closure
  };
  process(); // start processing
} ;

processData(aBigArrayOfData);

The nice thing about this is the enumerator will work even if you edit the array of data, whereas keeping a simple index would be more difficult to keep in line. Note how you can call nextObject() on the enumerator until it reaches the end of the array, afterwhich it will return undefined.

Content Observing

One other benefit SC.Enumerable brings is it makes your array observable. All arrays have a ‘[]‘ property which you can observe to be notified whenever the membership of the array changes. For this to work, you must use the SproutCore-specific API for manipulating the array instead of the native methods, but this is cheap and yields huge wins. Here is a banking example:

MyApp.account = SC.Object.create({
  ledger: [],

  ledgerDidChange: function() {
    console.log(’account ledger changed!’);
  }.observes(’.ledger.[]‘)
});

With this controller, you could now insert or remove items like so:

MyApp.account.ledger.pushObject(newDeposit);
> "account ledger changed!"

MyApp.account.ledger.popObject();  // this is probably stealing. 
> "account ledger changed!"

MyApp.controller.records.insertAt(3, newWithdrawl);
> "account ledger changed!"

This makes it incredibly easy to observe changes on an array when you care about the member of the array itself.

Reduced Properties

Of course, we didn’t stop there. Observing when an array value has changed is nice, but often times you don’t care about the array itself, only a summary of its contents. For example, consider the ledger above. Maybe what you really care about are not the specific transactions, but the sum total of the account. You can get this with something called a “reduced property”. A reduced property is simply a value that is computed dynamically by evaluating all of the items in an array and combining their results. You can write your own reduced properties, but SproutCore comes with a couple of useful ones built in as well.

To get the value of a reduced property, you just use get() on the array with the property name. All reduced properties begin with an @ symbol and may contain a parameter identifying a specific property on the array contents you are interested in. For example, assuming all of the objects in the ledger above have an “amount” property that tells you their value, you could get a sum of the transactions with:

MyApp.account.ledger.get('@sum(amount)');
> (returns total amount)

Best of all, reduced properties are observable as well. So you can bind to them. If you wanted to show this account balance in a label view, for example, you could just bind the “value” property to "MyApp.account.ledger.@sum(amount)".

And so much more…

SC.Enumerable opens up a wide array (no pun intended) of possibilities for working with collections of objects in SproutCore. Best of all, these features are available TODAY in the SproutCore version you probably have installed on your machine. Checkout the SC.Enumerable and SC.Array mixins today. They both get a minor facelift for 1.0, but for the most part they work now. Get to know them.

SproutCore 1.0: SC.Builder

2008-11-09T05:43:48Z

Over the past few months, I’ve worked more and more with jQuery while investigating removing our dependency on Prototype. By far, my favorite part of the library is its API. jQuery’s design genius is to use chained methods to operate on a result set. This both makes your code very compact and it makes the API itself easily hackable as you can always add new helper methods at runtime.

This API-model makes a lot of sense for features where you need to configure a bunch of JavaScript (or DOM elements). For example, let’s say you want to quickly find all of the headings on your page, turn them red and change their text. It’s easy to do this in jQuery like so:

$('h1').title('Hello World!').css('color','red');

Pretty nice. Of course, you can do a lot more complicated things with this as well, but you get the point.

Of course, this kind of API lends itself quite well to the DOM layer, but it got me to thinking about what other pieces of an API might be better expressed this was as well. Take for example, Ajax requests. When you think about it, an Ajax request is a one time action. It’s really pretty clunky to have to create a Request instance and configure it just to send off a request. We could do better.

In SproutCore 1.0, we will have a new SC.Request API that you can use to make low-level requests to a server. (This will sit beneath SC.Server, for example, replacing what you would do now with Prototype). We’re still putting the finishing touches on this API, but its here is an example of how you might send a request to a server to get a resource:

SC.Request.get('/twitter/feeds').format(SC.JSON_FORMAT)
  .notify(Twitter.feedController, 'feedDidLoad').send();

Not bad huh? This would request the named twitter feed, expecting a JSON format, and then notify your the Twitter.feedController when the request is finished. Request object’s have a response property that contains either the retrieved JSON or an Error object depending on the result.

The nice thing about this model also is that you can hold onto the builder object and use it over and over again. For example, this is how you would setup a controller so you can send the same request over and over again:

Twitter.feedController = SC.Object.create({
  feedRequest: SC.Request.get('/twitter/feeds').format(SC.JSON_FORMAT),
  refreshFeedThenNotify: function(target, method) {
    this.feedRequest.notify(target,method).send();
  }
});

You can call refreshFeedThenNotify() as often as you want and each time it will initiate a new request. Pretty powerful for a few lines of code.

SC.Request is just one example of how we are thinking of using this DOM-builder-like API. We are also planning API’s for configuring views, menus, and even models. This is starting to look like a new design pattern, so we got to thinking: maybe we should provide some support for it. So that’s what we’ve done.

Introducing SC.Builder

SC.Builder is a simple class that makes it terribly easy to create jQuery-like builders for any kind of content you want. For example, to create your own jQuery all you need to do is:

jQuery = SC.Builder.create({
  init: function() { .. setup ... },

  // other helper methods you want here
});

Out of the box, this builder can do method chaining, supports plugins, and implements SC.Enumerable, which means you can iterate over it using typical Array methods like getEach(). All you need to do is to fill in the content-specific helper methods you want to add.

As we finalize some of these new API’s over the coming few weeks I’ll post more details about them, but I’m very excited about what SC.Builder makes possible. Configuring your SproutCore app has never been so easy.

If only…

2008-11-07T07:57:22Z

Microsoft considers adopting WebKit for Internet Explorer

I have no idea if this is true or not, but I can say that Microsoft has to get the JavaScript performance up to speed (pun intended) for the next generation of IE or risk becoming totally irrelevant.

People will spend thousands of dollars to buy a new computer so they can run the latest software that is important to them. They are far more willing to switch to a free brwoser to get the best experience for their web-based software. You would be surprised how quickly people will switch browsers for apps.

Apps !== content sites. The rules have changed.

Speaking of backends

2008-11-03T17:06:50Z

Jon Borgthorsson wrote an interesting article on building a SproutCore app with an erlang backend using Mochiweb and Mnesia. I don’t have the full setup needed for this article on my machine so test this myself, but it has received quite a bit of linkage over the weekend.

Thanks for the tips Jon!

How fast can a SproutCore app load?

2008-11-03T07:10:56Z

Checkout this simple todo app running on Google AppEngine. This is a work-in-progress sample app I’m working on to show at the next SproutCore Founders Meetup. The source code includes the SproutCore, a Google AppEngine backend and a Merb backend, with more to follow.

SproutCore applications are thick-clients, which means they download once to your web browser and run independently of the server. A lot of people naturally think this means that your server can run slow and it won’t matter. In some cases, this is true. More often, though, your application server actually needs to respond faster than it did before.

When you write a server-driven web app, the user constantly has to wait for the server to respond with some new HTML or Ajax between every few clicks. It’s slow and boring but at least it is consistently slow and boring.

When you switch to a SproutCore app, things speed up considerably for your users. Once your app is loaded, they can fly through the interface, selecting items, moving them around, deleting, creating, etc. The only time they have to wait is…you guessed it…when your server has to get involved.

Now that slow server of yours that was mere annoying before sticks out like a sore thumb.

Thankfully, SproutCore apps also free you to make your server side much simpler. All it needs to do is perform some basic data manipulation and return json as quickly as possible. This is often far less work than you had to do before server side, so you don’t have any excuse.

Make your SproutCore app beautiful and rich…and then make your server fast so won’t ruin that great experience.

SproutCore 1.0: New Bindings and Observers

2008-10-31T19:05:05Z

Property observers and bindings form the very core of SproutCore’s API. In fact, SproutCore is one of the few frameworks to have implemented bindings and observers from the very beginning instead of bolting it on at a later date. This contributes heavily to SproutCore’s compact design.

The centrality of bindings and observers also makes it one of our most important so that is why it was one of the first things we revisited for SproutCore 1.0. Since this code as so old, it was quite easy to rewrite it using some more efficient techniques, giving us a 2x performance boost when creating new bindings and setting up new observers.

In addition to a raw perf boost, we also changed some key behaviors related to timing that could change how your application behaves. These changes should speed up your app even further by reducing the number of bindings that fire in your application. Depending on how you’ve written your code, however, it could change how your code behaves. Here is what we did:

Change 1: setIfChanged Becomes Default

Today, every time you call set() on an object, SproutCore will invoke any observers you have as well, even if the value you are setting has not changed. For example, if you write some code like this:

obj = SC.Object.create({
  firstName: null,

  firstNameObserver: function() {
    console.log("observer fired");
  }.observes('firstName')
});

obj.set('firstName', 'John');
> observer fired
obj.set('firstName', 'John');
> observer fired
obj.set('firstName', 'John');
> observer fired

Now, the default behavior has changed. With the new code, observers will only fire if the value you set actually changes. For example, the output of the above code with SproutCore 1.0 is:

obj.set('firstName', 'John');
> observer fired
obj.set('firstName', 'John');
obj.set('firstName', 'John');

This means you can write less code to make sure your observer is not fired more often than necessary. Big win.

The only problem with this change is that this means computed properties may sometimes not be set more than once if you call set() with the same value. Usually this will not matter, but if your computed property needs to be called everytime you try to set the value, you can change this behavior by adding the indempotent() helper to your property:

fullName: function(key, value) {
  // do something interesting here
}.property().indempotent(NO)

Adding this qualifier to your property will cause it to be called every time there is a set() instead of just when the value changes.

Change 2: Binding and Observer Timings

Currently, whenever a property changes on your application, observers are notified immediately unless you are already inside another observer handler. Then they are queued and notified when the root observer exits. Since bindings are implemented using observers, bindings will trigger when your other observers finish but before the set() returns, again unless you are more than one level deep in observers.

If this sounds confusing to you, that’s because it is confusing. It also makes it hard to predict exactly how change notifications will propagate through your application.

With SproutCore 1.0, this timing behavior is significantly cleaned up. The rules are simple:

Observers (i.e. methods you setup with observes() or addObserver()/removeObsevers()) will fire immediately when you call set(), unless wrapped inside of a beginPropertyChanges()/endPropertyChanges() pair. In that case, they will fire immediately when you call endPropertyChanges().
Bindings on the other hand queue up. They fire only once at the end of the run loop, when all of your normal event handling or timer code finishes executing. Bindings are also coalesced. If a binding changes more than once during a single run loop, it will still only fire once at the end.

The net effect of this timing change will be that when a property changes on an object, the observers you have written for that object will execute immediately so you can update other state within your object. But, the bindings that tie together the objects in your app will fire all at once. This will cause changes to relay through your app rather like a wave, starting at the model or view layer and propagating to the other side in layers.

This more controlled rate of change will generally not require you to change any code, but it does mean that code you put in to gate changes and control duplicate messages will be less necessary. It will also generally speed up your application since binding change notifications occur less frequently.

Change 3: Cache Computed Properties

I mentioned this the other day so I won’t spend a lot of time on it now, but the basic idea here is that often the return value of a computed property only changes when one of its dependent keys or some other state changes. In the mean time, multiple calls to get that property could return a cached value. Caching used to require many lines of code, but now it can be done with just one. Here is how you write a cached property:

contact = SC.Object.create({
  firstName: 'John',
  lastName: 'Doe',

  // computed property, cached until first or last name changes
  fullName: function() {
    console.log('computing fullName') ;
    return this.getEach('firstName','lastName').compact().join(' ');
  }.property('firstName', 'lastName').cacheable()
});

contact.get('fullName')
> computing fullName
> "John Doe"

contact.get('fullName')
> "John Doe"

contact.set('firstName', 'Jane');
contact.get('fullName');
> computing fullName
> "Jane Doe"

contact.get('fullName');
> "Jane Doe"

Now the fullName computed property will be called only once and cached. You can get() as often as you like without paying the cost to recompute the value. If you ever need to recache a computed property without changing one of its dependent keys, you can do so by calling properyDidChange().

Change 4: Use a target and method with addObserver() and removeObserver()

The low-level addObserver() and removeObserver() methods are used to setup and remove observers on an object. Their API currently requires you to pass the property you want to observe along with a function to execute. To execute the function in the context of a particular object, you had to wrap you function using Function.bind(), which adds a stack frame, another object and closure and generally slows everything down.

Now addObserver() and removeObserver() will be able to accept a target and method, which will be tracked separately for you. This allows you (and SproutCore) to avoid having to create these extra closures, which increases performance and helps on limited JavaScript engines like IE7’s JScript.

Change 5: Disable Automatic Observer Notification

Normally, when you call set() with a new value on a property, SproutCore will automatically notify observers when the property has changed. Sometimes, however, you may have a property with a more complex behavior and you don’t want the automatic notification process to take place. Now you can override this behavior by implementing a new method on your class called automaticallyNotifiesObserversFor(key). Returning NO for this method will disable automatic notification for the passed key.

This technique is most useful when used with computed properties. For example, let’s say you decide to implement a computed property that only allows values greater than 10 to be set on it. Here is how you might implement this:

obj = SC.Object.create({
  // computed property can be set to any number
  // as long as it is greater than 10
  value: function(key, value) {
    if ((value !== undefined) && (value > 10) && (value !== this._value)) {
      this.propertyWillChange('value'); // implement notification manually
      this._value = value ;
      this.propertyDidChange('value', value) ;
    }
    return this._value ;
  },

  // disable automatic notification for this property
  automaticallyNotifiesObserversForKey: function(key) {
    return (key === "value") ? NO : YES ;
  },

  // add observer just to show  what happens
  valueDidChange: function() {
    console.log("value did change to: %@".fmt(this.get('value')) ;
  }.observes('value')
});

obj.set('value', 20) ;
> value did change to 20

obj.set('value', 5);
[no output]

obj.set(’value’, 21)
> value did change to 21

obj.set(’value’, 21)
[no output]

This is definitely an advanced topic, but if you need to control precisely how and when property change notifications happen, it can be a god-send.

In general, you will be able to use the new property observers and bindings in SproutCore without having to worry about the changes here. You should just notice your app running a little faster. Understanding how some of these work though can dramatically reduce the amount of code you have to write in certain advanced situations. If you have questions about this once its available, be sure to ask on IRC or the mailing list!

On the future of SproutCore

2008-11-02T01:06:41Z

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.