I spend most of my time using Ruby on Rails, but enjoy exploring other web application frameworks. There’s a wonderful diversity of frameworks out there, with more popping up all the time, but there are two challenges I’ve found with trying to find ones I want to investigate:

1. Keeping track of them all: This isn’t terribly hard, but I find myself subscribing to a number of news feeds so that I can find out about new frameworks as they come out. If you want to look within a particular language of choice, you can generally search and find good lists that way as well. Looking across languages you can turn to Wikipedia or a few other places, but these don’t always stay up to date and can be biased (Wikipedia lists only 5 Ruby frameworks, and 3 JavaScript ones as I write this).
2. Knowing which ones are worth looking at: This is far more challenging. When looking at a list of names of frameworks I’ve never heard of, the question that comes to mind is “which ones are people actually using?”. Not that popularity is a perfect proxy for how good a framework is, but I do put some faith in what fellow developers are into, and there are definite benefits to having a good sized community. In order to judge popularity, I look at github stats for projects living on github, and failing that will also look at how much traffic the framework’s site gets and how many people are linking in to it.

The Idea

After numerous occasions of such exploration, it occurred to me that I may not be the only one who does this sort of thing. I decided to formalize my methods for turning up nuggets of web framework goodness and share the results with others. I was also inspired by The Ruby Toolbox, which beautifully does what I’m talking about for Ruby plugins/gems. But unlike Ruby, where essentially everything interesting is happening on github these days, not all (or even most) web frameworks have their source code hosted on github. This meant employing some different tactics for rating popularity.

The Popularity Contest

Since github stats aren’t universally available, I decided to look at other measures of popularity. Traffic statistics seemed a reasonable approach, but these too weren’t universally available since many web frameworks don’t have their own domain (e.g. Tapestry is at a subdomain of apache.org), and traffic statistics are typically only available at the domain level. I also considered looking at things like Google search trends or Twitter mentions, but the problem with these is one of specificity. For example, I can be fairly sure that any time I see SproutCore come up on Twitter it’s referring to the framework, but Cappuccino mentions could very well just be talking about the caffeinated beverage. So the third measure I’m employing is the number of inbound links, since these are specific and can be checked against any URL.

So inbound links seem to be the lowest common denominator for measuring popularity, but it would be a shame to neglect the other popularity measures where they’re available. Plus, inbound links are sometimes biased, for instance many Django apps have a “Powered by Django” link at the bottom so Django has an enormous number of inbound links. What I decided to do is take whichever of the three popularity measures (github stats, site traffic, inbound links) are available for a framework, and average them. But since the raw statistics are on very different scales, I first put them on a 0-100 scale, and then simply average the three scores. It’s not incredibly sophisticated, but seems to get the job done.

The Implementation

See the results at:

