SproutCore 1.5 Released

written by Yehuda Katz

We’re excited to announce the final release of SproutCore 1.5. It’s been almost four months since 1.4.5 shipped, and we have lots of exciting new stuff for you.


Template View

SproutCore 1.5 offers a brand-new way to define your view layer. If you have an existing application, SC.TemplateView makes it easy to integrate Handlebars-flavored HTML into your view hierarchy. If you’re starting a brand new application, you can design your entire application using just HTML, CSS, and the power of SproutCore’s binding system.

We’ve put together a tutorial that takes you through the process of creating a new template-based SproutCore application from scratch. You’ll learn how to define a model, create a controller structure, create HTML using Handlebars, then hook all of the pieces together using bindings.

Guide: Getting Started with HTML-Based Apps

Community member Greg Moeck created a screencast as part of his Dispatches from the Edge series that shows some of the power of these templates:

Dispatches from the Edge: Template Views


If you are building a native-style application using SproutCore’s library of controls, we have a great new default theme called Ace 2.0 that looks at home on modern desktop and mobile operating systems.

We’ve also significantly improved theming flexibility for developers that desire their own look-and-feel. You can even include multiple themes in the same application.

To learn how to theme your application, read the guide by Alex Iskander:

Continue reading

Giving Back to jQuery

written by Yehuda Katz

For the first several years of SproutCore’s life, we shipped a fast, minimal jQuery clone that powered our view layer. As of SproutCore 1.4, we integrated jQuery proper into SproutCore’s view layer. I thought it might be worth taking a few minutes to explain why we made this change and what it means for our project.


In the past, we tried to stay relatively DOM library agnostic.  You could use Prototype, jQuery, MooTools, or whatever else you wanted.  SproutCore would do its best not to depend on any of these so you didn’t have to pay the cost of loading a library you didn’t own.

Since we made that decision, things have changed somewhat on the web.  jQuery adoption, in particular, has skyrocketed.  Not that these other libraries aren’t used, but today it’s common to find most sites using jQuery alongside them for one or two things.

In short, we believe jQuery has become a nearly standard library of the web. In many ways, it is no longer just about one project but really belongs to the web as a whole.

Because of its degree of use on the web, it is by far the best way to work with the APIs exposed by the web browser. And while it was once somewhat sluggish compared with hand-rolled code, jQuery is now usually *faster* than the code you wrote yourself. The jQuery team has spent years building features with and an expert-level understanding of the browser environment and API.

Here’s one example: did you know that when you use `$(“<div id=’test’></div>”)`, jQuery caches a document fragment that it reuses every time you use the same String value? (Did you know there was such a thing as a document fragment?). To avoid memory bloat, jQuery applies heuristics to the String based on real-world usage. The widespread use of jQuery and the team’s focus on real use cases has afforded the library a careful balance between all of the factors that go into using the browser efficiently.

Having spent almost half a decade pushing the limits of the browser, we’re familiar with a lot of these tradeoffs. In many cases, jQuery 1.4.3 will be faster and more efficient than our code. In some cases, because of the ways that SproutCore has been used, our techniques are more efficient. Starting with SproutCore 1.4, we’re going to be contributing time and resources to jQuery, which is crucial to our own success.

Continue reading