Skip to main content

Guide to searching (and finding) help on Sproutcore

Sproutcore Logo
Make no mistake: Sproutcore IS a huge framework. Also not all of it is documented equally well and that's the reason why a casual observer or someone picking it up for the first time might find it difficult to perceive its full power (and extent).

My first acquaintance with Sproutcore goes back to fall 2009 when a series of articles began to appear on the web about this new framework created at Apple by Charles Jolley. Since then a lot of things have changed and it's not always been clear what was driving those changes.

This post is an attempt to write down and share my experiences and the resources that I used in learning Sproutcore in the hope that they may be useful to others.

A little bit of history
First of all a little bit of history: Sproutcore was started by Charles Jolley while working on the MobileMe platform at Apple. From there the framework spun off into an Open Source MIT licensed version (originally hosted on GitHub under the sproutit account).
That version, numbered 1.4, is probably the version that most developers started with and it's also the version that marked a shift in the SC world.

Around spring 2011, with SC gaining popularity and visibility Jolley moved on into founding Strobe, a VC backed company whose mission was to continue improve SC and provide a whole hosting service model for developers. Basically a PAAS for Sproutcore apps.

Strobe hired most of the original Apple employees who worked on MobileMe and Yehuda Katz of jquery and ror fame. It was at that time the Sproutcore 2.0 moniker came out. The purpose of Sproutcore 2.0 was to provide a leaner framework, still based on the original SC, but without the complex view system so that it could be plugged into traditional web pages, much like jquery. Sproutcore 2.0 would provide a rich datasource model, key-value-observing and a view system based on templates (derived from Moustache). Probably Strobe had planned a way to transition apps from 1.x to 2.0, but it was never officially stated and this increased the confusion among (new) users who thought 2.0 was just a newer version of 1.x.

Strobe managed to release two more stable versions of SC (1.5 and 1.6). A beta version on 1.7 was released but never finalized. 1.7 came as 1.8 out in March 2012 under a complete different umbrella.

At the same time time Strobe was in fact busy working on SC 2.0 and its PAAS offer (which is still advertised on the web site). It managed to release a promising developer preview in fall 2011 and then went silent. The reason was that it was being acquired from Facebook with the acquisition being announced in Dec 2011. In the months in between development likely stalled as there was no sign of activity either on github, the ml or irc.

I for one was confused and started fearing that I had bet on a losing horse.

The December 2011 fork
However the Facebook acquisition went at least it got things moving again and marked the following events:
  1. Sproutcore 2.0 was forked and given a different name: Ember.js . Development is being carried on mainly by Tom Dale and Yehuda Katz
  2. some of the members of the core team moved on to Facebook and I believe they are not working on SC anymore
  3. Erich Ocean (who wrote the original Datastore implementation) forked SC 1.4 and is currently rewriting the view layer to use a canvas-based renderer. The fork is named Blossom and the project manifesto is here
  4. Sproutcore 'classic' is currently being mantained by an active group of people and has recently released version 1.8 and its bugfix release 1.8.1. Release 1.9 is in the works
  5. last but not least there was an attempt to rewrite the build tools in nodejs (they are currently written in Ruby), but I have not heard any news about it
So, if you're new to Sproutcore and you wanted to get started with it, which one should you choose?

If you already have an app or a web site and just want to benefit from SC KVO and datastore implementation then you should probably pick Ember.js.

If you are developing an app from scratch and need to implement a complex ui with a native look and feel for desktop platforms then 'classic' Sproutcore is the natural choice. Please note that 'classic' SC might not yet feel at home on mobile devices, but the situation has been improving steadily, especially with the 1.8 release.

If you like Erich Ocean's canvas based renderer and the possibility to compile your app to native for mobile platforms too, then you should try Blossom.js.

Sproutcore classic
As I said Sproutcore is a big framework and with the 1.6 release it became even bigger because new technologies were incorporated:
  1. statecharts
  2. template views
  3. routing
  4. touch support
So if you're new you're probably wondering where to learn about them, especially for those not covered in the guides. During my experience developing with Sproutcore the following resources proved extremely important:

The new guides, of course are a must-read, especially after the getting started trilogy has been thoroughly reviewed during the 1.8 sprint. The old guides are pretty important too, especially with regard to the datastore section which is not covered in the new guides. Don't bother with the big red "DEPRECATED" sign in the top right corner, almost all content is still valid. The datastore is also covered pretty well by the webcasts on Vimeo (see below for the link).
Let's not forget the API docs (these were obvious, though).

In 2011 Strobe published a series of excellent webcasts, they are all still available on vimeo. They cover all the bases including a project overview, views and datastores.

If you think you've encountered a bug it is probably worth checking the list of current issues before asking on the ml.

The #sproutcore and #sproutcore-dev IRC channels are also useful when you need help quickly. I suggest you hang out there on a regular basis, even when you have nothing to ask. You never know when an interesting discussion is going to start.

Use the Source, Luke!
The github repositories of other sproutcore users and of course the developers: you'll find hidden gems to inspire you (like this RSS reader by Tim Evans).

gist.github.com : try searching for SC.outlet (an obscure, but useful feature of the framework) and you'll see how many references and actual examples will show up. Github is disseminated with gists of statecharts, controllers and datastores.

Read this series of 3 blog posts by Michael Cohen if you find yourself in the need to customize or create your own view.

Unfortunately the animation framework is in a state of flux and the new API is not yet completely documented, while the old, which was documented, is deprecated. 

I saved for last the ultimate documentation tool: source code. Sproutcore source code is well-written and heavily commented, you'll find many suggestions and tips there like this improved version of the split view or a picker pane with a more likable theme.

Comments

Popular posts from this blog

Mirth: recover space when mirthdb grows out of control

I was recently asked to recover a mirth instance whose embedded database had grown to fill all available space so this is just a note-to-self kind of post. Btw: the recovery, depending on db size and disk speed, is going to take long. The problem A 1.8 Mirth Connect instance was started, then forgotten (well neglected, actually). The user also forgot to setup pruning so the messages filled the embedded Derby database until it grew to fill all the available space on the disk. The SO is linux. The solution First of all: free some disk space so that the database can be started in embedded mode from the cli. You can also copy the whole mirth install to another server if you cannot free space. Depending on db size you will need a corresponding amount of space: in my case a 5GB db required around 2GB to start, process logs and then store the temp files during shrinking. Then open a shell as the user that mirth runs as (you're not running it as root, are you?) and cd in

From 0 to ZFS replication in 5m with syncoid

The ZFS filesystem has many features that once you try them you can never go back. One of the lesser known is probably the support for replicating a zfs filesystem by sending the changes over the network with zfs send/receive. Technically the filesystem changes don't even need to be sent over a network: you could as well dump them on a removable disk, then receive  from the same removable disk.

How to automatically import a ZFS pool built on top of iSCSI devices with systemd

When using ZFS on top of iSCSI devices one needs to deal with the fact that iSCSI devices usually appear late in the boot process. ZFS on the other hand is loaded early and the iSCSI devices are not present at the time ZFS scans available devices for pools to import. This means that not all ZFS pools might be imported after the system has completed boot, even if the underlying devices are present and functional. A quick and dirty solution would be to run  zpool import <poolname> after boot, either manually or from cron. A better, more elegant solution is instead to hook into systemd events and trigger zpool import as soon as the devices are created.