4 ms·

Cappuccino developer conference

66 points by klaaspieter 16y ago

fdhjkyului 16y ago
ONLINE STORE— http://www.fullmalls.com http://www.fullmalls.com Christan Audigier bikini $23 Ed Hardy Bikini $23 Smful short_t-shirt_woman $15 ed hardy short_tank_woman $16 Sandal $32 christian louboutin $80 Sunglass $15 COACH_Necklace $27 handbag $33 AF tank woman $17 puma slipper woman $30 http://www.fullmalls.com http://www.fullmalls.com
brian_c 16y ago
I honestly had no idea Cappuccino was still even a thing since Motorola bought 280 North. Didn't they kill development?
- Slevenbits 16y ago
  Quite alive indeed: https://github.com/280north/cappuccino/commits/master https://github.com/280north/cappuccino/commits/master Cappuccino the framework is open source.
- Me1000 16y ago
  We just put out a new major release about a month ago. We're very much alive. :)
MatthewPhillips 16y ago
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 16y ago
  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.
erikpukinskis 16y ago
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 16y ago
  This is probably the best explanation available online http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractions-and-objective-j/ http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractio... 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 16y ago
    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.
r00k 16y ago
Lanyrd link for those interested: http://lanyrd.com/2011/cappcon/ http://lanyrd.com/2011/cappcon/

66 points by klaaspieter 16y ago

ONLINE STORE— http://www.fullmalls.com http://www.fullmalls.com Christan Audigier bikini $23 Ed Hardy Bikini $23 Smful short_t-shirt_woman $15 ed hardy short_tank_woman $16 Sandal $32 christian louboutin $80 Sunglass $15 COACH_Necklace $27 handbag $33 AF tank woman $17 puma slipper woman $30 http://www.fullmalls.com http://www.fullmalls.com

brian_c 16y ago

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

Slevenbits 16y ago
Quite alive indeed: https://github.com/280north/cappuccino/commits/master https://github.com/280north/cappuccino/commits/master Cappuccino the framework is open source.
Me1000 16y ago
We just put out a new major release about a month ago. We're very much alive. :)

MatthewPhillips 16y ago

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 16y ago
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.

erikpukinskis 16y ago

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 16y ago
This is probably the best explanation available online http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractions-and-objective-j/ http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractio... 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 16y ago
  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.

r00k 16y ago

Lanyrd link for those interested: http://lanyrd.com/2011/cappcon/ http://lanyrd.com/2011/cappcon/