10 ms·

Cappuccino Turns One

84 points by boucher 17y ago

ryanfitz 17y ago
I'm considering using cappuccino for a startup idea I have, but the lack of people using it and info out there on it makes me a bit gun shy. It makes me think I'll spend more time hacking away with capp rather than focusing on delivering a product quickly to see if people like it. For anyone else out there considering using it do check out http://cappuccinocasts.com http://cappuccinocasts.com
n8agrin 17y ago
I've spent a small amount of time working through the Cappuccino docs and tutorials, but never used it to build a project because it feels like it is so different from the typical JS I'm used to writing. That's not a criticism, just a description of the major hurdle I've encountered working with Cappuccino. Instead of having a smattering of tutorials and example apps, what would be really help would be a set of real world problems and solutions to those problems using Cappuccino (a list of N perhaps?). It would be especially compelling if it could be shown that those problems are more elegantly or simply solved by the use of Cappuccino.
- tolmasky 17y ago
  I'm not sure if this is more along the lines of what you mean, but this tutorial got written recently which explains specific problems/solutions in building an entire app: http://blog.springenwerk.com/search/label/Cappuccino http://blog.springenwerk.com/search/label/Cappuccino . Perhaps an explicit list of when you would and wouldn't want to use Cappuccino is a good idea though
