Great article - I've been building recently with backbone / jasmine using client-side fixtures. Architecture is a bit different than Sproutcore, so the data fixtures come need to match with server rest calls (vs client-side data store). This means mocking both the ajax calls and the html as fixtures.
I'm curious of other experience using Sproutcore (particularly Sproutcore 2 since there has been a large refactor of code).
- How useful are the widgets in a rapid prototyping situation?
- Upon initial inspection, the state-model of Sproutcore records seems to be overly complex (ie, not very elegant). How does this design pattern work in the real world?
- If I build a webapp with Sproutcore, will it be easier to deploy this same app to mobile devices vs something like backbone.js?
The widgets are really useful. Your apps will not be very different if you use them with the same theme every time but I think it's ok for a demo to show customers during the Problem Interview phase.
I agree that the state model is a bit overly complex but if you go past the learning curve it can work well. Also there are ways to kind of bypass it and use an approach more similar to what Backbone/Spine does. There is a recent blog post by the SC team that shows you you can do that with 2.0 branch: http://blog.sproutcore.com/sproutcore-2-and-ajax/
I went through all of the javascript frameworks and found Sproutcore to be extremely confusing. A lot of the documentation and tutorials just aren't there to make it a mature choice. I'd say Sproutcore is more cutting edge than state of the art.
I can see why you would say that, especially back when we initially started looking at it (before Yehuda went over to Strobe), but more recently the docs/tutorials have become much better. We have invested a decent amount of time learning the framework and it has become really productive for us. Also, I haven't seen anyone using statecharts with the other frameworks. Not that they aren't, just haven't seen it. If you don't really know what statecharts are or what it means to have one backing your application, I would recommend just looking into it. It was eye-opening (for me at least).
Another great post Luc. It's really been bumming me out that more people aren't talking about statecharts and web app development (especially with Sproutcore). After developing web apps for over a decade, watching Erich Ocean's course on statecharts with Sproutcore was a eureka moment for me. It was like, "Finally, a sane, testable, non-hacky-feeling way to build responsive web front-ends!"
Really like the idea of using the scientific method to come up with a business plan. Keeps steps defined and eliminates some of the terror of developing a plan that will do justice to a product...
It is more than a business plan. I have been reading Eric Ries's The Lean startup, and I find that the ideas shown there are more focused as defining a process to deal with uncertainty in startups using scientific methods. It is amazing!.
It definitely helps your business plan, but I think it goes beyond just the business plan, it actually provides a process to align and direct your startup to success.
I wonder if this approach could be used for more "static" sites as well? This sounds great for JavaScript-heavy web apps, but what if there's server-side HTML generation involved?
I'm curious of other experience using Sproutcore (particularly Sproutcore 2 since there has been a large refactor of code).
- How useful are the widgets in a rapid prototyping situation?
- Upon initial inspection, the state-model of Sproutcore records seems to be overly complex (ie, not very elegant). How does this design pattern work in the real world?
- If I build a webapp with Sproutcore, will it be easier to deploy this same app to mobile devices vs something like backbone.js?