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

Indexing Apache access logs with ELK (Elasticsearch+Logstash+Kibana)

Who said that grepping Apache logs has to be boring?

The truth is that, as Enteprise applications move to the browser too, Apache access logs are a gold mine, it does not matter what your role is: developer, support or sysadmin. If you are not mining them you are most likely missing out a ton of information and, probably, making the wrong decisions.
ELK (Elasticsearch, Logstash, Kibana) is a terrific, Open Source stack for visually analyzing Apache (or nginx) logs (but also any other timestamped data).

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.

A not so short guide to TDD SaltStack formulas

One of the hardest parts about Infrastructure As Code and Configuration Management is establishing a discipline on developing, testing and deploying changes.
Developers follow established practices and tools have been built and perfected over the last decade and a half. On the other hand sysadmins and ops people do not have the same tooling and culture because estensive automation has only become a trend recently.

So if Infrastructure As Code allows you to version the infrastructure your code runs on, what good is it if then there are no tools or established practices to follow?

Luckily the situation is changing and in this post I'm outlining a methodology for test driven development of SaltStack Formulas.

The idea is that with a single command you can run your formula against a matrix of platforms (operating systems) and suites (or configurations). Each cell of the matrix will be tested and the result is a build failure or success much alike to what every half-decent developer of…