7 ms·

Announcing SproutCore 2.0 Developer Preview

130 points by jtaby 15y ago

hallman76 15y ago
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."
- jtaby 15y ago
  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.
grandalf 15y ago
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.
- wycats 15y ago
  Check it out at http://todos20.strobeapp.com/ http://todos20.strobeapp.com/
  - grandalf 15y ago
    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.
dmix 15y ago
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.
- tomdale 15y ago
  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.
ynniv 15y ago
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.
arturadib 15y ago
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.
- rbranson 15y ago
  I think that was exactly the problem with SproutCore -- it was essentially inseparable from it's UI toolkit.
- okito 15y ago
  We are not shifting away from the UI - we are just making it less monolithic. Look for more news on this soon.
cageface 15y ago
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.
- ojosilva 15y ago
  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.
  - cageface 15y ago
    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).
jashkenas 15y ago
Many congrats on the preview release. 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 15y ago
  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.
  - jashkenas 15y ago
    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.
    - boucher 15y ago
      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.
  - tomdale 15y ago
    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.
lapusta 15y ago
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.
- mbesto 15y ago
  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?
  - dogonwheels 15y ago
    How about Knockout? So it's not a 'full' RIA JS framework, but in my mind, that's no bad thing: http://knockoutjs.com/ 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 :)
  - nxn 15y ago
    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);
minhajuddin 15y ago
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.
- shanewholloway 15y ago
  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.
- humblepatience 15y ago
  yeah, i'm confused about this too

130 points by jtaby 15y ago

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."

jtaby 15y ago
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.

grandalf 15y ago

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.

wycats 15y ago
Check it out at http://todos20.strobeapp.com/ http://todos20.strobeapp.com/
- grandalf 15y ago
  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.

dmix 15y ago

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.

tomdale 15y ago
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.

ynniv 15y ago

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.

arturadib 15y ago

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.

rbranson 15y ago
I think that was exactly the problem with SproutCore -- it was essentially inseparable from it's UI toolkit.
okito 15y ago
We are not shifting away from the UI - we are just making it less monolithic. Look for more news on this soon.

cageface 15y ago

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.

ojosilva 15y ago
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.
- cageface 15y ago
  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).

jashkenas 15y ago

Many congrats on the preview release. 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 15y ago
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.
- jashkenas 15y ago
  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.
  - boucher 15y ago
    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.
- tomdale 15y ago
  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.

lapusta 15y ago

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.

mbesto 15y ago
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?
- dogonwheels 15y ago
  How about Knockout? So it's not a 'full' RIA JS framework, but in my mind, that's no bad thing: http://knockoutjs.com/ 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 :)
- nxn 15y ago
  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);

minhajuddin 15y ago

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.

shanewholloway 15y ago
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.
humblepatience 15y ago
yeah, i'm confused about this too