SproutCore has always been an interesting project. It is the application framework behind Apple’s impressive iCloud apps, and the MobileMe ones before that, as well as many other high profile projects. The SproutCore view layer has gone through many revisions. At one point it used Ruby templates combined with CSS, and then it switched to a JavaScript only system, which still used embedded HTML and CSS to layout and construct views.

Erich Ocean, a SproutCore contributor since the early days, and others have been hard at work on a new fork of the SproutCore project called Blossom, which reimagines the view layer without the use of any HTML or CSS. How does it do this? It renders the entire view structure of your application on a giant HTML5 canvas element. Perhaps this seems crazy, but it has quite a few benefits over traditional HTML and CSS.

Firstly, it abstracts all browser differences away at the lowest level and makes more complex views that were not possible or very difficult to create with HTML and CSS much more manageable. Once this has been abstracted, building views on top of it can be much easier for both application developers as well as framework authors, leading to better, more maintainable applications.

Secondly, it’s fast. Modifying the DOM is about the slowest thing you can do in the browser, and unfortunately it’s probably the most common as well. There are some performance issues with drawing everything to one huge canvas, so they have separate canvas contexts for each view that then get composited back together at the final step in rendering using drawImage. This style is akin to the way Core Animation works in Apple’s Cocoa framework, and in fact, GPU accelerated 3D transitions are possible in Blossom as well.

Obviously, when not rendering to HTML and CSS, you have to manage everything yourself, from hit testing of views, to all the nuances of text handling including all the platform native keyboard shortcuts.

This isn’t the first time we’ve seen an attempt to create an entirely canvas based view pipeline, but it certainly the most ambitious. Back in 2009 when Dion Almaer and Ben Galbraith were working at Mozilla on the Bespin code editor (now Ace), they also started work on a framework they called Thunderhead, which worked like this. Ultimately, they didn’t get too far on it, so Blossom seems to be the next step in proving if this approach is viable.

Of course, Blossom is a fork of the original SproutCore project, and so it brings over all the foundation frameworks that underly it including the famous support for bindings and observers that have now made the other more lightweight fork of SproutCore, Ember.js popular as well. It also contains the datastore frameworks as well as some new build tools written entirely in JavaScript using Node.js.

The number one question people ask about creating applications in canvas is about accessibility. Screen readers don’t know what’s going on within a canvas element, but luckily, the framework can take advantage of WAI ARIA by embedding a DOM subtree inside the canvas element specifically to enable this, however nothing is rendered via this DOM and it is invisible to the user. I’ve long thought that JavaScript needed an API to directly communicate with assistive technologies, and perhaps frameworks like this will shed light on a use case for that.

So how does this perform on mobile browsers? Unfortunately, the answer is not so well, so mobile browsers are unsupported. However, Blossom does have another strategy for mobile, which is to package up the applications as native iOS and Android apps. This doesn’t mean simply wrapping the application in a WebView and shipping. For performance reasons, and since the canvas API is easily reproducible on these platforms, all rendering will use the native rendering pipeline on those platforms. This is the result of not having any DOM to worry about, all you need is a JS engine, and seems like it could be pretty cool!

As for desktop browsers, Blossom will run on all modern browsers supporting the canvas element, which in practice means everything except IE8 and below. IE9 is not currently working (IE10 is), but there is no reason why it couldn’t in the future.

SproutCore has turned into many things, and there are now at least 3 different frameworks based directly on it. The original SproutCore 1.x line is still in use at Apple and many other places, but SproutCore 2.0, now Ember.js is perhaps gaining even more traction as a lightweight version of the framework with only the most powerful features baked in. Blossom joins the party, staying much more heavyweight than say Ember, but also containing a lot more features and a powerful view layer for desktop-class applications in the browser - SproutCore’s original goal.

Blossom has just reached beta status and if you were a hardcore SproutCore 1.x developer you should definitely check it out. There is also lots of cool code to read in the Blossom repo on Github, and some demos to check out if you install it on your own machine. A full release for end users is scheduled for May at JSConf. There’s lots of cool stuff coming down the pipeline for Blossom, including a Cassowary constraint solver that will be useful for layout, so we’ll be watching for sure!