

Cappuccino developer conference - klaaspieter
http://cappcon.org/

======
erikpukinskis
Does anyone know the motivation for using Objective-J instead of vanilla
JavaScript? Maybe it just makes things more comfortable for iOS developers who
want to move to the web?

That's the major thing that would stop me from using Cappucino over
SproutCore... I don't mind learning a new language if there's a compelling
need for it, but I just don't see the point here. I'd love to be proved wrong
though.

~~~
tolmasky
This is probably the best explanation available online
[http://cappuccino.org/discuss/2008/12/08/on-leaky-
abstractio...](http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractions-
and-objective-j/)

Also, objj is an extension to js, so "learning" it is not some monumental
task, kind of like learning the latest additions made by ecmascript 5.

~~~
erikpukinskis
Thanks! I was just coming across that as you replied. It clears up a lot. The
"syntax is not harder to learn than API" argument is compelling... although
the "syntax is aesthetically better than API for certain features" argument
doesn't really move me. Glibc and CLOS work quite well.

I think there's a tension right now in the web platform community about
whether we're in the post-HTML+js world yet. Cappuccino, GWT, jqueryui, etc
are all moving in that direction. But there's a tension between libraries that
want to treat HTML+js like dumb rendering layer, and libraries that keep
HTML+js as the developer-level workspace, and just extend it by adding API.

There are a lot of things that work really well in HTML+js (links, urls,
scrolling, etc) that get screwed up as you add more post-HTML widgetry. So the
developers of post-HTML tools eventually end up rewriting _everything_ HTML
did in their new toolkit. The toolkits get better and better, but I have yet
to see one that didn't break _something_ that HTML did well.

So it becomes an either/or proposition. Either I jump fully into Cappuccino,
accept that it will break things about HTML and I will not be able to fix
them, or I stay in the land of HTML, and I try to implement the cool stuff
Cappuccino does (windowing, OO, advanced widgetry, etc) with HTML+js and
whatever JS libraries I can find, but generally sick with The HTML Way
wherever possible.

The thing is, I know what HTML sucks at. I have no way to know what Cappuccino
breaks that HTML does well until I am waist-deep in a Cappuccino app. I think
that makes it hard for me to jump.

And so my preference (although it's just a preference) is for small tools that
add one thing to HTML+js, but they do it really well. So if I want to make a
mobile app for iPhones, I want to start with a JS library that lets me make
touch-slideable panes, that's incredibly fast and smooth, and that's it. I
don't need it to create a whole complex windowing model, or re-implement HTML
buttons in javascript, or anything like that.

But I feel like the tide is slowly turning... the post-HTML frameworks are
getting better. At some point one will be good enough that I really can leave
HTML behind. Maybe I'll try out Cappucino for my next weekend project and see
how it goes.

~~~
tolmasky
Its important to note that you are describing two things here: Objective-J (a
language extension to JavaScript) and Cappuccino (a framework built on top of
Objective-J).

Objective-J is just a language that adds what we consider to be a lot of nice
things to JS. You can use it and still keep HTML/CSS/etc (much like you would
use CoffeeScript). Similarly, you can use it to, say, write command line apps
for the terminal and never touch any web technology at all.

Separately, there is Cappuccino. I do not personally believe the situation to
be either or (or not necessarily anyways). I think HTML and CSS are very
powerful tools, given the right task (presenting documents). However, if I
wanted to write super mario brothers, I would not miss lists and links, but
would want strong graphical abilities. HTML has basically conceded this by
adding the canvas element (which if you think about it goes against everything
HTML is about -- semantic meaning). In the end, you should use the best tool
for the task. For example, our GitHub issues app builds its chrome using
Cappuccino, and displays the actual bug report as an HTMLView. No re-
implementation of all of HTML, just literally loading HTML when we want it
(Similar to how Mail's chrome is Cocoa, and the actual mail message rendering
is an HTML WebView).

And, as you say at the end, of course it is only a matter of time until
everything is "post HTML/JS". The fate of every language or framework is to
either die or to be built on top of and abstracted away, there is no "last
technology".

------
MatthewPhillips
I'm not a cappuccino user, but I'm glad to see that a client-side web
framework has become adopted enough to warrant a conference. Hopefully we'll
start to see a lot more of these pop up.

~~~
elefont2
GWT has a fair number of sessions at google i/o as well - so not a dedicated
conference, but a dedicated track at a conference.

------
r00k
Lanyrd link for those interested: <http://lanyrd.com/2011/cappcon/>

------
brian_c
I honestly had no idea Cappuccino was still even a thing since Motorola bought
280 North. Didn't they kill development?

~~~
Me1000
We just put out a new major release about a month ago. We're very much alive.
:)

