12 ms·

SproutCore 1.4 has been released

45 points by devinus 16y ago

eof 16y ago
I'd really like to hear the thoughts of anyone who has put SproutCore to significant use.
- scotth 16y ago
  I asked this a few days ago. See replies. http://news.ycombinator.com/item?id=1692675 http://news.ycombinator.com/item?id=1692675
- wycats 16y ago
  What kind of use are you thinking about using SproutCore for?
  - catch23 16y ago
    Would sproutcore still play nice in a development cycle if I only wanted to use it for a nice shopping cart implementation, but use adhoc javascript everywhere else on a website? The last time I looked at it, it seemed to only excel if you needed to implement one giant js application.
    - devinus 16y ago
      Yes, we plan on doing this. It's as simple as having the shopping cart page be SC and the rest ad-hoc, or the shopping card within an iframe.
      - catch23 16y ago
        I don't really consider the iframe-style as a valid integration point though. You could technically hide anything inside an iframe. The iframe makes it significantly harder to integrate because all your javascript will essentially need to do cross frame communication type crap just to tell the "other guy" what to do. Plus, depending how you stack your iframes, your inner iframes may not be able to do overlays on your parent frame. Iframes in general is just an ugly hack and should be reserved for actual cross-domain type scenarios. However, I am looking forward to the ad-hoc style integration if that's possible.
        wycats 16y ago
        iframe would be the lowest-level of integration. A better solution would allowing a SC app to take over a specific element on the page, and we're definitely looking at that solution. Another perfectly worthy solution might be to theme the SC app so it looks like your main app.
- city41 16y ago
  As would I, as "pushing the data onto the client and using it from there" is by far my biggest issue with Silverlight. I was surprised to see a framework that specialized in doing this.
  - paulitex 16y ago
    I wouldn't say sproutcore specializes in pushing data to the client, it really is a 'full stack' client side framework. That said, this is one thing that sproutcore does do quite well, the interface for hooking up to JSON datasources is very simple and effective (particularly useful are cascading data sources, which they've recent added and really cleans up the code where there used to be huge if-else if blocks on queries inside your data source file).
  - therockhead 16y ago
    What don't you like about that approach?
    - city41 16y ago
      There are a lot of things I don't like about it. But in all honesty my dislike might actually be how RIA Services implemented the approach, not the approach itself. I am currently writing a big blog entry going in to details on this. I'll let you know when it's posted.
wycats 16y ago
I just want to say that I'm psyched to be a new member of the SproutCore community. It's a lot stronger than it looked from the outside, and two of the most exciting features in the 1.4 announcement (GreenHouse and SCXIB) are community projects through and through. I also can't wait to start rolling out the documentation work we've been working on. If there's one thing we need, it's better documentation, and getting some full-time OSS love is really going to make the difference.
- railsjedi 16y ago
  Awesome. Sproutcore project has a lot of potential. I was dabbling with Sencha for some mobile client app work, but with the new touch functionality in SproutCore 1.4, it's taken back my interest. You're right on about the documentation. As of a few months ago, it seemed very daunting to start a new SproutCore project (especially with the update from 0.9 -> 1.0). A solid doc site (like Rails Guides) and maybe a few paid books / screencast series would go a long way. A good example is AppCelerator, which does a really good job with premium training classes and I think it's really helped them get developers onboard. The work Charles did a while back on SproutCasts was pretty awesome. Would be great to see more of those.
