In my opinion, this is a brave move from the team -- acknowledging that the SproutCore approach from the past four years needs to be ditched in favor of a brand-new codebase, and one that's a small fraction of the size (both code and API-wise) of the previous SproutCore.
Even though it's not recommended right now, I imagine that in due time SC 2.0 will also be recommended for "desktop-style" web applications, and when that happens, it'll be a force to be reckoned with.
It strikes me as less than brave, especially when you consider that 1.0 and 1.5 were also essentially backwards incompatible rewrites.
This update seems to move SproutCore away from what made it unique and towards something that mostly resembles what everyone else writing web frameworks is doing.
Totally -- but it takes balls to acknowledge that. I'd certainly feel betrayed if I had been a loyal SproutCore user: templates for the user interface is almost a complete 180° from the prior gospel.
But from an outside perspective, I think this could make SC truly competitive, and that's going to be a good thing for JavaScript-heavy web apps in general.
I'm not actually sure if the idea of templates alone is that much of a departure, I could see something template like working in Cappuccino (a more human readable version of a XIB perhaps), but relying on HTML and CSS is something I'm obviously not crazy about.
It seems pretty strange for you to say that given that you must also realize that the framework you maintain, Cappuccino, is veering towards obsolescence.
I think Aristo is a great theme, and better than the default SproutCore theme, but even it is starting to look dated. Web-style apps are similarly impossible with Cappuccino; I find it hard to believe you don't think there is value in bringing Objective-J to all web developers, not just those who opt-in to your view layer. Objective-J could be filling the same role CoffeeScript is now if that was the case.
SproutCore 1.5 was certainly backwards compatible with 1.0, and will continue to be maintained by companies that together have revenue in the billions. We just realized that the path we were on forced us to cater to a small niche. When you can provide value to a market at least an order of magnitude larger, why not do it?
We're not giving up on native-style interaction, and I think people will love the stuff we're working on right now. As I said in the blog post, this is just the first milestone on the way to that release.
It's also bold, and kind of silly, to suggest Cappuccino is veering toward obsolescence Tom. The only real argument you've given is that Aristo looks dated (which isn't exactly a scientific claim). Also, it's pretty important to understand that you don't have to keep the view layer (AppKit). The Foundation framework of Cappuccino runs on the server, and I'd imagine with little effort could run in the browser as well.
"acknowledging that the SproutCore approach from the past four years needs to be ditched in favor of a brand-new codebase"
This is just flat out incorrect. SC 2 is a more moduler SC 1.x runtime, not an entirely new codebase. Similarly, SC 1.x apps will be able to run almost unchanged on SC 2 once their UI frameworks are updated for the changes in the SC 2 runtime.
The only "change" is that instead of making Web-app style opt-in, and Desktop-style the default, Web-app style is now the default and Desktop-style is opt-in. That change could have easily been made on the SC 1.x runtime as well, but it makes the most sense to do it on the modular, tighter SC 2 runtime for obvious reasons.
In my opinion, this is a brave move from the team -- acknowledging that the SproutCore approach from the past four years needs to be ditched in favor of a brand-new codebase, and one that's a small fraction of the size (both code and API-wise) of the previous SproutCore.
Even though it's not recommended right now, I imagine that in due time SC 2.0 will also be recommended for "desktop-style" web applications, and when that happens, it'll be a force to be reckoned with.