SproutCore (Web App Framework) 1.0 is Done | Hacker News Reader

SproutCore (Web App Framework) 1.0 is Done

blog.sproutcore.com

Kinda curious about how this stacks up to Cappucino (http://cappuccino.org/)

Has anyone tried both? I'm thinking about diving head-first into one of these, so I'd love any direction on which is better for a programming newbie.

I evaluated both pretty extensively and eventually decided to go with sproutcore.

Cappuccino is in many ways more revolutionary and the SC, as it completely throws out any notion of dealing with HTML and CSS. By completely abstracting the presentation some things become easier, but some things become impossible (for example: they cappuccino devs haven't implemented all of CGGraphics, and that makes some things that are trivial in CSS, like rounding the corners of an image, effectively impossible). With SC you're working with HTML and CSS, though most of the HTML is generated by JS. I found the latter approach more flexible, especially if you can target CSS3-supporting browsers.

Both are based on cocoa, though Cappuccino takes its influences much more seriously. I love cocoa but I'm not terribly enamored with Obj-C syntax, so I don't really see why someone would want to take JS's superior syntax and replace it with Obj-C's, as cappuccino has done. Cappuccino also lacks a data store framework, while SC has a very good one.

Finally, SC uses native browser rendering as much as possible, which should make SC apps faster.

That said, I think Cappuccino has a lot of potential, and 280Atlas, a visual editor for cappuccino apps written in itself shows that. As it matures and the basically non-existent docs improve I think it will become increasingly worthwhile.

For what it's worth, your CSS corners probably won't work in IE. One of the reasons some things are hard in Cappuccino is because they are unreliable in many browsers. We've focused more on cross platform ways of doing things. Of course there are some things we just haven't done yet too.

Anything that's possible with HTML/CSS is possible in Cappuccino. There's either a different way of doing it, or you can drop down to native code if you must. The latter is just generally not a great idea.

JavaScript is an OK language, but it's syntax is far from superior to Objective-C's. More importantly, syntax is irrelevant. What it lacks are features. Features like code importing, and dynamic message passing, and native classical inheritance. Those features (and more) are available at the language level in Objective-J.

Not sure what you mean by "native browser rendering".

The docs aren't great, for sure. But one of the advantages of using a proven set of APIs like Cocoa, rather than implement your own untested APIs, is that there's an incredible amount of quality resources out there that are almost completely applicable to Cappuccino. The APIs aren't "inspired by" Cocoa, they are the same, and so many of the books and tutorials are the same.

Sorry if I was unclear by my remark on rendering. What I was referring to was Cappuccino's habit of rendering a lot of stuff using canvas, which SC (at least natively; obviously developers can use whatever presentation layers they want) does not. SC also relies on the browser to do much of its work–from resizing to animation—without using any JS.

As for the relative merits of Obj-c and JS, I supposed that's a matter of taste. As mentioned above, SC does implement classical inheritance, but I actually find prototypical inheritance to be very powerful. In general I find my Obj-J (and -C, for that matter) code much more verbose than my JS. Perhaps that's my failure, but still it's something to keep in mind.

Cappuccino doesn't render anything in Canvas, with the possible exception of a couple minor pieces of the tableview.

FYI, SproutCore implements classical inheritance in Javascript.

Which is unfortunate on both accounts :-(

I wonder if different types of apps are suited to different frameworks. Is Cappuccino robust enough to recreate most desktop apps on the web?

Your css stylesheets on the linked page are returning 404's.

http://www.sproutcore.com/static/shared_assets/en/c7cb6bb82d...

http://www.sproutcore.com/static/sproutcore/standard_theme/e...

http://www.sproutcore.com/static/blog_template/en/2ff3e0eada...

I've been doing a lot of sproutcore development in last six months, and I can say it's a really powerful platform. The docs aren't great, but once you get you're head around it it's very productive.

For me, it feels like the biggest paradigm shift since Rails. Rails made it easy write dynamic ajax-based websites, but they were still websites. With SproutCore, you're truly writing web applications, which run entirely in the browser and only go to the server for data. This means desktop-level responsiveness.

Congratulations for the dev team on the release, and I look forward to the exciting stuff to come in 1.1!

> you're truly writing web applications, which run entirely in the browser and only go to the server for data

I see this as a huge step backwards towards client/server. The web is a win because it's made of addressable, reusable semantic resources in open formats. Instead web apps ship data around in undocumented and unstable formats which are only understood by one ephemeral piece of code that you have to trust. If this really catches on it will wreck the web, leaving us only with the same pile of siloed apps we had in 1990 (but without the native code).

Do you mean that reading in html (data with formatting mixed in) is preferable to reading JSON or XML? AJAX / AJAJ? What I am trying to say is I think eval(JSON) or parsing XML is > scraping HTML.

The lesson I took from the MS Office XML fiasco is that a poorly abstracted single-client data model remains impenetrable no matter how you serialize it. It's not impossible to commit to a documented and stable wire format behind a web app, but almost nobody has the diligence to actually do it when it's so much easier to make random changes and then tweak your own client code to handle whatever you did (instantly making your client the only one that still works). Before javascript happened, HTML wasn't that easy to scrape, but it at least had the virtue of forcing everyone to generate output that made some kind of sense without first being munged by one idiosyncratic piece of code.

Writing a proper SC or Capp app is easiest if you're working against a fleshed out set of APIs. Then the web app is just another data consumer, like an iPhone app. If anything I see this pushing more web sites to release solid JSON or XML based web services, not fewer.

SproutCore, for those who don't know, is an HTML5/JS application framework that works mostly on the client side. I've been playing around with it for the past week or so.

It can do some really cool things, and works a lot more like desktop GUI toolkits than most web app frameworks. (Both in terms of how it works, and in terms of how it performs.) I've been told it's much easier to learn if you know Cocoa, but I don't, so I can't comment on that.

This page: http://demo.sproutcore.com/sample_controls/

Just stays empty for me, and Firefox (3.6, on OSX 10.6.2) gives me:

Error: uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "http://demo.sproutcore.com/static/common_assets/en/efcc10e74... Line: 3150"]

Is this better than Google GWT?

Could one build something with the same graphics and responsiveness like Googles "Speed Tracer" plugin which is way cool?

http://code.google.com/webtoolkit/speedtracer/

It depends. There are a group of people who dislike Java so whatever the arguments are, they will not see SC or Cappuccino better than GWT.

GWT has typical Java attributes/properties: lots of tools and libraries, growing communities, a bit verbose, some setups, a bit heavy (not performance, but from a developer perspective).

The irritating thing with GWT it that it takes a long time to compile.

Is anybody else concerned about the buggy demos? http://demo.sproutcore.com/sample_controls/

On "Collections" moving the bottom right slider doesn't resize the cells. On "Containers", dragging the blue square is pretty buggy. There are others too. That kind of stuff would be a problem for me.

I eagerly await the time when those frameworks will be able to do what Adobe Flex can do. I'm itching to try my hand at rewriting our app in javascript, but so far they all seem too immature and generally broken (and cross-browser incompatible) to be worth considering.

At the moment, for an RIA that's going to be used by enterprises, Flex still appears to win hands down, unfortunately. I'd love to be proved wrong, though! However, based on the comments in this thread, it appears that Sproutcore is not there yet, by far.

I like the concept of Flex but I've tried to create some apps and the UI designing was a pain, plus you have to deal with the fact the most users don't have the flex runtime app.

However flex uses AS which bring a nice belt of libraries to play with.

I don't know how it's now, I played with it a year ago.

Getting dark text on a dark background on my phone. Can't read it.

Pretty sure they borked their site on the way out to celebrate.

---

I’m happy to announce that SproutCore 1.0.1046 is the official “1.0” release of SproutCore. We’ve had the gem out for nearly two months now without any show stopper issues forcing an update, so I’m pretty confident with it’s stability.

Thanks again to the many people who contributed code to SproutCore 1.0. You’ve built something you should be very proud of.

This project was in the works for 18 months. We rewrote 20,000 lines of code, added nearly 6,000 unit tests, and significantly improved the clarity and consistency of the API.

Most importantly, SproutCore 1.0 is a performance beast. It feels really good to be able to recommend SproutCore to people building complex app that will push the boundaries of the browser knowing that we have the goods to get them there.

If you’ve been holding off on SproutCore 1.0 until it was really really done - well it’s ready so come and get it!

Now What?

Ironically, most of the core SproutCore team has moved well along past the 1.0 candidate. A lot of work is already going into the next release with some really fantastic results. So must so that I will spend most of my talk at jsconf in April covering the new stuff instead of 1.0.

The good news is that 1.5 (or whatever it’s called) will be a much shorter release cycle - probably starting this summer. And this time a lot of the development is happening in the community so it is a lot easier for everyone to get involved.

I’ll save some of the big surprises for jsconf but suffice to say the next few versions of SproutCore will be major moves forward. 1.0 was about laying the ground work for some big things down the road. These next few releases we start to reap those rewards.

See you at jsconf.

Thank you!

Same. Regardless though, has anyone here spent a significant amount of time with sprout? I've played around a bit with it and Capp but I'm still undecided on which is the better investment.

Works great on Safari. Totally horked on Firefox.

It's worth noting their blog doesn't use Sproutcore ;)

Getting the same thing on Firefox 3.6 on a 20" widescreen desktop monitor.

It's working fine for me in FF3.6 on Windows, but not on Linux.

I'm on Linux.

Apple's Mobile Me service is built on this. It has its problems, but it's a pretty impressive web app. Amazing things can be done with this.

But the _fucking_ documentation!

I've 'dived in' to SproutCore a couple of times (spending about 2 days each time) and beyond the initial tutorials and a few random blog posts on third party sites there is almost no useful documentation. A lot of the info on the wiki is out of date or irrelevant to anyone but the developers. (I've been advised to visit the IRC channel numerous times, and it's great that it's there, but that's support not documentation.)

You pretty quickly end up reading the source code, and wasting time on trial & error approaches.

Look at the user guide for Code Igniter, a PHP framework, http://codeigniter.com/user_guide/ — SproutCore desperately needs one of these.

This is very broken on my (Android) phone. There's no way to scroll lists or resize containers and many of the popup panes don't work.

Supporting phones, tablets and mystery-gadget-of-tomorrow is verging on, if not already mandatory. The traditional monolithic desktop widgets don't adapt well to novel form factors. The flexibility of the web permits more usable interfaces than the desktop anyway.

There is a huge need for a layer that makes beautiful AJAX apps easy to build and helps with the device-independence issue. Recreating the desktop GUI on the web is not the solution. It may be that SC is not limited to this, but it certainly seems like the main purpose.

As I understand it, this is client side only. That means I have to duplicate some of the code on the server side, right? I'm thinking of stuff like input validation. And I have to say I have become a little wary of anything called framework.

How do SproutCore and Cappucino compare to Google Web Toolkit (as far as the client side)?

What do you want to compare?

This is awesome, hadn't heard about this before.

So it sends data to your server asynchronously in the background? So you write it in Ruby or something like that, and it compiles to js for you?

This could be huge.

Reply on news.ycombinator.com