The Sweet Spot
On software, engineering leadership, and anything shiny.

GWT vs. SproutCore vs. Cappuccino

I’m looking to develop a Web application with a full-stack Javascript framework like GWT, SproutCore or Cappuccino. I’m making the decision to go with a Javascript framework over a traditional full-stack framework (like Rails) because:

  • I get richer, desktop-like functionality in the browser.

  • I can offload much of the work from the server onto the client.

  • There’s less Javascript hand-coding so I don’t reinvent the wheel.

  • I can bring the desktop app programming paradigm straight to the client.

I’ve been taking a look at GWT (Google Web Toolkit), SproutCore and Cappuccino, and here’s some of my observations so far:

  • GWT is the most mature framework out of the three at 2 years. SproutCore and Cappuccino have emerged only in the last three months.

  • SproutCore is really, really, beautiful. Just look at MobileMe. I’m sure Cappuccino looks much the same. It’s probably because both emulate Cocoa, and so take on the same icon set, window chrome, pane behaviors, and so on.

  • Objective-J sounds cool. I picked up Cocoa over the summer, and to have it on a Web browser is going to be phenomenal.

  • Cappuccino is so new that there aren’t that many apps out there (asides from the storied 280 Slides app). I’m worried that it could be buggy and docs are too sparse.

  • Something about Java in GWT makes me cringe. Maybe it’s just because I’m not used to that extra compilation step. Maybe it’s because I’ve been mucking in dynamic languages for too long of a time.

  • I’m a big sucker for looks. GWT looks pretty frumpy. Honestly, it doesn’t get me excited like SproutCore applications do in all their Aqua-like goodness.

  • The Ext widgets from Ext-GWT are only slightly better. I guess I shouldn’t complain… but gosh, I really like OS X-looking widgets. What can I say, I was brainwashed :)

  • SproutCore and Cappuccino are slower: they simply can’t beat the compiler optimizations of compiled and optimized JS in GWT. Then again… we’re going to have crazy fast JS engines in the next year or so.

  • I considered Dojo. Sort of. I like it because it’s more mature than SC, but it’s slower than GWT and doesn’t have as many widgets as Ext.

Honestly, even though my “ooh-shiny” sense wants to use SproutCore, my objective reasoning tells me to go for GWT for its stronger support, more maturity, better performance and a fuller set of widgets. Anybody else want to weigh in?

Updated portfolio... sort of.

Since I’m in the process of doing some housekeeping around the blog, I’ve begun moving my old design portfolio over to Flickr.

This is sort of an intermediary step to another intermediary step of overhauling my portfolio (yeah, I’ve been meaning to do this for the past five years). Watch this space for updated project briefs to come trickling in.

A layman's guide to the OAI-ORE data aggregation protocol

In Spring 2008, I took an information architecture course in the UC Berkeley School of Information, taught by Erik Wilde (disclaimer: I dropped the course after a month because of schedule conflicts). An interesting part of my research for that class involved investigating the nascent Object Reuse and Exchange (OAI-ORE) protocol, a way of organizing groups of resources across the Web. I’m going to try to describe in laymen’s terms what I learned from my research and explain why it’s significant.

Group things together on the Web

Let’s say you’re looking for a book online. You’ll hit up JStor or Google Books and browse through the pages of that book you found. Easy enough, right?

In reality, the physical, electronic representation of the book online is actually more than just “that book on JStor” or “”. It’s actually a collection of images on a Web server. We need a uniform way to descibe that jStor’ specific online version of “War and Peace” is actually comprised of “page1.jpg”, “page2.jpg”, et cetera.

As another example, let’s say that the local public library wants to create a digital representation of its materials on Jimi Hendrix. Well, the library’s got Jimi Hendrix CDs, Jimi Hendrix books, Jimi Hendrix magazine articles, and so on. With the OAI-ORE protocol, we can create a digital “Jimi Hendrix @ Your Local Public Library” object that lists out each CD, book and magazine article contained in the library.

Let’s say on top of that, a certain Jimi Hendrix biography references “Little Wing” on pages 12, 141 and 254. This “Jimi Hendrix” object is capable of encoding that reference from those pages to “Little Wing” on the “Axis: Bold as Love” album in the library.

Why even have a description framework?

As the Web gets more connected and as we’re seeing the rise of interoperable Web services, it becomes increasingly important to have a standard resource description language. Various protocols (such as RDF) have built a foundation on which to describe relationships between electronic resources.

