SproutCore 1.4 has been released

http://blog.sproutcore.com/post/1157172526/announcing-sproutcore-1-4

by devinus • 16 years ago

45 30 16 years ago

blog.sproutcore.com

eof• 16 years ago

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

scotth• 16 years ago

I asked this a few days ago. See replies.

http://news.ycombinator.com/item?id=1692675

wycats3• 16 years ago

What kind of use are you thinking about using SproutCore for?

catch233• 16 years 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.

city412• 16 years 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• 16 years 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• 16 years ago

What don't you like about that approach?

wycats3• 16 years 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• 16 years 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• 16 years 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• 16 years 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.

Isofarro7• 16 years 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-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• 16 years 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?

Isofarro7• 16 years 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.

mhd• 16 years ago

I've yet to see a site that depends on JavaScript heavily and degrades well. I think in this case you're much better of making secondary interface in pure HTML, cf. GMail. You could also make some small JQuery (etc.) enhancements to this bare-metal platform.

Having something that degrades from full whizbang to dumb terminal is really hard, kinda like getting a desktop application that is fully cross-platform. Sometimes it's better to just use a common backend for separate interfaces.

chc2• 16 years ago

Dav's experiment is interesting, but I don't see how these static pages come anywhere near touching "we do web applications not websites so we don't have to bother about non-javascript". A rich interface simply will not work with its interactivity taken away. Even something as simple as a selection rect fails under such a system. It would require a separate interface, and now we're back to where SproutCore gets us.

That is the dilemma of progressive enhancement. If you choose to do it, you must either limit your enhancements or support two separate interfaces.

Isofarro7• 16 years ago

"It would require a separate interface, and now we're back to where SproutCore gets us."

That's precisely the downside a JavaScript library or application development platform should be seeking to avoid: forcing developers to write two versions of their service - one with SproutCore and one without.

In a startup world, I'm surprised that someone on a tight budget can afford this approach and still have a viable minimum product at the end of it.

SproutCore 1.4 has been released

Related Stories