Microsoft’s Richard Florance has a neat set of “easy win” performance tips.
Daily Archives: June 17, 2008
Installing SproutCore on Ubuntu on VirtualBox
If you check out the installation instructions for SproutCore you will notice that Windows developers are not really catered for (though I am sure it can be done). I also noticed some Windows issues in the Sproutcore forum. More evidence of the Windows/Unix disconnect.
Having been impressed by VirtualBox recently, I figured it might be easier to use VirtualBox and Ubuntu.

Here’s how it went. I ran up a new VirtualBox image and installed Ubuntu. Very easy; just point VirtualBox to the Ubuntu install iso. This worked, except that Ubuntu did not recognize the video driver and defaulted to 800 x 600 resolution. Solution: install dkms in Synaptic (or using apt-get); then install the VirtualBox Linux Additions. That gave me 1024 x 768, which is good enough.
Next, you need to install Ruby (developer version) (use sudo or root)
apt-get install ruby
apt-get install rubygems
apt-get install ruby1.8-dev
and some build tools as one of the SproutCore dependencies (hpricot) calls make when installed:
apt-get install build-essential
I thought that would be enough, but my first go at installing SproutCore failed, apparently because gem is not on the path. Although it seemed to work, I got “command not found” when running sproutcore. So:
export PATH=$PATH:/var/lib/gems/1.8/bin
Now you can install SproutCore:
gem install sproutcore
Several components, such as hpricot, ask which version to install. I chose the variant designated (ruby).
After that, the Hello World tutorial ran exactly as expected.
By the way, although this example makes it look as if SproutCore is a dynamic server framework, it is not. The usual way to deploy a SproutCore application is as static files; the server arrangement is for debugging.
Note: the command above only amends the path for the current session. To make it permanent, I added the following to lines to the end of /etc/profile (needs root permissions to edit)*:
PATH=$PATH:/var/lib/gems/1.8/bin
export PATH
*See comment below for an even better suggestion.
The RIA dilemma: open vs predictable
There’s recently been a bit of hype (RoughlyDrafted.com) for Charles Jolley’s Sproutcore, yet another JavaScript framework, mainly because Apple is using it as its “Cocoa for the Web”, according to AppleInsider.
I tried the sample controls demo in IE7 but it didn’t work quite right. For example, the Picker pane opened but would not close. Tried again in Firefox 3.0 and everything was fine.
I’ve got no idea what the problem is with IE7; it is probably because of weak standards support in IE. However, it illustrates the advantages of a plug-in like Flash, Silverlight or Java. With these platforms, the application is largely insulated from differences between browsers.
The snag with the proprietary plug-in approach is that the vendor may not support every platform equally. Microsoft is entrusting the bulk of Silverlight Linux support to a third party. There are also issues of control. Apple most likely does not want any runtimes on iPhone because they open up a route to application deployment that bypasses its App Store and 30% revenue share. Google seems wary of Flash; RoughlyDrafted says that is because of the risk of content being turned into “opaque binaries” that are beyond the reach of its contextual advertising analysis, but it may just be reluctance to cede such an important part of its platform to a third party.
Still, as a developer in search of a predictable app platform I’d rather target a plug-in than trust the browser vendors to be sufficiently consistent, and the Javascript libraries sufficiently smart, to enable my code to run reliably everywhere. It is easier to get away with a requirement for, say, Flash 9, than to insist that users choose a particular browser or operating system.
There are other factors of course. On the Javascript + HTML side, there are advantages in that it extends rather than replaces the HTML model. Things like clipboard support just work. Plus, it runs on iPhone.
On the plug-in side, you get the fast execution of a JIT compiler, and easy use of graphical and multimedia effects that take effort to do in JavaScript, or can’t be done at all.
I would be interested in comments from developers about what RIA platform you are choosing, and why.