Has anyone used Sproutcore for a web application? If so, can you give me a description of your experience? I am currently considering it, but I have a few concerns. First, the documentation is bad/incomplete, and I'm afraid that I'll spend lots of time figuring things out or digging through source code. Also, I'm a bit hesitant to use a project that is relatively new and could undergo significant changes.

Any thoughts from people who have developed in Sproutcore are appreciated!

EDIT/PS: Yes, I've seen this post: https://stackoverflow.com/questions/370598/sproutcore-and-cappuccino . However I'm interested in a bit lengthier description of Sproutcore itself from someone who's used it for a significant project.

  • 2
    I can't answer the question, but I can tell you that Apple itself uses SproutCore for its own .Mac services. So it's at least mature enough for that.
    – Chuck
    Sep 16, 2009 at 5:17
  • Yea--that's what got my interest. But with what little I've tried of it, the documentation is bad enough (especially, for example, for SC.DataSource and SC.Store) that I'm not sure if it's worth the trouble.
    – Sam Lee
    Sep 16, 2009 at 5:51

6 Answers 6


Just browse through the sproutcore group posts at google groups to get a feel for what's going on.

Some weeks ago someone complained about the docs, being a newbie, and basically what he got was: "if you don't like it, why don't you help create the docs"... well duh!!

You'll see issues like this since it's inception. Also a few weeks ago someone asked the group how to create a hyperlink using Sproutcore. I mean, LOL, it takes hours to create a simple hyperlink apparently.

Sproutcore doesn't advertise who's using their framework in the wild: usually not a good sign.

It is claimed (not by sproutcore itself afaik) that Apple uses it, but if you look closely you'll see that Apple has it's own codebase.

I personally found sproutcore to be riddled with bugs, the lack of a simple tableview annoying, incomplete or non-working examples, and the absence of documentation and even the absence of complete TESTS is just not a good base to build upon.

  • 5
    I claimed that Apple uses it, and it's from Apple itself. MobileMe is written with SproutCore. appleinsider.com/articles/08/06/16/…
    – Chuck
    Sep 16, 2009 at 15:51
  • Apple does have their own code base, but they regularly merge back with the public repo.
    – Peter Wagenet
    Dec 6, 2010 at 21:16
  • Also, in response to the hyperlink issue, SC is made for creating rich web apps. This means that you are not normally touching the DOM yourself. As a result, you are not intended to make your own hyperlinks.
    – Peter Wagenet
    Dec 6, 2010 at 21:17

We are using sproutcore more then year.

First I developed using version 0.9 which was excellent but had performance issues, related to KVO, Large datasets etc. But since SproutCore is Javascript (close to javascript) we were able to solve them for our application. For me actually, SproutCore taught me proper way of javascript coding. I was learning Javascript and SproutCore same time.

Somewhere around July they released SproutCore 1.0 pre-alpha. API was changed significantly so converting our application to newer version was a project in itself. And documentation was zero at that time.

Now things are changed, There is documentation and very nice wiki. New tutorials and documentation added each day.

If you thinking to use/evaluate SproutCore this is right time. And each day SproutCore amaze me with capability and power it contains. Still there is lots of rough edges, which reduces everyday.

Some Resources:

SproutCore Wiki

API Docs

Recent addition for data store API (which is very important part)


I worked with a company using SC for their flagship app redesign. Here are my thoughts:

  1. I really like the MVC layout of an SC app. It is something I think other JS frameworks lack. Their binding framework makes updating views a snap.

  2. The best documentation was in the code itself.

  3. The need better documentation/more examples. Their examples are enough to get you started, but advanced things will stump most users.

  4. The data access layer is too complicated. Its a huge mystery. They need to really shore up documentation or provide more examples to pave the way so people can use it properly. On the other hand, it seems to be a really powerful almost ORM framework.

  5. I like the fact that they stress testing.

  6. Lack of a grid is a real drag. Many if not most apps need grids. That said, SC is a fully featured MVC framework, not a framework of widgets(components) list EXTJS.

  7. A lot of the code seemed overly complex. Anytime a method gets to be longer than 10-30 lines it should really be broken up to increase readability.

  8. Perhaps the biggest consideration is this: if you are working a project and considering SC, you are going to have real trouble finding competent developers to work on it. So it might be good for a small personal project, but you are taking a risk with a large project that will need maintenance.

  9. The IRC support was phenomenal. The guys on that channel are really helpful.

  • 1
    The data access layer is too complicated. Its a huge mystery. - indeed. Also, debugging is one hell of a task.
    – c69
    Nov 2, 2011 at 13:07
  • @c69 -- When I wrote this I believed that. But since then I've dug in and come to the conclusion that the datastore is quite powerful and not too difficult to understand. You just need to start doing stuff with it
    – hvgotcodes
    Nov 2, 2011 at 13:59
  • maybe in current releases, its true - but i work with legacy SC, and its just madness.. (and its not updateable, as it seems)
    – c69
    Nov 2, 2011 at 16:01
  • @c69, if you are having specific problems, ask a question and maybe i can help
    – hvgotcodes
    Nov 2, 2011 at 16:41

