Yehuda's post on his leaving graciously tells the tale of his work over the last three years and gives plenty of nods to the folks who have worked by his side.
Has anyone tried out Sproutcore on a semi-serious/serious project? I've browsed their source and it looks well-written. I'd love to hear people's experiences.
I used SproutCore heavily from February until the start of the summer, when we pivoted to focus on server-side features for a while. So my information is a bit out of date, and some of the problems described below may have been fixed.
The good: 1) SproutCore's MVC controller support is very nice, and a joy to use. You can wire up a view to an underlying data model, and you get bidirectional data propagation. 2) The SproutCore list view feels like a native widget, with excellent keyboard and mouse integration. 3) SproutCore gets a lot of fundamental architectural decisions correct. It's highly declarative, and you get an enormous amount of functionality for a tiny amount of code.
The bad: 1) SproutCore scrolling is choppy, and two-finger scrolling on the Mac is a mess. This is easy to fix—just use native scrolling—but the core team hasn't gotten around to fixing it. 2) As of this spring, SproutCore had no internal error-checking, which meant that I would spend literally 90% of my programming time in debugging hell. Once I finally figured things out, the answer was always 5 lines of beautiful, undocumented code. 4) The SproutCore testing situation was really shoddy—no Steak/Cucumber-style integration framework, and a dodgy unit test runner.
I _really_ want SproutCore to work. It's a gorgeous framework in so many ways, and as far beyond jQuery as Rails is beyond PHP. But as of early this summer, SproutCore wasn't ready for prime time. Fortunately, there's nothing wrong with SproutCore that a year of Yehuda Katz's time couldn't fix. So I'm really excited about this announcement, and seriously considering returning to SproutCore.
I worked on SproutCore projects at Apple for a couple years on the iWork.com team.
A lot of the pros and cons are similar for any thick framework: if you buy into it, you get a lot of power and functionality for free, but you need to fully buy into it and play the game the framework is playing. When your mandate is to build a web app with the size and feel of a native app, SproutCore is a good choice.
SproutCore is in a class with GWT and Cappuccino in that it's a thick-client framework. It is quite a bit of code that enables you to build powerful applications, but only makes sense if you're building a complex application. It contrasts with a small library like JQuery that is very flexible but only provides the minimum required for bootstrapping an app. Both in principle and in design it's similar to building an app using Cocoa instead of just in C.
I'll echo others' statements about the code and documentation. The docs left something to be desired when I was working with SproutCore, but by reading the code, I became a better JavaScript developer.
Sure. I'm 4 months in of fulltime work on a Sproutcore-based app that is the basis of our startup - we haven't yet launched so I can't point you to it yet unfortunately but I can give you my experiences. In a nutshell:
pros: friendly and helpful community, a number of things that 'just work' and a vocally espoused observers paradigm for wiring up your app that, when it works, is very nice and tidy. Very readable and well documented code base (I've read well over 50% of the codebase now, keep it open in a window all day). Can look very impressive in demos. Deals pretty well with most browsers and platforms (particularly iOS friendly).
cons: Compared to Rails, jQuery, etc... a relatively small community and not a lot of examples to learn from. The wiki is really hit-or-miss and the codebase is pretty much the only reliable source of documentation. Some of the features feel half-baked and like 'some person's pet project'. Some things don't 'just work' and can require a lot of hacking (not in the good way). The build tools are a little slow, which adds 15 seconds or so to every reload (which I do many many times every day, it adds up). Refactoring is a real pain (especially compared to our backend, written in java using eclipse), there just aren't that many tools. That's true of most javascript, but the sproutcore build tools add some 'macros' to javascript (like sc_require();) that really confuse the javascript refactoring tools that do exist.
So refactoring is difficult due to the way in which you interact with Sproutcore's API, or because of a lack of refactoring tooling? The two are completely different. Refactoring != Tooling.
That's true, I shouldn't mix up the two - the real complaint is about the tooling, but it's in refactoring tasks that I really feel it. For example, say I want to rename a class: If I'm in java/eclipse I can command-option-R, type the name, and press enter. Total time about 2 seconds. If I'm in sproutcore I have to search/replace the whole project searching for references which takes minutes and is tedious.
The reason it is difficult is because you can't use any of js tools that leverage a js interpreter - your code isn't valid until it's run through the sproutcore build system (which, as previously mentioned, is pretty slow).
That is pretty much standard in dynamic languages, including Ruby and Python. It's what I miss most about strongly typed languages, like Java and Scala.
I tried sproutcore for a project about 2 years ago and couldn't make the table widget work with page up, down etc.
Instead I finalized on qooxdoo - http://qooxdoo.org/ and was impressed with it and the mailing list was and is responsive and the developers from 1&1 quick to fix any bugs I found :)
And I finally had the table widget I always wanted with keyboard shortcuts for all the things I wanted.
Of course, it could be me not knowing enough to make sproutcore's table widget work like I wanted, since I was only a beginner in JS back then.
Edit: The demo at http://demo.sproutcore.com/table_view/ for the table still doesn't work with page up or page down. Maybe the feature is there, but not enabled for this demo.
I tried it out on http://truedat.net. It's very cool, but the minimalness of documentation made it a bit of a slog, and certain incompatibilities with IE made it a deal-breaker for the time being.
I intend to revisit it once the Quilmes release (v1.5) is out the door.
This is indeed big news! I really hope this means SproutCore will finally be a mature framework. The biggest thing that I've found annoying with it was the UI builder's not so stellar performance, other than that, they got a lot of things right.
The post no longer mentions SproutCore, instead referring to "a new startup in the mobile applications space." A comment mentioning SproutCore remains, however.
Yehuda really did an amazing job with Rails 3.0, both in improving the architecture and explaining the decision made.
I don't know much about SproutCore yet, but I'm definitely going to take a closer look now. I also don't know much about node.js yet, but it seems that might be a good companion for SproutCore, so I wonder if Yehuda will go that route as well.
http://yehudakatz.com/2010/09/14/heres-to-the-next-3-years/