SproutCore: smart clients, dumb servers

I heard about SproutCore recently, from an enthusiastic client-side web developer. I hadn’t heard about it, which is not entirely unsurprising as it turns out – SproutCore came out of hiding as something of a surprise at the recent Apple Worldwide Developers Conference, as the power behind the slick interfaces for Apple’s new suite of MobileMe applications.

I’ve had a look. The clearly exciting thing, from my point of view, is that SproutCore produces static HTML, CSS and JavaScript. And it does this by asking you to write JavaScript. So, that’s a good thing. Static web applications are easy to scale and are looked on favourably by search engines. The interaction with any server-side (for data storage or web service access) is done using their simple REST API.

It almost looks like SproutCore has been designed as my web development framework of choice – the problem is that SproutCore uses a Ruby-based templating language called “Erubis” to create what it terms “views” (in the Model-View-Controller tradition); these are essentially the structure for the web pages. So the development behaviour becomes: do your coding in JavaScript and Ruby, compile the whole thing down to HTML, CSS and JavaScript and then upload to the server. I would have thought it would make more sense to write your templates in something that resembled HTML in the first place, and perhaps made use of JavaScript.

Notwithstanding the small deviation from the HTML, CSS, JavaScript toolset, SproutCore takes the idea of smart clients and dumb servers seriously, and does so more than any other web development framework out there.

Advertisements

One Comment

  1. Posted July 4, 2008 at 2:27 am | Permalink

    The whole thin/thick client/server thing … I never felt it got settled.

    Or, rather, historical events drove certain solutions, but I didn’t feel that it all was being driven by foundationally sound thinking. GTD rulez, of course, but …

    I think the scaling problems Twitter encountered could (/could/ … plausibly) be looked at as a case for this.
    For my money the server’s being called too often … I can’t say the downloaded page is too thick, though it’s surprisingly heavy.

    Without data to go by, what’s harder to handle: a request for a lot of code? or multiple requests for bits and pieces?

    TW is as thick as I’ve seen. In it’s way it’s pure / paradigmatic.