As part of their new MobileMe online platform announced at the 2008 World Wide Developer Conference, Apple has recently released a web-applications framework which they’ve put their hands in with. SproutCore was originally designed by the SproutIt company for use in their Mailroom help-desk application.

Please note, that while Apple has chosen SproutCore, and they’ve gained it a lot of attention, it is not an Apple technology. It’s not really a Google technology either, the project just happens to be hosted on Google Code. Hell, even on MacBreak Weekly this week, Leo and the rest of the MacBreakers get that wrong. Apple has hired the developer, and they’ve been extending it, but the project is so far beyond just Apple. Google’s involvement is basically just providing hosting, but Google’s interest is similar to Apple’s. Both companies are interested in keeping the Web open using Open Standards. Google, so they can sell ads. Apple, so that no one can lock their platform out of the market. I may not care much about the motives, but I definitely support the potential results.

SproutCore is marketed as an advanced JavaScript framework which seeks to make Flash and Silverlight unnecessary because “users hate to have to download plugins before using your application.” Frankly, I think that’s bullshit, as 95% of users already have Flash installed, and will have Silverlight installed soon. No, the real reason to avoid Flash and Silverlight is that if you’re not a Windows user, the plugins typically are really awful. Of course, this remains to be seen with Silverlight, as it’s still in Beta, and Microsoft hasn’t released a Mac beta (to my knowledge at least), and the Moonlight project is still working hard to support Linux and other unixes.

My first impression of SproutCore may have been unfairly negative. Developing for SproutCore depends on Ruby, a language which I’ve felt no inclination to learn. This really has nothing to do with Ruby, which I applaud for successfully bringing the excellent MVC Design Pattern to the Web via the Rail framework, but mostly that I don’t want to go through the effort of learning the language without requiring it for a job. I know that i could learn the language pretty quickly,if necessary. Part of my problem with SproutCore was that it appeared to me to be little more than an extension on top of Rails.

This doesn’t appear to be the case upon further inspection. Upon running the ‘sc-build’ command on a project, it will output pure HTML, JavaScript, and CSS. Which is good, because the output of the debug SproutCore is really, really inefficient.

SproutCore can use a large amount of cool technology. Including HTML5 Client-Side Storage (which only Safari can use at this time) and some advanced JavaScript stuff. It provides an MVC framework in JavaScript, which many people are touting as bringing “Cocoa to the web.” Not being a Cocoa programmer, I can’t speak to that, but I do acknowledge and agree with the power of MVC, and apparently Cocoa has an excellent Internationalization Framework which has been extended to SproutCore.

My problem with SproutCore is that it feels to me that it forces you into a particular development model. Unlike other frameworks like Google Gears and the Objective-J framework, SproutCore allows you to write real JavaScript to accomplish what you’re doing. However, I’m still a fan of YUI, which allows me to embed their controls in any development system, and it’s better at designing applications that degrade in a clean fashion that many of these other systems. Admittedly, this isn’t as important anymore, particularly to Apple with Mobile Safari, but even recently I had a user who was still using Firefox 1. While I don’t intend to offer a rich experience to that user, I still want them to be able to use my Application. YUI can enable this, SproutCore probably can’t.