- SkyMarshal 16y ago
  High on my todo list has been to really learn one of SproutCore or Cappuccino and build something cool with it, but I've been torn between which one to start with. Initially I was leaning toward Cappuccino, but recent announcements (yours, and Motorola buying Cappuccino) have me leaning toward starting with SproutCore now. Did you consider Cappuccino at all when making you decision? What's your take on the relative strengths and weaknesses of the two platforms and their communities (if you've dabbled enough in Cap to have opinions on this)?
- necubi 16y ago
  As someone who learned sproutcore last fall, I found the documentation really lacking, and it hasn't gotten much better since then. Mostly I learned by reading the source code, which fortunately is very clear, but that's too much effort for most people to take. Regardless, I'm very excited for 1.4. There was so little public progress since 1.0.1042 was released that it seemed as if the project had lost momentum. I'm glad to see that's not the case and that Strobe is pushing ahead to improve things.
Isofarro 16y ago
I wonder if there are any examples of SproutCore being used in a decently progressively enhancing way. The last time I looked through, JavaScript disabled/unavailable view was an empty div. Might be strange to pick up the lack of attention on progressive enhancement from a JavaScript library developer group, but take a look at what davglass is doing with YUI and node.js in terms of progressive enhancement (for example http://ajaxian.com/archives/progressive-enhancement-using-nothing-but-javascript http://ajaxian.com/archives/progressive-enhancement-using-no... ). The ability to run the same javascript on the client and the server introduces a powerful new way to do progressive enhancement, this opens up possibilities of taking a very rich interactive application that works decently enough on a constrained platform/network (very much directly aimed at the Sprout Core "we do web applications not websites so we don't have to bother about non-javascript" philosophy at their original launch) The ability to build upon what's already there is important. So a solid approach to progressive enhancment is necessary for any JavaScript library that wants to be anywhere near web developer mainstream.
- glhaynes 16y ago
  It seems like "ability to run JavaScript" is as much a core requirement of a browser as "ability to render HTML" at this point. Are users with JavaScript turned off really worth targeting?
  - Isofarro 16y ago
    There are other causes of JavaScript not being run in a browser than a visitor turning JavaScript off. A mobile phone running off a flaky 3G network is still a common issue outside of Silicon Valley. The ability to support your intended audience is still an important factor in building websites.
    - catch23 16y ago
      Yes, but if you're targeting mobile devices, you can load them a different set of javascript that would be lighter load on the network. I think it's kind of pointless to use something like Unobtrusive Javascript support because if you're one of those users with javascript disabled, we probably wouldn't want you as our target audience anyway.

45 points by devinus 16y ago

eof 16y ago

I'd really like to hear the thoughts of anyone who has put SproutCore to significant use.

scotth 16y ago
I asked this a few days ago. See replies. http://news.ycombinator.com/item?id=1692675 http://news.ycombinator.com/item?id=1692675
wycats 16y ago
What kind of use are you thinking about using SproutCore for?
- catch23 16y ago
  Would sproutcore still play nice in a development cycle if I only wanted to use it for a nice shopping cart implementation, but use adhoc javascript everywhere else on a website? The last time I looked at it, it seemed to only excel if you needed to implement one giant js application.
  - devinus 16y ago
    Yes, we plan on doing this. It's as simple as having the shopping cart page be SC and the rest ad-hoc, or the shopping card within an iframe.
    - catch23 16y ago
      I don't really consider the iframe-style as a valid integration point though. You could technically hide anything inside an iframe. The iframe makes it significantly harder to integrate because all your javascript will essentially need to do cross frame communication type crap just to tell the "other guy" what to do. Plus, depending how you stack your iframes, your inner iframes may not be able to do overlays on your parent frame. Iframes in general is just an ugly hack and should be reserved for actual cross-domain type scenarios. However, I am looking forward to the ad-hoc style integration if that's possible.
      - wycats 16y ago
        iframe would be the lowest-level of integration. A better solution would allowing a SC app to take over a specific element on the page, and we're definitely looking at that solution. Another perfectly worthy solution might be to theme the SC app so it looks like your main app.
city41 16y ago
As would I, as "pushing the data onto the client and using it from there" is by far my biggest issue with Silverlight. I was surprised to see a framework that specialized in doing this.
- paulitex 16y ago
  I wouldn't say sproutcore specializes in pushing data to the client, it really is a 'full stack' client side framework. That said, this is one thing that sproutcore does do quite well, the interface for hooking up to JSON datasources is very simple and effective (particularly useful are cascading data sources, which they've recent added and really cleans up the code where there used to be huge if-else if blocks on queries inside your data source file).
- therockhead 16y ago
  What don't you like about that approach?
  - city41 16y ago
    There are a lot of things I don't like about it. But in all honesty my dislike might actually be how RIA Services implemented the approach, not the approach itself. I am currently writing a big blog entry going in to details on this. I'll let you know when it's posted.

wycats 16y ago

I just want to say that I'm psyched to be a new member of the SproutCore community. It's a lot stronger than it looked from the outside, and two of the most exciting features in the 1.4 announcement (GreenHouse and SCXIB) are community projects through and through. I also can't wait to start rolling out the documentation work we've been working on. If there's one thing we need, it's better documentation, and getting some full-time OSS love is really going to make the difference.

railsjedi 16y ago
Awesome. Sproutcore project has a lot of potential. I was dabbling with Sencha for some mobile client app work, but with the new touch functionality in SproutCore 1.4, it's taken back my interest. You're right on about the documentation. As of a few months ago, it seemed very daunting to start a new SproutCore project (especially with the update from 0.9 -> 1.0). A solid doc site (like Rails Guides) and maybe a few paid books / screencast series would go a long way. A good example is AppCelerator, which does a really good job with premium training classes and I think it's really helped them get developers onboard. The work Charles did a while back on SproutCasts was pretty awesome. Would be great to see more of those.
SkyMarshal 16y ago
High on my todo list has been to really learn one of SproutCore or Cappuccino and build something cool with it, but I've been torn between which one to start with. Initially I was leaning toward Cappuccino, but recent announcements (yours, and Motorola buying Cappuccino) have me leaning toward starting with SproutCore now. Did you consider Cappuccino at all when making you decision? What's your take on the relative strengths and weaknesses of the two platforms and their communities (if you've dabbled enough in Cap to have opinions on this)?
necubi 16y ago
As someone who learned sproutcore last fall, I found the documentation really lacking, and it hasn't gotten much better since then. Mostly I learned by reading the source code, which fortunately is very clear, but that's too much effort for most people to take. Regardless, I'm very excited for 1.4. There was so little public progress since 1.0.1042 was released that it seemed as if the project had lost momentum. I'm glad to see that's not the case and that Strobe is pushing ahead to improve things.

Isofarro 16y ago

I wonder if there are any examples of SproutCore being used in a decently progressively enhancing way. The last time I looked through, JavaScript disabled/unavailable view was an empty div. Might be strange to pick up the lack of attention on progressive enhancement from a JavaScript library developer group, but take a look at what davglass is doing with YUI and node.js in terms of progressive enhancement (for example http://ajaxian.com/archives/progressive-enhancement-using-nothing-but-javascript http://ajaxian.com/archives/progressive-enhancement-using-no... ). The ability to run the same javascript on the client and the server introduces a powerful new way to do progressive enhancement, this opens up possibilities of taking a very rich interactive application that works decently enough on a constrained platform/network (very much directly aimed at the Sprout Core "we do web applications not websites so we don't have to bother about non-javascript" philosophy at their original launch) The ability to build upon what's already there is important. So a solid approach to progressive enhancment is necessary for any JavaScript library that wants to be anywhere near web developer mainstream.

glhaynes 16y ago
It seems like "ability to run JavaScript" is as much a core requirement of a browser as "ability to render HTML" at this point. Are users with JavaScript turned off really worth targeting?
- Isofarro 16y ago
  There are other causes of JavaScript not being run in a browser than a visitor turning JavaScript off. A mobile phone running off a flaky 3G network is still a common issue outside of Silicon Valley. The ability to support your intended audience is still an important factor in building websites.
  - catch23 16y ago
    Yes, but if you're targeting mobile devices, you can load them a different set of javascript that would be lighter load on the network. I think it's kind of pointless to use something like Unobtrusive Javascript support because if you're one of those users with javascript disabled, we probably wouldn't want you as our target audience anyway.