natemartin 17y ago
Great work! I'm really looking forward to using cappuccino for my next project, I think it will be a perfect fit. In the blog post, you mentioned several backend solutions to work with cappucino. Which would you say is most mature, and which would you recommend? Using Objective-J on the backend would certainly be preferable, so that the developer can stay in one context the whole way. Also, many solutions are going to end up having a model layer in the UI and a model layer on the server that will need to stay in sync. Are you guys working on any solution to automate this?
- tlrobinson 17y ago
  Objective-J on the backend is still in it's infancy, so I'd recommend it if you enjoy being on the bleeding edge. We don't have any sort of Objective-J server-side framework, but you can use emerging JSGI-compatible JavaScript ones, like ActiveJS (Rails-like, http://activerecordjs.org/ http://activerecordjs.org/), NitroJS (http://www.nitrojs.org/ http://www.nitrojs.org/), Bogart (Sinatra-like http://github.com/nrstott/bogart/tree/master http://github.com/nrstott/bogart/tree/master) or just write raw JSGI application using Jack or custom middleware, which is actually perfectly adequate in many cases.
  - boucher 17y ago
    Worth noting that 280 Slides runs the entire app on the server as well as the client.
    - tlrobinson 17y ago
      Yes I should also note that Objective-J and Cappuccino run well on the server-side (using the Narwhal standard library: http://narwhaljs.org http://narwhaljs.org), I only meant that there's no Objective-J server-side web application framework (which you don't need in many cases).
    - cpr 17y ago
      Can you expand on what you mean by this? It could mean a lot of different things... Thanks.
      - tolmasky 17y ago
        Essentially, we run the same code on the server side as we do on the client side in order to unarchive the objects that get archived on the client, and then operate on them. For example, when you hit "export", the presentation is archived, sent over the wire, unarchived (using the same exact model code), then converted to PPT or whatever. You could also for example make an entire UI in code on the server, complete with connections to abstract objects, then send that entire object graph over the wire and show it on the client.
locnguyen 17y ago
First off, congrats to the team. Has anyone on HN used the framework extensively to give an opinion and compare experiences with other frameworks?
- joubert 17y ago
  I started using it to build our app's web UI. Really like it, but because of maturity switched over to Flex for the time being.
- tumult 17y ago
  I'm using it for my current project, currently ~6k semicolons. Stream of thought time! Forgive the sloppy writing, which will be full of interjections. Obj-J is more verbose than regular JavaScript. More use of objects and method selectors than callback functions. I usually prefer callbacks to delegate objects. It's easy to just make a catch-all object and use that with an anonymous function if you'd rather not specify a class for something that requires a delegate method, though it's not idiomatic Cappuccino/Cocoa. Cappuccino is almost identical to Cocoa. If you have experience with Cocoa you can just switch off the part of your brain that wonders how you should be doing something and just do it like you would have with Cocoa, and it'll just work, as they say. Not terribly exciting, but it works – and frighteningly well. I spent over a month working on my app, testing exclusively in WebKit and Firefox. Lots of what would be called advanced behavior "for a browser app" (but nothing that would be called advanced for a desktop app from 5 years ago) and making it work in IE required just a few tweaks, most of which were unrelated to Cappuccino (comet longpolling library I was using, Orbited.) Good stuff: Awesome, responsive, feels-right GUI stuff. Can't break objects by clicking and dragging around. No weird jumping around behavior. Stuff doesn't get dislodged, misaligned, etc. Don't have to work with the DOM. At all. This is a huge deal if you have a background in desktop GUI stuff – if all you've ever used is the DOM you have no idea what you're missing. It's pretty terrible for anything except vertically scrolling pages of text. Working with the DOM was like having someone beat on your shins with a baseball bat. "No I want the box to go there. There! THERE! ARGHOSOIJSD" Built-in serialization for Cappuccino classes. Canvas/vector abstractions. GUI building in Apple's Interface Builder. IE, WebKit, Opera, Firefox all work from the same code without apologies. Much more finessed event handling. Bad stuff: Awful debugging. Worse than regular JS debugging. Usually can't even easily tell what line a syntax error is on. Still has tons of stupid JS problems – implicit globals, type coercion everywhere (with JS primitives), slow as molasses. About a 10% performance hit on tight loops if you use Obj-J message sending in them. Mostly non-existent documentation. Still in rapid development, things change a lot. If you don't already know how to use Cocoa, expect to be totally lost. Other stuff: Has its own event loop. Allows for more flexibility than only DOM events, but it might cause problems if you use other JS code that uses events. Building Cappuccino in Linux had a few hiccups, but I got it working (they were related to Ruby 1.9.) Just Works in OS X without any tweaking necessary. Best reason to use it: Cocoa is not perfect by any measure, but we know it works for GUI apps. Cappuccino is like Cocoa; it works. A lot of effort has gone into Cappuccino. Behind the scenes, a lot is going on to maintain the transparent layer of browser compatibility that you get to work with. There are warts and issues, but you can absolutely build something with it right now and it will work.
jli 17y ago
what ever happened to atlas?
- boucher 17y ago
  Still in development.
  - jonathanespo 17y ago
    Still shooting for a summer release?
  - jf 17y ago
    I can vouch for this.
- felixmar 17y ago
  Atlas got tired of his job. He was replaced by a bunch of turtles.
- deleted 17y ago
  [deleted]
- al3x 17y ago
  shrug
cmpeters 17y ago
I saw this a long time ago and thought, "cool, but what about scalability, performance, etc..." But now there is back-end support. I'd like to see how this performs with the Lift framework. Cool project.
cpr 17y ago
I've been watching the Capp project with great interest since its debut, and hoping against hope that it turns into a serious alternative to the mess that's out there today for web dev. Now I'm worried that the combination of the Atlas delay and lack of serious Capp-based public websites is going to hurt its initial momentum.
- tolmasky 17y ago
  We'll be announcing some Atlas news soon, we try not to post about it on cappuccino.org since it is a separate commercial product.
  - xal 17y ago
    That's missplaced idealism. You should very much use the soapboxes you created to tell people about news. This is "industry" news for people who are interested in capp. I go to capp.org regularly and see no changes and assume that progress has stalled.
Keyframe 17y ago
First time I see that - is there any particular reason why would one use that for applications instead of, for example, GWT? edit: I am watching screencasts now from http://cappuccinocasts.com http://cappuccinocasts.com (I'm not Ruby guy though - PHP, but doesn't matter) - and I am wondering how the hell are you 1) how to debug/profile this? What, a hunch or traces and alerts? 2) .j files are in plain sight to anyone, not obfuscated 3) Why .j at all in production, why not compile down to javascript? 4) It seems nice from a perspective of a desktop guys viewpoint (here is one!) 5) holy spaghetti code
- nestlequ1k 17y ago
  GWT is a java library. To me it seems sick and crazy to code java that generates javascript. It's like using assembler to generate C code.
  - Keyframe 17y ago
    Have you actually tried to write anything with GWT and/or used Java and it's wonderful tools? And how does it make more sense to basically have a pseudo-VM running on top of JS than to spurt out heavily optimized JS code like GWT does? I'm really interested in answers to both questions.
    - tumult 17y ago
      Obj-J isn't a VM, it preprocesses and has some runtime functions.
    - ryanfitz 17y ago
      I work in gwt everyday and there are lots of pluses to it such as the easy communication between the client and server and taking away a lot of the dom headaches. However, I have several issues with it. Compile time from java to javascript is very slow, simple app takes a few minutes to compile. You typically will work in a hosted mode browser so changes are on the fly, in many scenarios things work in the hosted mode browser, but fail inside a normal browser, regex and bigdecimal use are two such pain points. A big issue that I have with it is that developers end up putting way too much business logic inside the gwt portion of an app, simply because its just java anyway, right? You can't really blame gwt for bad programming, however, because of the notion of its just java it easily allows developers to not think and just put business logic in the ui. If this was javascript developers would much rather do the more complicated business-y things on the server side (typically where it should belong), rather than in javascript because most people really dislike working in JS. I personally feel that its very difficult to build a gwt app while maintaining a clean well refactored codebase and doing TDD is also very difficult with the framework. I say difficult and not impossible, because I have done it in the past, but its not easy and really takes time and care. Again because its not easy to do these things developers tend to not do them, thus leading to messy, hard to change apps.
papersmith 17y ago
Has anyone who also used SproutCore have any thoughts on how they stack up? SproutCore also stabilized into 1.0 recently it seems.
- boucher 17y ago
  Worth noting we aren't calling ourselves 1.0 yet. This is just our one year anniversary. Also worth noting that SproutCore 1.0 is still in beta, and almost a complete rewrite, rather than a stabilization of what was already there.
- sandofsky 17y ago
  I developed a few toy projects to learn each framework. Cappuccino is an incredible technical accomplishment. I've done iPhone development, and it's true that you can easily map your Cocoa experience onto Cappuccino. However, when I hit a corner case such as embedding a SWF, the abstraction leak was a nightmare. Sproutcore feels safer because it doesn't hide the fact you're working with HTML/CSS; you need to write it to create custom views. Inserting a SWF was straightforward. The other reason I favor Sproutcore is the feeling Cappuccino has cargo cult issues. For example, Sproutcore uses namespaces while Cappuccino just prefixes initials. In Sproutcore you have "SC.Object" while Cappuccino uses "CPObject." Cappuccino is still pre 1.0, so all of this could change, but if I had to choose a framework to write an app today, I'd go with Sproutcore.
  - boucher 17y ago
    I'm not sure what "cargo cult issues" are, but Cappuccino uses prefixed globals because they are strictly faster than using "namespaces" (which really aren't namespaces). It makes a big difference in IE.
