By Andrew Tetlaw

SproutCore: JavaScript Applications

By Andrew Tetlaw

Revealed by Apple at the recent WWDC as the basis of the MobileMe web applications, is the newest member of the JavaScript framework fraternity: SproutCore. I’m pretty sure that if I told you SproutCore was yet another JavaScript framework for creating rich browser application interfaces, you’d prefer to scrub your eyeballs with steel wool than keep reading. Don’t head off just yet though, because SproutCore is quite different from other frameworks and worth taking a look at.

SproutCore is an open source framework for creating desktop-style applications that run in the browser using only HTML, CSS and JavaScript. You first create your application within a local development environment and then use the SproutCore build tools to compile the application in to a set of static files you can place on your web server. The term ‘thick client’ has been coined by SproutCore’s lead developer, Charles Jolley, to describe SproutCore’s approach. SproutCore applications are totally independent of any server-side technology. The whole application runs in the browser; the only interaction with the server is to save or load data via Ajax.

When I say, ‘creating applications’ I mean sophisticated, Model-View-Controller based application design, inspired by Apple’s Cocoa. In practice it feels like you’re building a full featured Ruby on Rails application — the build tools are written in Ruby and use Rails-like features such as generators. Models and controllers are written in JavaScript and views are written in Erubis, a high performing implementation of Embedded Ruby.

Here’s a very simple demonstration of how it works. I recommend doing the hello world tutorial on the SproutCore site if you want to see more.

After installing the build tools via the RubyGems system, you begin a new application by typing the command: sproutcore hello_goodbye, replacing hello_goodbye with the name of your application. This will generate a directory with the same name as your application and in it, all the required files to make your application run locally.

To be able to do anything interesting you’ll need a controller — a JavaScript object that manages your application logic. You can use the built-in generator by typing in the following command from your project’s root directory:

sc-gen controller hello_goodbye/app

This will generate the application controller called HelloGoodbye.appController.

You wire up the interface elements of your application using bindings and observers. Let’s modify our controller by adding a greeting property:

