9 responses to “Cappuccino: Taking the “Web” Out of Web Development”

  1. Speckyboy

    I wish they had advertised it as an alternative rather than a replacement framework.
    The idea is good, the app perhaps isn’t.
    Great article. Dugg it.

  2. Ben Sargent

    Another fun exercise is firing up a Cappuccino app and exploring the generated DOM with a tool such as FireBug. Aside from the slowness introduced by Objective-J, the sheer volume of nested divs and inline styles used to abstract away the browser creates overhead as well.

    V8, Tracemonkey, etc have introduced great improvements in JavaScript execution speed, but it appears DOM manipulation is still a bottleneck. (see http://ejohn.org/blog/javascript-performance-rundown/)

  3. untouchable

    Man, we can see you’re a windows fanboy that never has seen how productive a cocoa developer can be and how much he can accomplish.

    If you’re a real OO programmer you can get Obj-J in a matter of hours, and be proficient in a framework like Cappuccino after a little while. After that point the sky is the limit in terms of desktop class apps in the cloud.

    I profoundly doubt that anyone can achieve the high level of productivity with any framework as we can with an Cocoa inspired environment.

    All hands down to 280N guys in bringing that to the web!

  4. Buck Wilson

    Untouchable –

    Nicely done in getting the author’s credentials completely wrong. He’s a Mac user and was well on his way to a CS doctorate specializing in OO studies before pursuing his own business endeavors.

    Anyway, Adam has provided the pros and cons of each method, so I can’t possibly fathom how you’re able to argue anything he’s said.

    Cappuccino abstracts the developer too far away from HTML / CSS / JS for my tastes, but that doesn’t mean someone else can’t be productive with it. Just expect quite a bit of frustration if you can’t get the enormous markup it provides to work exactly how you want it to.

  5. theMusicMan

    In terms of performance are you only concerned with the initial loading of the application? Sure the jQuery version loads a lot quicker, but I did not see a performance issue once the Cappuccino app was loaded.

    Also notice when you resize the images and then change photo lists in the jQuery app the slider retains is position, but the size of the photos in the new photo list do not reflect the slider value. Try the same thing in the Cappuccino version.

  6. Dave Parizek

    Also there is a lot that can and will be done to speed Cappuccino up. Like spriting images to get less file loads. You can compile it if you wish.

  7. Land Rover Lover

    The performance comparison is off-base. Cappuccino is not simply zooming the photo in and out:

    “- The Cappuccino example works just like iPhoto, when you drag the slider, it does not just resize the images by increasing relative height and width like your jQuery script does, it zooms the images in keeping them centered (both vertically and horizontally) in their own “cell” and each row of cells in its column, until the bounds of the image (and cell) are bigger than the column’s width, therefore moving the image to a new column so it fits. I think that’s a more complex calculation and so takes more time to be processed by the JS engine”

    quote from comment by Fernando Lins on another blog

  8. Grb

    I should highlight that the JQuery re-implementation DOESN’T re-implement properly the behavior of the cappuccino app.

    First, I was like “uh, it doesn’t feel as neat at the cappuccino app”, then I noticed how resizing and pictures disposition was handled with JQuery (look closely).

    Cappuccino behave like iPhoto, which might consume more resources and explain some speed difference.

Leave a Reply

Google Author link