To SproutCore, or not to SproutCore…

I’ve been debating over the past week whether or not to use SproutCore for a large application I am working on. What follows are my initial thoughts on the framework, likes and dislikes.

A fight with what’s right

Right, I’m afraid I’m going to start with a negative in the hope that I can focus more on the positives for the rest of the post.
I have been an advocate of Web Standards in the running on SonicIQ over the past 10 years, with this has come the adoption of Progressive Enhancement using Unobtrusive Javascript. Now along come two cutting edge frameworks, SproutCore and Cappuccino who completely abandon this culture in search of a desktop-like feel to web apps.
Having been an early adopter of techniques like Unobtrusive Javascript and seeing the benefits they offer, I am reluctant to give the finger to those without Javascript, even if this is now a small minority. With the advent of HTML5 I suppose this becomes less of an issue as Javascript is one of the many standards under the whole HTML5 umbrella and is just expected to exist. I can’t help feeling a little dirty though having a page of just script tags.
Am I being too “precious” about Graceful Degradation, or is this still relevant with the arrival of HTML5?

Fat Client

Both SproutCore and Cappuccino opt for the “Fat Client” methodology, for anyone who has not heard of this (other than in the literal sense), this means that the client (browser) is made to do more of the grunt work usually accomplished by the server. This has a huge benefit of making the app feel much “snappier”, as common calculations, concatenations etc. are all done on the client-side, reducing the amount/size of calls to the server. Your server-side app acts more like a dumb data store, using REST to communicate data back and forth.
The downside to fat clients (I won’t do the obvious joke), is that there is a chance that your audience will see more than you want them too when visiting “View Source”. You obviously don’t want to give away Granddad’s age-old secret hangover cure in the Javascript source, however as long as you’re sensible and keep the business logic that is of any real value at the server-side, all should be fine.

Fat Framework

Unfortunately, in order to have the additional work handled by the client, you have to feed it more Javascript. The whole of SproutCore comes in at an impressive 500Kb uncompressed! That said, it will compress down to 100Kb when minified and gzipped.
Lets say you went with plain old jQuery as it’s smaller, and you’ll just add plugins for the bit’s you need. Well, by the time you include a chunk of jQueryUI when you want to be able to sort lists and drag stuff around… you’ve soon hit that 100Kb threshold.
So… is the size really an issue by the time it’s all been cached by the browser, images sprited, scripts concatenated into one file etc?



One of the alternatives already mentioned is Cappuccino. To me the instant turn-off was Objective-J, it’s very clever and all that but do I really want to have to learn another language when I already have Javascript under my belt. Objective-J may have the benefit of easing portability to desktop apps, however I can’t see that this will ever be a flawless process.


Another lightweight alternative is UKIJS which aims to bring the core UI element of the aforementioned frameworks, without the kitchen sink that comes with it.
I’ve had a brief play with UKIJS and generally love the concept, however I can’t help but think it would be better built on top of jQuery instead of borrowing so much of the internals. Also as it is a young project, there are large gaps in the functionality, such as reordering of lists, custom cells in list view etc.
This is definitely one to watch as it seems like a great light-weight alternative to it’s bulkier competition.


I have only scratched the surface in my search for the best framework out of these options. My next job is to play with SproutCore a little more, to see if it caters for what I need.
Has anyone else had experience with these frameworks? What was the conclusion? Should we just abandon Unobtrusive Javascript when building web “Apps” and use it only for web “Sites”?

Join the conversation


  1. It took me a little while when I was starting to use SproutCore to get over the perception that what i was doing had nothing to do with traditional web sites. SproutCore is meant to build applications, not sites that are used as a source of information. Think iTunes, iCal, not wikipedia/amazon. In other words, complaining that a sproutcore app does not work without javascript is like complaining that does not work without cocoa.
    Soroutcore has a reeky awesome and helpful community, so don’t hesitate to ask questions!

    1. @Majd I know completely what you mean. My project is definitely at the “app” end of the scale but just struggling with the paradigm shift.

  2. I had a similar love/hate reaction to sproutcore. In the end, having all the html markup generated by the framework bothered me too much to go forward. I generally work with designers that produce html/css and I couldn’t figure out how this kind of workflow could work with sproutcore. You might also want to check out javascriptmvc which is built on top of jquery.

  3. @Jamie recently came across this blog post after a web search, I’m in the same position now and I’m curious what your reflections are and if you’ve made a decision.

    1. @Leroy I found both Sproutcore and Cappuccino too bulky for my needs. Currently I am playing with Spine and my own custom micro framework that takes ideas from the best and I will be open sourcing when usable.

  4. I too had been caught in this rut myself. I had been working with JQurey for couple of years until I took a project which was originally done in DOJO. I had to learn DOJO which wasn’t hard but time is of the essence when a developer is staring at the barrel of a gun. After finishing up with “Dojo” project, I walked into a project that was half done in “Javascriptmvc”. Well, I should have said no the project, but need the finance were tight. I ended up working with “Javascriptmvc” which is just as good as other frameworks. Now I am looking into sprout core and am asking myself “why in the work am I killing myself like this?” Everytime I turned around there was a no framework, or new flavor, and I was just tired of learning new frameworks. I have decided to go to the dark side and work behind the scenes (back-end). I no longer do the front-end.

  5. @Xane
    How does doing just the backend solves your problem? You didn’t mention what language you use for the backend so off the top of my head you have to choose from ZendFramework, CakePHP, Symphony, CodeIgniter, ruby on rail, ASPX.Net , MVC3, just to name a few, there are lots more…
    I’ve been developing in PHP for a while now, and from PHP I went and learned C++and C# but I’ve never really did anything serious in JS, the most I’ve ever done is animating a few divs and ajaxing some stuff with jQuery, now I’m facing a few project that will require desktop like environment on the web and for reasons I can’t use C#.Net but must use PHP, I’m looking for a web app JS framework but my JS skill is limited, im curious what would you recommend for someone like me?

Leave a comment

Your e-mail address will not be published. Required fields are marked *