
SproutCore (Web App Framework) 1.0 is Done - aaronbrethorst
http://blog.sproutcore.com/post/459714079/sproutcore-1-0-is-done
======
rriepe
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.

~~~
necubi
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.

~~~
boucher
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.

~~~
necubi
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.

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

------
apsurd
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/shared_assets/en/c7cb6bb82dc338ffd9db5a4f48319560f9550038/stylesheet-
packed.css)

[http://www.sproutcore.com/static/sproutcore/standard_theme/e...](http://www.sproutcore.com/static/sproutcore/standard_theme/en/6beab73826ba9e40c6cb69fc8e248a0804ee9e03/stylesheet.css)

[http://www.sproutcore.com/static/blog_template/en/2ff3e0eada...](http://www.sproutcore.com/static/blog_template/en/2ff3e0eada826a4a26f5f71c9627c798e278003e/stylesheet.css)

------
necubi
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!

~~~
prodigal_erik
> 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).

~~~
timcash
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.

~~~
prodigal_erik
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.

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

------
slater
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...](http://demo.sproutcore.com/static/common_assets/en/efcc10e747291521495b10d9b48be9b9d3c489be/javascript-
packed.js) Line: 3150"]

------
abbetts
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/>

~~~
hello_moto
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).

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

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

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

~~~
phatbyte
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.

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

~~~
benologist
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.

~~~
pohl
Thank you!

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

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

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

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

~~~
hello_moto
What do you want to compare?

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

