ColinCampbell

The important thing is that client-side rendering stays on the client and doesn't need to go back to the server. If you have any noticeable latency (read: everything on mobile, desktop clients not close to a server), needing to go back to the server to render will ruin the perceived performance of your app. Well-written applications running on the client can take a change and optimistically render that before the change has even been persisted back to the database. This is inherently faster. If you're able to invest in the infrastructure to allow you to do this on the server, and your use cases allow you to make that decision, then the trade-off is a little less black and white.

I have a subscription to the Atlantic because of reading the articles and their blogs online. I don't think it would be incorrect to attribute their turnaround in going digital first. I've been reading their properties for years and there was definitely a change (perhaps in just attitude).

We're definitely working on the documentation situation. We learned hard lessons with the 1.x series, which remained undocumented for far too long. If you want to send me an email and let me know what you thought was lacking in the docs (can be as specific or general as you'd like), I'd really appreciate it: colin at sproutcore dot com

The problem is there is no guarantee they will play nicely together, not clash, or provide similar and compatible APIs. JavaScript developers are running into a very similar set of problems and having everyone cobble together their own solutions is pretty clearly not an answer, which obvious to those who have tried. You may already know what is being abstracted by some of the more expansive frameworks (Cappuccino, SproutCore, Backbone, etc) but there are a lot of people who do not know or do not want to deal with the differences in browsers, etc.

I'm assuming that you don't consider jQuery or its ilk restrictive as far as abstracting the DOM. I don't know of many application developers who would prefer to deal with the low-level DOM API (which differs across browsers, etc) instead of a library like jQuery. There are many people who approach application structure from a similar viewpoint. Instead of rolling their own and running into problems scaling and maintaining their applications, they can use a framework that provides an abstraction that is proven to work. Everyone tries to roll their own pet framework project because that's where the glory is. That's not necessarily the best thing for the future of the web.

Fair points all around; I agree wholeheartedly. Here's what the problem has been thus far: do we focus on making the framework better, or do we focus on selling it? Personally, I'm much more comfortable with making sure we deliver the goods before we try to sell it. That's what SproutCore 1.5 is about. This is the first smoke signal of where we want to head with the framework, and people can take that for what it is. The core of the framework is amazing and fun to work with, but a lot of our demos are old and ugly. In many cases, our documentation has been or is still lacking and we're working on that too.

This obviously makes it a tougher sell. However, when people actually start building apps, their responses are overwhelmingly positive and they're very happy with their decision. I would much rather this problem than vise versa. We're going to work on the outward facing stuff, I promise.

We have a link to our, albeit totally old and crappy, demos right on that page: http://demo.sproutcore.com/

We're working on new demos, and a new website. Demos feature much more heavily in the new design, and you definitely don't (and won't) need to install the build tools to run them!

I wholeheartedly agree that SproutCore's documentation is poor. There have been plenty of reasons (and excuses) provided, but regardless, that still doesn't cut it. We're beginning to rectify the situation with Guides (http://guides.sproutcore.com) which was announced on Friday. There is already one written (http://guides.sproutcore.com/fixtures.html) and there are more in the pipeline, being written by both core team members and developers from the community. Given we're a startup, sometimes things need to take a backseat but Strobe is definitely committed to making developing web apps as easy as possible and documentation is high on the priority list.

Side note: I work for Strobe.

Yehuda has already made some fantastic changes to the Abbot build tools that should be landing with the 1.4 release any day. It's in rc2 right now, just run gem install sproutcore --pre, the tools are super fast now.

Greenhouse isn't ready to be compared to Atlas just yet, the development has only been ongoing for a matter of weeks. That being said, Atlas costs money, and Greenhouse is completely open source:

http://github.com/sproutit/sproutcore/tree/mg/master

If you're more comfortable with Obj-C/J, then Cappuccino is the way you should go. Personally I use SproutCore because I'm far more comfortable in JS/HTML/CSS.