I am using SproutCore and it is simply great. We switched from jQuery to SproutCore, since jQuery offers a small set of utilities and SproutCore offers a nice high-level architecture.

We evaluated these Javascript libraries in the following order:

  1. Prototype, which felt ok but jQuery has more support and books etc.
  2. jQuery, which felt great but it didn't have any support for a nice high-level architecture and we started to build one, but it took too much time.
  3. Cappuccino, which has a nice high-level architecture but lacks roadmap and documentation
  4. SproutCore THE SOLUTION, since this offers a nice high-level architecture and it has a nice built-in build system

Our top list:

  1. SproutCore is the WINNER
  2. jQuery is a good toolkit
  3. Cappuccino looks promising but is not quite yet there
  4. Prototype is ok, but in my opinion not as good as jQuery

Of course there are more toolkits, but these are the ones we evaluated. As a conclusion I can highly recommend SproutCore to anyone who is building a desktop class applications using Javascript. If you just need some simple Javascript, like date pickers etc., I recommend jQuery.

Just one more tip. At the time of writing this answer the SproutCore 1.0 is the latest stable version. Unfortunately it is quite old and we are using the latest version that can be found from the SproutCore's Github page. I can highly recommend that.


If you are trying to get into SproutCore I recommend that you dig into the SproutTweets sample application. Many of the more powerful constructs (states, dynamically loaded frameworks, a useful example of a datasource) are in there.

You can find the SproutTweets application on github http://github.com/sproutit/sproutcore-samples/tree/master/apps/sproutweets/

  • Also be aware that running the sample in Safari with the web inspector gives a more useful set of error messages.
  • The sc-server contains a proxy which can be used to access your own REST data source running on a local web server. Refer to the buildfile in the sprouttweets sample app above to see how that works.
  • The included proxy in the sc-serve is pretty limited. If your having issues with your data layer requests give sc-build then deployment on your local web server a try instead of the proxy. We found issues with our 401 authentication loops and streaming of large dataset responses (chuncked encoding).

Even if you have no intention of using SproutCore in a production application you owe it to yourself to explore it further to see a powerful approach to javascript application programming -- especially the KVO and mixins (aspects) stuff. Lots of great architecture to ponder and learn from.

Last point -- the IRC channel can be far more helpful than other sources of information, second only to some deep diving in the google group discussions.


I have used SproutCore in the past. I was assigned a project to develop automated web testing scripts using the tool called Selenium RC. Selenium RC was built to target regular HTML id's and classes, but SproutCore compiles the element IDs so that the element IDs are pseudo random, so I had to figure out the API for SproutCore so I could fish out the element IDs from the view tree.

SproutCore has a close analogy to compilers. If you have too many elements that you're importing creating for your web page, there's a chance you'll have a namespace collision on the IDs if you were to build your application with jQuery. When you're building your web page with jQuery, all the IDs of HTML elements are globals. There's no such thing as local scope as in a compiled or interpreted language.

SproutCore ends up managing the HTML content for you. The views are built up using javascript and then compiled. If you go through the SproutCore tutorial (and I agree SproutCore is lacking in documentation so you should try to avoid it for a business application), you'll see that your finished project has ID elements of "sc-###". Namespace collisions become resolved on the website giving you the potential to work faster.

However, there's major concerns. They documentation doesn't do a good enough job explaining why people should use it. The project is opensource, but digging your way down to understand the lower level javascript for how the views are built become painful. Javascript is a functional language, but I just find something wrong with dynamic functional languages. There's just too much flexibility. I'm plugging Scala.

The last issue. SproutCore can be slow. But it's a price to pay

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy