Announcing SproutCore 2.0 Developer Preview(blog.sproutcore.com)
blog.sproutcore.com
Announcing SproutCore 2.0 Developer Preview
http://blog.sproutcore.com/announcing-sproutcore-2-0/
9 comments
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.
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.
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.
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.
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.
Interesting that they're reducing the emphasis on native look and feel. The thing that's put me off all the native-mimicking JS libs like EXT and Sproutcore is that making web apps imitate native desktop apps seems like the wrong move in many cases. The web gives us a chance to rethink a lot of those old assumptions and newer, cleaner interfaces like Github etc. suggest that some of those old assumptions can be abandoned.
I agree that html freedom has done a lot to user interfaces and ux. But that works best in a web setting.
In an intranet setting (the kinda place where IE6 may still linger for 2-3 years) using standardized RIA frameworks like ExtJS help speedup the development cycle by offloading 80% of the design work from the 1000+ developers, which probably already have a handful trying to figure out in which order a certain financial transaction needs to be called on the Mainframe CICS-DB2.
In an intranet setting (the kinda place where IE6 may still linger for 2-3 years) using standardized RIA frameworks like ExtJS help speedup the development cycle by offloading 80% of the design work from the 1000+ developers, which probably already have a handful trying to figure out in which order a certain financial transaction needs to be called on the Mainframe CICS-DB2.
I spent the last ten years writing intranet apps and evaluated and rejected EXT and similar frameworks several times because it just didn't meet our internal users' needs. They preferred our lightweight interfaces that rendered quickly and well on all kinds of different devices.
However, our environment was a little unusual in that we were able to mandate reasonably modern browsers (FF 3+, Webkit).
However, our environment was a little unusual in that we were able to mandate reasonably modern browsers (FF 3+, Webkit).
Note: they're announcing 2.0, not releasing anything ready for prime time.
The announcement indicates that they're releasing SproutCore 2.0 Developer Preview with the caveat: "SproutCore 2.0 is still under heavy development and APIs are likely to change."
The announcement indicates that they're releasing SproutCore 2.0 Developer Preview with the caveat: "SproutCore 2.0 is still under heavy development and APIs are likely to change."
I updated the title of the post to more accurately reflect that this is a Developer Preview release. Apologies for any confusion on our part.
Looks more lightweight now, but still it's 12k LOC vs 1k LOC in Backbone. Need to look through, what do those 11k offer :)
Pure JS and drop-in integration is good too, we are a Java shop and lots of developers working on Windows, so introducing a Ruby-dependent JS framework would be hard in my case.
Previously we also considered SC as a 'heavy' JS solution - like Cappuccino, ExtJS or GWT(we used GWT for complex backends - it allowed us to share UI&server code), but now we'll have another look at it as an alternative to Backbone for frontends/mobile.
Pure JS and drop-in integration is good too, we are a Java shop and lots of developers working on Windows, so introducing a Ruby-dependent JS framework would be hard in my case.
Previously we also considered SC as a 'heavy' JS solution - like Cappuccino, ExtJS or GWT(we used GWT for complex backends - it allowed us to share UI&server code), but now we'll have another look at it as an alternative to Backbone for frontends/mobile.
I'm helping a colleague of mine get into a RIA start-up and the original development he used ASP MVC on Windows. Do you know if any of the RIA JS frameworks play nicely with ASP MVC?
I've used ExtJS with ASP.NET MVC for a few years, and it was quite nice. Just have the controller functions return JSON serialized data instead of a regular view. If decoupling the UI from the server side portion of the app isn't a concern you can also use Ext.Direct, which will allow you to call your server side controller methods from JavaScript by just doing:
ControllerName.FunctionName(arg0, arg1, callbackFn);
ControllerName.FunctionName(arg0, arg1, callbackFn);
How about Knockout? So it's not a 'full' RIA JS framework, but in my mind, that's no bad thing:
http://knockoutjs.com/
It feels like a nice fit to MVC/MS stuff (there's certainly plenty of examples of this, and Steve Sanderson now works for MS). And it's easy to bind whatever UI you want to your view models.
Personally I now use KO for even the smallest of JS/HTML 'apps'. It's lovely :)
It feels like a nice fit to MVC/MS stuff (there's certainly plenty of examples of this, and Steve Sanderson now works for MS). And it's easy to bind whatever UI you want to your view models.
Personally I now use KO for even the smallest of JS/HTML 'apps'. It's lovely :)
There's an annotated Todo app source code just like Backbone.js (awesome!) ... however no link to the actual app hosted somewhere so I can play with it and experience the interaction.
Check it out at http://todos20.strobeapp.com/
thanks!! Anyone else have any useful links? I am looking forward to doing my first hello Sproutcore app and would love to know about the best blog posts, etc.
To me one of the more compelling things about Sproutcore in comparison to other Javascript MVC/binding frameworks (Backbone.js, Knockout, Angular.js, JavascriptMVC, etc) was that it seemed to offer a beautiful UI toolkit that was modern-looking and tailored to web apps.
Is part of the plan to shift focus away from that UI aspect?
If not, is there a tutorial on how to put together a simple app that uses some of the available UI components?
Thanks guys, keep up the great work.
Is part of the plan to shift focus away from that UI aspect?
If not, is there a tutorial on how to put together a simple app that uses some of the available UI components?
Thanks guys, keep up the great work.
From what I've read, there doesn't seem to be a lot of difference between SC 2 and Backbone.js. Can anyone point out when someone would go for SC 2 instead of Backone.js.
I've been evaluating Backbone, Spine, JavascriptMVC, Knockout.js, and Sproutcore 2. What I like most about SC2 is the direct support for key-value coding, including bindings and reusable well-defined controllers.
I also find the 5-layer [Model, Model-Controller, Controller, View-Controller, View] better for my OO coding style and isolation of dependencies — but that's probably more of a personal quirk.
I also find the 5-layer [Model, Model-Controller, Controller, View-Controller, View] better for my OO coding style and isolation of dependencies — but that's probably more of a personal quirk.
Would this be suitable for a mobile app? The existing view builder in sproutcore made that a no-go. But with HTML views it might have potential.
If you look at most mobile-optimized web applications today, they tend to be very "web-style," which SproutCore 2.0 is great for.
In the next few months, we will be working on a mobile control set that allows you to create more "native-style" interactions. I think both have their place and can deliver awesome experiences to users.
In the next few months, we will be working on a mobile control set that allows you to create more "native-style" interactions. I think both have their place and can deliver awesome experiences to users.
Great move guys! I've been working with SproutCore for a couple of years now, and reducing the framework overhead and ditching the ruby tool chain is a great step in the right direction. sproutcore.com is looking shinier than ever, and the NPR web app is awesome. I'm not even sure how you got streaming audio in a web page on the iPad.
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.