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.
"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.
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.
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."
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.
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?
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.
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?
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.
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.
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.
[+] [-] jashkenas|15 years ago|reply
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.
[+] [-] boucher|15 years ago|reply
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.
[+] [-] foobarbazoo|15 years ago|reply
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.
[+] [-] cageface|15 years ago|reply
[+] [-] ojosilva|15 years ago|reply
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.
[+] [-] hallman76|15 years ago|reply
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."
[+] [-] jtaby|15 years ago|reply
[+] [-] lapusta|15 years ago|reply
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.
[+] [-] mbesto|15 years ago|reply
[+] [-] grandalf|15 years ago|reply
[+] [-] wycats|15 years ago|reply
[+] [-] arturadib|15 years ago|reply
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.
[+] [-] rbranson|15 years ago|reply
[+] [-] okito|15 years ago|reply
[+] [-] minhajuddin|15 years ago|reply
[+] [-] shanewholloway|15 years ago|reply
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.
[+] [-] humblepatience|15 years ago|reply
[deleted]
[+] [-] dmix|15 years ago|reply
[+] [-] tomdale|15 years ago|reply
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.
[+] [-] ynniv|15 years ago|reply