HotFrameworks (http://hotframeworks.com)

Currently there are really just three components to the site: rankings charts, individual stats for each framework, and a blog. This is just the first iteration though so there’s plenty more I can envision adding.

When implementing a trivial timer application in Cappuccino, RestfulX and SproutCore, one thing that struck me was how varied their approaches were to handling interaction with a server back end. Cappuccino has the lowest level abstraction here, while RestfulX takes care of more of the process and SproutCore has a high-level and somewhat complex system for server interaction.

Cappuccino
The Cappuccino framework provides the CPURLConnection class, which handles XMLHTTPRequests, although the level of abstraction is fairly low. For instance, here’s what I use to submit a request to create a new project in Clocky/Cappuccino: This does allow greater flexibility for any type of back end, however.

RestfulX
RestfulX has a higher level of abstraction, with Service Providers for JSON, XML and others, and models that use the service provides when they’re asked to be created/updated/etc. This allows you to use create a new project (after setting it’s properties) with something like: Of course, the JSONHTTPServiceProvider assumes a standard Rails-style “REST” JSON API, which is great if you’re using Rails, but you’d need to roll your own service provider if you’re not using a back end that’s Rails-style or one of the other existing Service Provider types.

SproutCore
SproutCore clearly has the highest level of abstraction for server interaction, although it’s a bit complex so it may seem intimidating at first. There are actually 3 levels as I understand things: the model, the data store and the data source. Your models (e.g. projects in Clocky) are locally stored on the client in the DataStore, which is back end-agnostic. The data source layer lies between the data store and your server, so it handles putting together the right XMLHTTPRequest. What’s great is that the SproutCore actually keeps track of state on model objects, and you just have to make your application respond to these states appropriately. Unfortunately you have to roll your own data source, and for me getting SproutCore to talk with my standard Rails backend took almost as much time as doing the rest of the app (it would have been easier if I’d been willing to adopt the JSON structures to what SproutCore likes). Of course now I have a fairly generic Rails data source that I could use on future projects.

The winner: it depends
Determining which framework handles back end integration the best will depend on how you want that interaction to work. If you’re doing Rails-style REST on the back end, then RestfulX and SproutCore are going to take care of a lot of the details for you. SproutCore’s ability to track state and do local queries using the data cached on the client could save you a lot of work if you think you’d end up having to implement that yourself with the other frameworks. But if you roll your own back end or don’t plan on doing CRUD over HTTP then you won’t miss what the others have to offer by going with Cappuccino.

Now that I’ve finished implementing a trivial timer application in Cappuccino, RestfulX and SproutCore, I want to delve into and compare a few aspects of developing in these frameworks. Of course all of my comparisons will be biased by my choice of application to implement, so I’ll certainly miss exciting parts off these frameworks that I didn’t have the opportunity to explore.

One aspect of working with these client-side frameworks that I found challenging was debugging, which is particularly important when first learning them and experimenting with how to properly use their not always well documented APIs. Compared with server-centric frameworks, even ones based on dynamic languages like Ruby, there are far fewer clues when something goes wrong.

YMMV
When the client lives in the browser, your choice of browser and accompanying tools/add-ons becomes important. The two real choices seem to be either Firefox with the Firebug add-on or Safari with its developer tools. As I’m developing in Linux, I use Firefox/Firebug, so my comments may not be valid for Safari

Compiled or non-compiled
One of the best and worst things about using RestfulX is the compile step. It slows down the development cycle a bit, but does catch a lot of errors. This would be a moot point if SproutCore and Cappuccino were able to report errors, but unfortunately that’s often not the case. I found that both of these frameworks repeatedly left me either with a blank page or a semi-functional interface and no console errors to help me find where things went wrong. Of the two, SproutCore seemed to provide helpful error messages more frequently, and when it did it could show the location of the error in the source, which isn’t currently possible with Objective-J

Logging and Breakpoints
I could be wrong, but from what I understand the only way to use breakpoints with RestfulX (Flex) is to use Flex Builder. Given that it costs a bit of money and I only wanted to briefly explore RestfulX, I stuck with logging, which still took a bit of effort to set up since I needed to have the developer version of Flash. SproutCore had the best free breakpoint setup since all the code is JavaScript and you use the breakpointer in Firebug as you would with any other JavaScript code. It’s also supposed to be possible to hard code breakpoints into your code in Cappuccino and then step through the Objective-J that’s been turned into JavaScript, but I ended up sticking with just plain old logging for Cappuccino as well.

Conclusion
Overall, given that I’m using Firefox and Firebug I found the SproutCore and RestfulX debugging processes to be equal in difficulty, but for different reasons, and Cappuccino slightly harder than either.

Cappuccino is the third framework I’m including in my project to implement a trivial time tracking application in multiple client-side/rich frameworks. Cappuccino was created by the guys over at 280 North, and originally showcased by their 280 Slides application. Like the SproutCore framework I recently explored, Cappuccino has its roots in Cocoa, but while SproutCore just draws on Cocoa for inspiration, Cappuccino attempts to reproduce a subset of the Cocoa API on the web and uses the Objective-J language that is roughly Objective-C built on JavaScript.

Since Cappuccino and SproutCore are so similar, it’s perhaps worth looking at some notable similarities and differences that I ran across when implementing the trivial timer application in each:

• Cappuccino strives to let you use a single Objective-J API to implement applications, whereas in SproutCore you need to drop down to the standard HTML/CSS/JavaScript combo when you need to implement a new type of view ,for instance.
• Both allow you to “compile” and deploy an application as a set of static files that can be served by any starndard web server (although you’ll usually want some sort of backend too), but in development SproutCore requires running a Ruby web server, whereas Cappuccino can run entirely in the browser even in development.
• SproutCore provides a model abstraction layer that manages much of the interaction with REST-like backends. In Cappuccino there isn’t a model abstraction to handle this so each call to the server is handled manually.

Without any experience using Cocoa/Objective-C I didn’t have the immediate familiarity that is no doubt very enticing to developers coming from that background, however the Objective-J syntax was relatively easy to get used to and the API still seems sensible even without that experience. As with the other frameworks I’ve looked at, Cappuccino is fairly young so the documentation and tutorials are sparse as compared with more mature frameworks.

Now that I have three frameworks (Cappuccino, SproutCore and RestfulX) under my belt, it would be interesting to write more on specific aspects of developing with these frameworks, but I’ll save that for later. For now I’ll simply post a link to the source code, which tells all: http://github.com/bruz/clocky-frontend-cappuccino

You can never be completely sure of how well a Linux distribution will work on a laptop until you actually give it a whirl. I just got a new (well, refurbished) Dell Vostro 1220, crossed my fingers as I installed the latest Karmic Koala (9.10) Ubuntu release, and was extremely pleased with the results. So far I’ve verified that all the following work without any tweaks:

• Hibernate and suspend
• T-Mobile 3G modem
• Sound
• Special keys for volume up/down, brightness up/down, sleep and the audio player play/pause, stop, and forward/reverse

The wifi didn’t immediately work, but after plugging in to a wired network and doing all available Ubuntu updates, two options for wifi drivers became available. Based on what I read in a couple of forums I went with the proprietary driver from the vendor (Broadcom STA) that was reputed to work a bit better.

Performance is great with ext4—I’m seeing about 15 second to boot up. Battery life is roughly 3-4 hours with the heavy flogging I inflict upon it. Looks like this will be a great laptop for the long bus commute.

SproutCore is the second framework I’ve used in my project to implement a trivial time tracking application in multiple client-side/rich frameworks. SproutCore, the framework behind Apple’s MobileMe, is one of the heavyweight contenders in the desktop-like web application arena. Originally released last year in version 0.9.x form, it has undergone major changes over the past year+ to the currently near-release 1.0 version. Thankfully my experience with SproutCore started as it was becoming more stable towards the 1.0 release, although the documentation still hadn’t all caught up to the 1.0 changes (but has since been massively updated and is in good shape now). SproutCore is a Cocoa-inspired framework, but is implemented in JavaScript so it makes use of some of the good aspects of the language. JavaScript as the language choice comes in contrast to RestfulX which uses ActionScript 3, and Cappuccino which uses (and created) Objective-J. Since I’ve already looked at RestfulX, it’s interesting to note some similarities in the platforms. Both have:

• Ruby tools for code generation and application compiling/building
• Bindings to wire together the various components of applications
• Fixtures to let you develop your app prior to switching over to using a real back end server

A big difference comes in SproutCore’s model layer and how it interacts with the back end. SproutCore provides a higher level abstraction that manages when objects are changed and need to be updated, and when they’re busy and shouldn’t be modified, for instance. This is handled via the SC.Store, which your controllers interact with directly. Underneath that is an SC.DataSource, which you have to implement. I can understand the reasoning for not having a one-size-fits-all data source, but I was surprised no one else had crafted one up for Rails yet. Implementing my data source ended up taking longer than the rest of the app, but it was a good exercise in getting to know the framework better. I’ve included a generic data source in this implementation that can interact with a stock Rails server (no tweaks to make the JSON SproutCore-friendly), and may follow up with a post on that. Other miscellaneous notes on my experience with SproutCore:

• Attractive controls by default
• No date selection field in standard widgets (although this appears to be part of the new SproutCore-UI project)
• Write-save-refresh cycles are somewhat slow, but speed up substantially with Ruby 1.9 vs 1.8

Finally, here is the code: http://github.com/bruz/clocky-frontend-sproutcore

The first client-side/rich web application framework I’m tackling in my attempt to explore various frameworks of this sort is RestfulX. While RestfulX is not well known yet, I decided to give it a go since it has an intriguing set of features:

• Strong support for multiple RESTful backends (e.g. Rails, CouchDB)
• Built on Flex
• Uses Ruby for code generation and build tasks
• Offline capabilities via Adobe AIR

This was my first foray into AS3 and MXML, but thanks to the generators I had a nice scaffold to serve as an example for how to do things. Even the custom timer control that I had to implement wasn’t too tricky. But what really stood out with RestfulX, especially after looking at the other frameworks, was the model layer. It handled all the interaction with my JSON back end (well, after a small patch), and worked great with Rails by default. Here are some other miscellaneous notes:

• There’s a good set of user interface components (thanks Flex)
• Model callbacks take a little getting used to coming from a Rails background
• The compilation step is a little slow, but does catch a lot of mistakes prior to the browser

You can find the source code at http://github.com/bruz/clocky-frontend-restfulx. Most of the code sits in the ProjectBox.mxml view, and would probably be better separated out into the appropriate places, but it’s rather convenient having it all in one place for this simple example.

Previously I described a new project to explore a few different client-side/rich web application frameworks such as SproutCore and Cappuccino, by implementing a fairly trivial application in each of them.

In order to see just how loosely coupled this arrangement can be, I’ve implemented a fairly stock Rails application to serve as the back end for all of the front end implementations. Basically this could be done with any server-side framework that can provide a JSON HTTP API, but I chose Rails because that’s what I’ve used the most. This has certain implications, such as making frameworks that are geared toward Rails-style REST APIs seem easier to work with, so that’s worth bearing in mind.

This Rails app basically serves up two resources, projects and project sessions (it would have just been sessions but that name is reserved in Rails). A project can have a name, start date, project status and any number of associated project sessions. Each project session can have a start and end time and a description.

The source over on github at http://github.com/bruz/clocky-backend-rails. It’s nothing to get excited about on it’s own, but will provide a necessary back end from which to build.

Web applications were originally (and necessarily) server-centric, using the web browser as a thin client that just displayed the view. As the use of AJAX has become popular, application behavior has crept onto the client, but is often achieved by Frankenstein methods such as serving HTML snippets with embedded JavaScript that provide some application behavior.

Over the past couple of years several web application frameworks have emerged that put the entire client application on the client (web browser), and use the server just to deliver the application and provide data persistence. A couple of the major advantages of these frameworks: 1) they can deliver desktop-like applications in the browser, and 2) the server can simply provide a set of web services that the application becomes a client of, allowing loose(r) coupling between server and client.

As an exercise to get acquainted with a few of these frameworks, I’ve come up with a trivial project time tracking application that I’ll be implementing in each framework I try out. It’s simple enough that I can implement it in a reasonable amount of time in each framework, but has the following features:

• It uses two models that have a one-to-many relationship between them
• Persistence is provided by a set of JSON web services (using Rails for familiarity reasons)
• It requires a timer view component that isn’t part of any of the frameworks and requires creating a custom view

While there is certainly more that could be added to this application to explore each framework in further depth, I’ve chosen to keep it simple in the interest of time and with the caveat that it is by no means a comprehensive way to explore these frameworks.

Now, on to the question of what frameworks ought to be included in such a comparison. Since there are too many frameworks to allow for trying them all, and there’s no fair way to decide, I’ll just be trying out the ones that for whatever reason spark my interest. Contenders include SproutCore and Cappuccino, but first up will be the lesser known RestfulX.

Update The trivial timer app (Clocky) is done being implemented in RestfulX, SproutCore and Cappuccino. See implementation details for:

• RestfulX
• SproutCore
• Cappuccino