Thursday, May 20, 2010

I love Sproutcore, but I hate it.

Sproutcore is awesome -- it's a framework for building rich web applications. It's got a lot of nice widgets, the default theme is pretty, and it uses an MVC-style pattern.

The problem is, I hate it.

A long time ago, I used to be a desktop developer, primarily .NET apps. Unlike HTML, when you're creating the user interface for a desktop application, there's no markup language you can use, like HTML. Instead of this:

You write this:

b =;
b.Text = "Click me!";
b.Position = new Position(1,1);

Now imagine a user interface full of buttons, tabs, and other things to play with, and you'll see where I'm going with the second half of this post title.


Once you see how the UI is laid out in Sproutcore, it's like shell-shock; it immediately takes me back to the days of writing desktop app UIs, and that is terrible. I consider Sproutcore worse, though, because the end result of defining your UI through Sproutcore ends up being HTML! Man, I love me some exclamation marks, btw.

I mean, if we're going to render in browsers anyway, I think it'd be better to exploit what browsers already have, which is the DOM. Facebook does it with its tags, so I don't see why Sproutcore can't do it with its own tags. Will there be a slight delay as the custom tags get processed? Yeah. But the delay is minimal... and I'd deal with the delay rather than the misery of laying out UI elements in code.

And no, visual designers that just output the code for laying out a UI is not a substitute. Anyone who has done some heavy UI hacking knows that once you hit a certain point the designer just gets in the way -- and worse, all the designer-generated code is terrible, and trudging through it is like walking across hot coals.

So, I love Sproutcore, but when it comes to hacking out the user interface, it is not my cup of tea. For a few small internal applications, it's OK -- the UI drudgery isn't much -- but there's no way I'm breaking out a large interactive application using it.