- catch23 17y ago
  unless things have changed recently, SC's 1.0 beta is anything but stable. It's great for hobby projects, but I would worry if attempting to use it for production. I guess if you're starting a new project now, SC isn't a bad route. Will probably be stable soon.
richcollins 17y ago
Congrats on making it through the first year. Looking forward to Atlas!

84 points by boucher 17y ago

I'm considering using cappuccino for a startup idea I have, but the lack of people using it and info out there on it makes me a bit gun shy. It makes me think I'll spend more time hacking away with capp rather than focusing on delivering a product quickly to see if people like it. For anyone else out there considering using it do check out http://cappuccinocasts.com http://cappuccinocasts.com

n8agrin 17y ago

I've spent a small amount of time working through the Cappuccino docs and tutorials, but never used it to build a project because it feels like it is so different from the typical JS I'm used to writing. That's not a criticism, just a description of the major hurdle I've encountered working with Cappuccino. Instead of having a smattering of tutorials and example apps, what would be really help would be a set of real world problems and solutions to those problems using Cappuccino (a list of N perhaps?). It would be especially compelling if it could be shown that those problems are more elegantly or simply solved by the use of Cappuccino.

tolmasky 17y ago
I'm not sure if this is more along the lines of what you mean, but this tutorial got written recently which explains specific problems/solutions in building an entire app: http://blog.springenwerk.com/search/label/Cappuccino http://blog.springenwerk.com/search/label/Cappuccino . Perhaps an explicit list of when you would and wouldn't want to use Cappuccino is a good idea though

natemartin 17y ago

Great work! I'm really looking forward to using cappuccino for my next project, I think it will be a perfect fit. In the blog post, you mentioned several backend solutions to work with cappucino. Which would you say is most mature, and which would you recommend? Using Objective-J on the backend would certainly be preferable, so that the developer can stay in one context the whole way. Also, many solutions are going to end up having a model layer in the UI and a model layer on the server that will need to stay in sync. Are you guys working on any solution to automate this?

