SproutCore: Introducing GreenHouse | Hacker News Reader

SproutCore: Introducing GreenHouse

blog.sproutcore.com

72 pointsjoegaudet20 comments

Why not ship a self-contained demo where all you have to do is double click it to try it out, like Atlas?

I have to admit I am having some trouble installing this and setting up a sample project.

"Some will even charge you for their beta releases."

I love the SproutCore versus Cappuccino battle. Two frameworks enter, one framework leaves.

Not really sure what that means. I don't think there has to be one winner, and we're glad to have more people in the market trying to realize our goal of desktop class web apps.

But let's not kid ourselves. Cappuccino has two interface builders, Atlas and nib2cib+IB. Both of these have been used to ship commercial software. nib2cib is completely free and open source, it's been out about as long as Cappuccino has, and it runs together with Interface Builder, the best in breed tool for designing interfaces for the last 20 years.

Greenhouse isn't even playing in the same game at this point.

I think he means that competition is good. It's been an exciting couple of years for JavaScript.

That and I wanted to make a Mad Max reference. Both these frameworks are doing exciting and interesting things that will help change the web.

I've already chosen which side of the fence I'm on, so with my bias in mind I'd like to say that I evaluated Cappuccino and nib2cib+IB before I settled with SproutCore. IB is the best of breed tool for creating interfaces, but the fact is nib2cib is nowhere near complete and many widgets failed to translate correctly or at all. I eventually gave up on it.

This is of course a function of when you tried it. Its been out for over a year now, and in that time we've built out support for a lot of the built in widgets, especially for our 0.8 release. Things like TableView work very well now (which last time I checked is a class that isn't even that well supported in SC at all). And again, the proof is ultimately in the pudding: most of the apps that are shipping today have used either nib2cib or Atlas, and we have very few users who don't begin development today straight from our nib2cib based projects.

Fair enough. I tried to keep my criticism firmly in the past tense too, because I wasn't sure how much love nib2cib has had since I evaluated it.

The choice between SproutCore and Cappuccino is largely philosophical (port something that works, or build fresh with new perspective), and based on limited data. The way I see it, either choice is still a choice for a client side web framework, and that's a step in the right direction. For instance, Narwhal/CommonJS/SeedJS came out of these efforts, and benefit all involved.

There's so much cool stuff coming out for building web apps. If you started your project more than a month ago, it seems to mean that you're using old, outdated stuff which is going to make you less productive.

I console myself by realising that the lack of extra abstractions makes my application faster and lighter.

Seriously though, how does one take advantage of new stuff without rewriting too much or ending up with an inconsistent and messy codebase?

I think you will have a tough time building something that is faster than SproutCore. Its built for speed and cloud computing. We are working with ~7 million object and getting it to work great.

^-Author of Greenhouse, why the downvotes? I think he knows what he's talking about.

The serious part of my comment was the last paragraph.

But it's certainly an interesting question: When should you adopt the latest and greatest for an existing project?

When you find the existing project cumbersome or find yourself severely hampered by your exiting tools.

In other words, when it makes sound business sense, I guess.

Seems half baked at the moment, but so did Atlas and nib2cib when they came out. I definitely prefer Sproutcore to Cappuccino and Objective-J. In my opinion Javascript is an excellent language for web development, where Objective-C (in Javascript form) is not. I really hope they pour a lot more work into this to make it great, as I'd really like to use it on an upcoming project!

Good work so far!

Seems like this is going to be the best way to build a certain class of polished apps w/o bothering with the app store. I was impressed that an app deployed this way can present custom launch images as well as present content in such way that the user cannot access the browser address bar.

With Mobile Safari support for HTML5 storage and HTML5 workers this is capable stuff.

MobileSafari doesn't support web workers.

yet ;)

For more Mobile Safari features, check out the docs:

Offline applications and local storage: http://developer.apple.com/safari/library/documentation/iPho...

HTML5 geolocation: http://developer.apple.com/safari/library/documentation/Appl...

Specifying icons and startup images while hiding chrome: http://developer.apple.com/safari/library/documentation/Appl...

I feel it is kinda sad that only nowadays we are seeing all the work that was done on Destkop ui Frameworks emerge on Client Javascript. I wonder how many MVC server-side frameworks (or hybrid ones like GWt) would have been invented if such tools existed 10 years ago...

Reply on news.ycombinator.com