HelloGoodbye.appController = SC.Object.create(
  greeting: "Hello World!"

Then we’ll add some view helpers to the default view file: a label view and a button view:

<%= label_view :my_label, 
    :tag => 'h1', 
    :bind => { :value => 'HelloGoodbye.appController.greeting' } %>
<%= button_view :toggle_button, 
    :title => 'Change Greeting', 
    :action => 'HelloGoodbye.appController.toggleGreeting' %>

Starting the included Mongrel web server by entering the command sc-server from the project’s root directory, will allow you to load the project in your browser at http://localhost:4020/hello_goodbye. You’ll see a h1 element with the text “Hello World!” and a “Change Greeting” button.
A screenshot of a simpleSproutCore app

The text content of the label view has been bound to the greeting property of the controller. If you change the value of greeting using the SproutCore API:

HelloGoodbye.appController.set('greeting', 'Goodbye World!')

the text within the heading will miraculously change as well.

The :action property of the button view indicates the controller method that will be called when the button is clicked. We’ll add that method to our controller:

HelloGoodbye.appController = SC.Object.create(
  greeting: "Hello World!",
  toggleGreeting: function() {
    var currentGreeting = this.get('greeting');
    var newGreeting = (currentGreeting === 'Hello World!') ? 'Goodbye World!' : 'Hello World!' ;
    this.set('greeting', newGreeting);

If you refresh the page in your browser, clicking the button should toggle the text within the h1 element between “Hello World!” and “Goodbye World!”. You may notice this is achieved without us having to write any DOM manipulation code in JavaScript at all.

Once you’re ready to deploy, all you need to do is run the following command from within your project’s root directory:sc-build. This will create a directory containing static files that you can move to your web server.

Our trivial example above is converted to the following html:

<h1 id="my_label" class="sc-label-view my_label"></h1>
<a title="Change Greeting" id="toggle_button" 
    class="sc-button-view button regular normal toggle_button">
  <span class="button-inner">
    <span class="label">Change Greeting</span>

In addition to the HTML, you’ll also find all the JavaScript code required to run the application.

Looking at the generated source, it’s clear SproutCore is an application framework in the truest sense: ignore the generated HTML, the end product will look and feel like a desktop application. For a web standards fan like myself, browser-based, desktop-style applications are always a hard sell. I prefer the restful, semantic-markup based, document-centric approach that lets browsers act like browsers. You know: bookmarks and history, right-click > Open in new tab, the sanctity and purity of the hyperlink. It seems inevitable though, that the browser, as an application platform, will be pushed as far as it can go. I can’t help recalling Joel on Software predicted something like this might come along.

As a JavaScript fan I’m impressed; the interface performance is excellent. SproutCore raises the bar for what JavaScript can do in the browser. On a recent Audible Ajax Jolley talked about how a SproutCore application has only 6 event handlers. SproutCore uses event delegation to determine which element in the body was the target of the event. I’m certain that there are many JavaScript gems to be mined from the SproutCore codebase. The SproutCore blog already contains some great posts.

What about accessibility? How will assistive technologies treat the HTML generated by SproutCore? I doubt screen readers that are compatible with standard HTML forms, but otherwise designed to interpret a web page as a document, will have any chance of making sense of it. Perhaps, in the future, standards like the WAI Accessible Rich Internet Applications specification will eventually come to the rescue. I’ll be interested to see the approach Apple takes for MobileMe.

Despite my concerns, I can certainly appreciate how Apple has chosen an open source technology that is browser based and requires no plugins as the basis for their online applications. In my mind, this beats the pants off the alternative technology stacks from Adobe and Microsoft.

  • So even for the most trivial example, clean semantic code is beyond the capabilities of this framework? What a mess – I dismiss it entirely.

  • ywarnier

    Basically, it’s a lot like OpenLaszlo ( or maybe there is something I’m missing? Would be nice to push the analysis so far as to make a comparison…

  • Martin

    I agree entirely with brothercake. When a ‘Hello World’ example takes 19 lines of code, you can safely say it was badly designed.

  • @ywarnier, SproutCore has no server component at all, the whole application is static HTML & JavaScript. ‘Compile’ is probably the wrong word to use.

  • @Martin, I don’t think you should make your judgment based on my crappy demo :)

  • heggaton

    Yeah, I believe you simply can’t judge any ‘framework’ based on a “Hello World”.

    This isn’t a programming language, it’s a framework. In fact, a “Hello World” is probably the worst example of a proof of concept as a framework is simply not designed for this type of task.

    Anyone who simply needs to output two words and a button would simply do it using JavaScript and HTML. No one in their right mind would ever look at *any* framework for this type of task.

    Once you start building complex applications, that’s where a framework becomes useful and I suspect in this case, it’d be the same.

    Why do you think most frameworks use a blog tutorial?

    @atetlaw, May I recommend truly putting this framework through it’s paces by doing a blog based system?

  • giladfit

    The demo is not working on IE6 – checked on two machines.

  • I just think it bodes badly – if this is how it generates buttons. The example itself is not the point, it’s the wider inference that bothers me, if I assume that *all* buttons will be generated with this kind of markup. And by extension, if this is how it generates all UI controls.

    Bad bad bad.

  • It’s worth to add that demos at SproutCore website don’t work in IE6. MobileMe is said not to support it as well. So it only makes sense to use the library if you can afford to forget about one of the most popular browser out there.

  • Stefan from

    As a framework it should be fully compatible with all major browsers. It’s working in FF2 & FF3, but fails in IE6 & IE7, which makes it’s totally crap for developers who confront there costumers with an application that works only in… that’s no option for developers.

    As for the showcare of this framework, i feel sad for the work that is done. Because it is not the only Javascript Framework there is, it should be in some way competitive with the others, like OpenLaszo or ExtJS.

    For what i can see now, i’m not blown away by Sproutcore as a “framework”.

  • Udo

    First sight: Totally slow in FF3, JS Error in IE 7

  • tmallen

    Apple missed the boat for JavaScript frameworks. jQuery, Mootools, and Dojo have all won their respective niches, with Prototype/Scriptaculous still being widely used as well. ExtJS doesn’t have momentum and I don’t see it making more waves.

    SproutCore has horrible effects compared to the other frameworks. Animation is slow and choppy. Why does Apple think the world needs this? All it takes is a little developer discipline to make any of the existing frameworks act MVC. JavaScript is a malleable language.

  • Johans

    Have to agree that that is hardly appealing code and certainly no way it gets close to what you can do in Adobe Flex/Air.

    The demo is badly designed since the Controller updates the View – the view should be bound to the Model.

    As for not working in MSIE – do I really want to spend my time doing cross-browser testing when I could be workgin on the application? Not me!

  • GMedia

    SproutCore is revolutionary – a game changing framework for the web. Write your code in Ruby/HTML/JS then compile it for distribution. There are a bunch of flaws and faults, but it is a young framework. I see it as the leader for tomorrow, but still in training.

    It seems a lot of web programmers are missing the point, because this isn’t your grandma’s web programming. This is application design. Once there is a good IDE for this (please please Apple make me something in xcode with Interface Designer) we will see an explosion in great web apps.

    As far as support for IE goes – I have had to drop it for one project that needs IE 6 support, but I have another app where people are going to drop IE6 to use it… It’s time for the web to grow up – there is no way I am chaining myself to IE6 for another 2 years waiting for System 7 to come out and people start upgrading.

  • heggaton

    there is no way I am chaining myself to IE6 for another 2 years waiting for System 7 to come out and people start upgrading.

    And there is no way anyone will use your framework until it supports IE6 or the years pass and no one uses IE6 any more.

    Get your head out of the sand! This isn’t a developer request. If developers had their way, they’d all use the very latest technology. It’s the users – a market which can’t be controlled.

    As long as users are using IE6, developers will (have to) support it. I can’t see any framework being successful when it dictates that it can’t be used on one of the most popular browsers out there.

  • PJ


    >The demo is badly designed since the Controller updates the View – the view should be bound to the Model.

    Er, that’s the whole point of the Controller in MVC, to synchronize data between the view and model.

    @everyone else

    “Because it doens’t work in IE” is a terrible reason not to use it. Let’s push the state-of-the-art, not wallow in the status-quo.

  • heggaton

    “Because it doens’t work in IE” is a terrible reason not to use it.

    Why? Why should we as developers handicap our business by telling our clients that we’re not going to support one of the most used browsers out there?

    Sounds like a good way to kill a business personally.

  • grrrr

    As somebody who has some experience with GUI programming before doing web programming it seems to me like web programmers do not really know what MVC is . For example if you think rails is a MVC framework you are wrong. On the other hand sproutcore looks like it really is a MVC framework and it includes some concepts that are fundamental to MVC that are missing in for example rails and that some commenter’s here do not seem to grasp.

  • Even though the demo is crappy, the point was not just to show how to get a message to display, but how bindings/observers work.

    @Johans the controller never really updates the view. The controller updates a stored value and that’s all. The label_view element just happens to be bound to that value, but the controller is unaware of that.

    That’s what I was trying to demonstrate — the wiring up of interface elements without having to write any DOM manipulation code. I thought it was pretty neat.

  • LaForce

    SproutCore is definitely the direction to go. I don’t care about IE6 or 7. Why bother my customers with the past, iinstead of make them happy with the future. And Sproutcore (and Ruby) take away so much development pain – they’re just amazing….

    Opposed to what was said before, allowing for clean semantic code is the strength of Sproutcore and Ruby. Hiding unnecessary, repeating and redundant code from the developer is the way to go…

  • heggaton

    I don’t care about IE6 or 7

    Good luck keeping customers.

  • We Should be like MSoft

    I realize that most of you guys comment on IE6 Support. Heck I suggest all web developers to kill IE6 support cause MS release new OS that require the whole world to upgrade their PC. So why should we be nice to Microsoft users by supporting an outdated browser?

    Yeah, my statement is confusing, but think of it this way, Microsoft forces its customers to upgrade to their new OS by killing of support of their previous OS, so its the same if we kill of IE6 users by forcing them to upgrade to IE7 if they want to use our website or make a popup which says get Firefox and never have to worry about browser incompatibility ever again.

Get the latest in Front-end, once a week, for free.