Think of OAI-ORE as a way of organizing information for re-use by others. If every library created its own “Jimi Hendrix” resource object and made them accessible to others, we could potentially create programs and Web services to collect all “Jimi Hendrix” objects from across the globe and reconstruct the ultimate, canonical Jimi Hendrix electronic resource library. We could note which books made references to “Little Wing.” We could view “Little Wing” as an WMA file, an MP3 file, or as lyrics.

The key is that by standardizing a description language, we enable programmatic ways to collect and synthesize data that can potentially add to the value of the world’s sum knowledge.

Resource maps & implementation formats

OAI-ORE is a specification that defines relationships between resources through an object called the resource map. The resource map is a resource file enumerating a collection of resources and describing the relationships between each resource. Each resource map has its own URI, so it can be discoverable and accessible.

There is no standard file format to encode resource maps. Currently, the OAI-ORE working group has suggested the following description formats (HT: Univ. of Queensland):

  • RDF (Resource Description Framework)
  • Atom syndication format
  • YADS
  • TriX (RDF triples in XML)

The recommended method of describing a resource map is in RDF/XML. I’m not very familiar with the RDF syntax, however, and the TriX format, which affords us RDF triples that can easiliy express relationships between objects and resources, seems to make more sense to me.. However, there is a complete Atom implementation of the protocol, used when syndication is preferred.

I’d definitely refer the reader to the Univ. of Queensland’s OAI-ORE PDF overview for a broader overview of the protocol and its potential implementations.

The nitty-gritty

Collections: Multiple resources can be grouped together, but only via an “aggregate object” or a “collection”, which maintains pointers to each object in a collection.

Links: Links describe relationships between objects in a resource map, such as “has-part” (“War & Peace “-has-part-“page 2”) or “derived-from” (“Radiohead - 15 Step Remix”-derived-from-“Radiohead - 15 Step”). Actual relationships depend on selected vocabularies and namespaces (meaning you can change the link relationships to be whatever you need them to be). There is a list of default namespaces on the spec.

In conclusion

I took a high-level and somewhat abstract tack in describing the protocol, and would direct you to the OAI-ORE Primer for more implementation specifics. Apologies to those of you who were completely lost in this discussion.

I’m excited about developing standards like these because resource mapping protocols such as OAI-ORE are an instrumental step in connecting resources, services and information on the Web. They’ll help us “connect the tubes” and create the infrastructure needed to link the world’s information together. Now that’s pretty cool.

I Like Google Chrome

I have to admit, I am an unabashed fan of Google Chrome, the new Web browser on the block. Why? UI design that shows attention to detail and a really cool backend architecture that gets a lot of respect from me for tossing convention and rethinking things from the ground up, the way they should have been done.Google ChromeThings I like:

  • There is so little clutter. There’s space for your Web pages and apps to breathe. The search bar and status bar and download pane only slide into view when needed, then they get out of your way so you can keep surfing. I love it.
  • The tabs blend right into the title bar and look really, really slick with Windows Vista Aero glass. (Okay, IE7+ gets points for this too).
  • You can pop tabs out from a window with a cool mini-screenshot.
  • Multiprocessed browsing and using the Vista security model: great ideas.
  • V8 Javascript JIT compiling is probably ridiculously complex but reports come in that say it gives us big performance wins.
  • Webkit engine = awesomeness (and I didn’t even have to work at Apple to say that). Hopefully this will speed CSS3 adoption (and don’t even get me started on Webkit’s CSS rounded corners and gradients!).
  • Great use of (color) contrast: the hostame of the site is given a darker color in the location bar. Everything else is grey. It’s all in the details.
  • The Omnibar (location bar) just knows what I want to visit. Credit to Firefox’s Awesome Bar for introducing us to the concept, but Chrome seems more accurate.
  • The downloads bar doesn’t open up a new window, but slides up a little bar that lets you glance at what just got downloaded. Awesome.

Needs to improve:

  • Gmail keyboard shortcuts seem to lose focus once I hit the “Enter” key.
  • I know everybody’s working hard over there, but extensions, please!

So there’s a nagging little voice that warns me that Google’s seriously going to take over the Interwebs with this killer platform. The other voice in me says to give credit to solid engineering and great design where it’s due. This is going to be a game changer, and I’m excited to see what’s in store for the future.

Work Series Graphics - Good Shepherd Christian Church

Part 2 of a summer series:

Work Series

Work Series

Work Series