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.<p>I'm curious of other experience using Sproutcore (particularly Sproutcore 2 since there has been a large refactor of code).<p>- How useful are the widgets in a rapid prototyping situation?<p>- 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?<p>- If I build a webapp with Sproutcore, will it be easier to deploy this same app to mobile devices vs something like backbone.js?
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.
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...
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?