tlrobinson 17y ago
Objective-J on the backend is still in it's infancy, so I'd recommend it if you enjoy being on the bleeding edge. We don't have any sort of Objective-J server-side framework, but you can use emerging JSGI-compatible JavaScript ones, like ActiveJS (Rails-like, http://activerecordjs.org/ http://activerecordjs.org/), NitroJS (http://www.nitrojs.org/ http://www.nitrojs.org/), Bogart (Sinatra-like http://github.com/nrstott/bogart/tree/master http://github.com/nrstott/bogart/tree/master) or just write raw JSGI application using Jack or custom middleware, which is actually perfectly adequate in many cases.
- boucher 17y ago
  Worth noting that 280 Slides runs the entire app on the server as well as the client.
  - tlrobinson 17y ago
    Yes I should also note that Objective-J and Cappuccino run well on the server-side (using the Narwhal standard library: http://narwhaljs.org http://narwhaljs.org), I only meant that there's no Objective-J server-side web application framework (which you don't need in many cases).
  - cpr 17y ago
    Can you expand on what you mean by this? It could mean a lot of different things... Thanks.
    - tolmasky 17y ago
      Essentially, we run the same code on the server side as we do on the client side in order to unarchive the objects that get archived on the client, and then operate on them. For example, when you hit "export", the presentation is archived, sent over the wire, unarchived (using the same exact model code), then converted to PPT or whatever. You could also for example make an entire UI in code on the server, complete with connections to abstract objects, then send that entire object graph over the wire and show it on the client.

locnguyen 17y ago

First off, congrats to the team. Has anyone on HN used the framework extensively to give an opinion and compare experiences with other frameworks?

joubert 17y ago
I started using it to build our app's web UI. Really like it, but because of maturity switched over to Flex for the time being.
tumult 17y ago
I'm using it for my current project, currently ~6k semicolons. Stream of thought time! Forgive the sloppy writing, which will be full of interjections. Obj-J is more verbose than regular JavaScript. More use of objects and method selectors than callback functions. I usually prefer callbacks to delegate objects. It's easy to just make a catch-all object and use that with an anonymous function if you'd rather not specify a class for something that requires a delegate method, though it's not idiomatic Cappuccino/Cocoa. Cappuccino is almost identical to Cocoa. If you have experience with Cocoa you can just switch off the part of your brain that wonders how you should be doing something and just do it like you would have with Cocoa, and it'll just work, as they say. Not terribly exciting, but it works – and frighteningly well. I spent over a month working on my app, testing exclusively in WebKit and Firefox. Lots of what would be called advanced behavior "for a browser app" (but nothing that would be called advanced for a desktop app from 5 years ago) and making it work in IE required just a few tweaks, most of which were unrelated to Cappuccino (comet longpolling library I was using, Orbited.) Good stuff: Awesome, responsive, feels-right GUI stuff. Can't break objects by clicking and dragging around. No weird jumping around behavior. Stuff doesn't get dislodged, misaligned, etc. Don't have to work with the DOM. At all. This is a huge deal if you have a background in desktop GUI stuff – if all you've ever used is the DOM you have no idea what you're missing. It's pretty terrible for anything except vertically scrolling pages of text. Working with the DOM was like having someone beat on your shins with a baseball bat. "No I want the box to go there. There! THERE! ARGHOSOIJSD" Built-in serialization for Cappuccino classes. Canvas/vector abstractions. GUI building in Apple's Interface Builder. IE, WebKit, Opera, Firefox all work from the same code without apologies. Much more finessed event handling. Bad stuff: Awful debugging. Worse than regular JS debugging. Usually can't even easily tell what line a syntax error is on. Still has tons of stupid JS problems – implicit globals, type coercion everywhere (with JS primitives), slow as molasses. About a 10% performance hit on tight loops if you use Obj-J message sending in them. Mostly non-existent documentation. Still in rapid development, things change a lot. If you don't already know how to use Cocoa, expect to be totally lost. Other stuff: Has its own event loop. Allows for more flexibility than only DOM events, but it might cause problems if you use other JS code that uses events. Building Cappuccino in Linux had a few hiccups, but I got it working (they were related to Ruby 1.9.) Just Works in OS X without any tweaking necessary. Best reason to use it: Cocoa is not perfect by any measure, but we know it works for GUI apps. Cappuccino is like Cocoa; it works. A lot of effort has gone into Cappuccino. Behind the scenes, a lot is going on to maintain the transparent layer of browser compatibility that you get to work with. There are warts and issues, but you can absolutely build something with it right now and it will work.

jli 17y ago

what ever happened to atlas?

boucher 17y ago
Still in development.
- jonathanespo 17y ago
  Still shooting for a summer release?
- jf 17y ago
  I can vouch for this.
felixmar 17y ago
Atlas got tired of his job. He was replaced by a bunch of turtles.
deleted 17y ago
[deleted]
al3x 17y ago
shrug

cmpeters 17y ago

I saw this a long time ago and thought, "cool, but what about scalability, performance, etc..." But now there is back-end support. I'd like to see how this performs with the Lift framework. Cool project.

cpr 17y ago

I've been watching the Capp project with great interest since its debut, and hoping against hope that it turns into a serious alternative to the mess that's out there today for web dev. Now I'm worried that the combination of the Atlas delay and lack of serious Capp-based public websites is going to hurt its initial momentum.

tolmasky 17y ago
We'll be announcing some Atlas news soon, we try not to post about it on cappuccino.org since it is a separate commercial product.
- xal 17y ago
  That's missplaced idealism. You should very much use the soapboxes you created to tell people about news. This is "industry" news for people who are interested in capp. I go to capp.org regularly and see no changes and assume that progress has stalled.

Keyframe 17y ago

First time I see that - is there any particular reason why would one use that for applications instead of, for example, GWT? edit: I am watching screencasts now from http://cappuccinocasts.com http://cappuccinocasts.com (I'm not Ruby guy though - PHP, but doesn't matter) - and I am wondering how the hell are you 1) how to debug/profile this? What, a hunch or traces and alerts? 2) .j files are in plain sight to anyone, not obfuscated 3) Why .j at all in production, why not compile down to javascript? 4) It seems nice from a perspective of a desktop guys viewpoint (here is one!) 5) holy spaghetti code

nestlequ1k 17y ago
GWT is a java library. To me it seems sick and crazy to code java that generates javascript. It's like using assembler to generate C code.
- Keyframe 17y ago
  Have you actually tried to write anything with GWT and/or used Java and it's wonderful tools? And how does it make more sense to basically have a pseudo-VM running on top of JS than to spurt out heavily optimized JS code like GWT does? I'm really interested in answers to both questions.
  - tumult 17y ago
    Obj-J isn't a VM, it preprocesses and has some runtime functions.
  - ryanfitz 17y ago
    I work in gwt everyday and there are lots of pluses to it such as the easy communication between the client and server and taking away a lot of the dom headaches. However, I have several issues with it. Compile time from java to javascript is very slow, simple app takes a few minutes to compile. You typically will work in a hosted mode browser so changes are on the fly, in many scenarios things work in the hosted mode browser, but fail inside a normal browser, regex and bigdecimal use are two such pain points. A big issue that I have with it is that developers end up putting way too much business logic inside the gwt portion of an app, simply because its just java anyway, right? You can't really blame gwt for bad programming, however, because of the notion of its just java it easily allows developers to not think and just put business logic in the ui. If this was javascript developers would much rather do the more complicated business-y things on the server side (typically where it should belong), rather than in javascript because most people really dislike working in JS. I personally feel that its very difficult to build a gwt app while maintaining a clean well refactored codebase and doing TDD is also very difficult with the framework. I say difficult and not impossible, because I have done it in the past, but its not easy and really takes time and care. Again because its not easy to do these things developers tend to not do them, thus leading to messy, hard to change apps.

papersmith 17y ago

Has anyone who also used SproutCore have any thoughts on how they stack up? SproutCore also stabilized into 1.0 recently it seems.

boucher 17y ago
Worth noting we aren't calling ourselves 1.0 yet. This is just our one year anniversary. Also worth noting that SproutCore 1.0 is still in beta, and almost a complete rewrite, rather than a stabilization of what was already there.
sandofsky 17y ago
I developed a few toy projects to learn each framework. Cappuccino is an incredible technical accomplishment. I've done iPhone development, and it's true that you can easily map your Cocoa experience onto Cappuccino. However, when I hit a corner case such as embedding a SWF, the abstraction leak was a nightmare. Sproutcore feels safer because it doesn't hide the fact you're working with HTML/CSS; you need to write it to create custom views. Inserting a SWF was straightforward. The other reason I favor Sproutcore is the feeling Cappuccino has cargo cult issues. For example, Sproutcore uses namespaces while Cappuccino just prefixes initials. In Sproutcore you have "SC.Object" while Cappuccino uses "CPObject." Cappuccino is still pre 1.0, so all of this could change, but if I had to choose a framework to write an app today, I'd go with Sproutcore.
- boucher 17y ago
  I'm not sure what "cargo cult issues" are, but Cappuccino uses prefixed globals because they are strictly faster than using "namespaces" (which really aren't namespaces). It makes a big difference in IE.
catch23 17y ago
unless things have changed recently, SC's 1.0 beta is anything but stable. It's great for hobby projects, but I would worry if attempting to use it for production. I guess if you're starting a new project now, SC isn't a bad route. Will probably be stable soon.

richcollins 17y ago

Congrats on making it through the first year. Looking forward to Atlas!