Cappuccino - The Node.js Project (cappuccino-project.org)

> On the other hand, narwhal and tusk do not run on Windows and are no longer being maintained.

You can't blame them for not staying with narwhal. And I'm sure you are not suggesting that they should switch back to ant or rake.

Honestly, I don't understand the unnecessary snarkiness of some people on this site.

"No prizes for guessing what will happen in two years' time when node.js is no longer the shiny new hotness"

Do you honestly think there will be anything out in the JavaScript world that will replace node.js within the next 2 years?

Please think before you snark.

Ive gotten the Objective-J compiler and custom build system to run on Node.js. Node.js is much better than Narwhal, this is purely an engineering decision.

Anybody looking into a package management solution should just use nix and be done with it.

Works on Linux, Mac, Windows, BSD, probably others.

Language-agnostic (and build-system agnostic) so if your project ends up depending on bindings to a specific version of libjpeg or some other C library, you won't be stuck. Likewise if you have perl/ruby glue scripts in your project (which is bound to happen), their dependencies can be properly modeled too.

Just for some context, Ant was originally used just because that was what we were used to in college. Ant is a pretty miserable tool I feel now, and quickly discovered back then (very hard to do anything imperative and writing plugins for new features is no walk in the park either). We later went to rake because (some people forget this now), but you couldn't really use JavaScript on the terminal in any practical way (Rhino was the only real option) -- and had you been able to there certainly did not exist a build system. Rake made the most sense to me back then, and I still really like that build system. Once we had a way to realistically run JS on the terminal (at a decent speed by getting JSC working), we literally did a line by line port of Rake -- so none of the existing build system had to be rebuilt, it just got faster and was able to interact with all the existing libraries for free. The reality of today is that everyone has node.js, if they have any sort of JS environment installed, so that is their desire to move to node.js. Now, I would be of the position of just doing the bare minimum to get the existing build system working on node as opposed to some from-scratch rewrite, but that is their prerogative. Regardless, this was not just moving to what was "hot" at the time.

We are using it for the web version of our Mac and iOS app (store-news-app.com). The web version can be found here:

http://store-news-app.com/web/

Edit: We made this nearly 2 years ago without updating it. It has some flaws now which should be fixed. :/

This is a good question. It seems like Cappucino is targeted squarely at Cocoa developers looking to do web development without retooling, just as GWT is targeted toward Java Swing developers looking to do the same thing. This can't be a large target audience. (And I imagine that the few hard-core users would probably be willing (and able) to pay something for it.)

(Haven't we all sort of agreed that the best way to do UI is largely declarative, and then we wire things together with a selector based library? Why go through the pain of having to write code just to describe static UI resources?)

    Button b = new Button("Click me", new ClickHandler() {
      public void onClick(ClickEvent event) {
        //do something
      }
    });

    Button b = new Button("Click Me");
    b.addActionListener(new ActionListener(){
        void actionPerformed(ActionEvent e){
            //do something
        }
    });

Yes, we used it for http://www.akshell.com. Here's a blog post about the experience (in Russian but Google Translate should do a good job): http://habrahabr.ru/post/114749/.

I started translating it to English for http://dailyjs.com but never had the time to finish it. If this comment gets enough votes I'll do it ;)

We are. Our product is inventory management software for event rental companies. You can see video of the product in action at http://www.rwelephant.com/videos/

The same could probably be said about extjs, too, but you'd find lots of intranet apps written in it -- often replacing predecessors written with Swing or even Tcl/Tk. Another popular approach here seems to be GWT. None of this is exactly "sexy" and blog-worthy, but neither are the POS and CRM apps themselves...

And here I could see some inroads for Cappuccino, if it were targeted in that direction. Lots of companies are making their own business iOS applications, so having browser-based systems with a similar UX and API would be worth it. But to gain enterprise customers, you'd probably need more marketing in that direction and paid support.

Exactly. If there is anything lacking in grunt for what they want they should contribute changes back. A wheel re-invention plus big-bang "we'll not just replace, we'll make it totally awesome" is not a great move.

The problem with grunt is that it doesn't detect if files have changed, it therefore does not replace ant, make, scons or any of the other build tools that don't build things that don't need to be built.

Yeah, I was a little confused by what they were saying too. They really want to build something that is essentially the exact same thing a grunt? That just seems like the devs are bored with what they are working on and want to shave a yak for a while.

Nobody is suggesting building every facet of a new build tool. But Cappuccino has a pretty significant library of custom tools built on top of our existing (custom) build system that will need to be rebuilt and rethought on top of a node based system. That's what this project is about.

Thanks for the link, that may be interesting.

$> whois cappuccino.org

...

Registrant ID:mmr-117754

Registrant Name:Domain Administrator

Registrant Organization:Motorola Trademark Holdings, LLC

Registrant Street1:600 North US Highway 45

Registrant Street2:Attn: Law Department

...

When 280North sold to Motorola, they got the domain too.

When Motorola bought 280 North, they also got Atlas. For whatever reason Motorola never continued Atlas/made it public. Most Cappuccino developers instead use Interface Builder to layout the interface and the tool nib2cib to bring it into a Cappuccino project.

Cappuccino is an open source project, and continues to thrive. You can see the public activity on Github: http://github.com/cappuccino/cappuccino

As you are aware, Atlas is dead and has been for some time. But Cappuccino has always been valuable without it -- virtually everything ever built with Cappuccino was not built with Atlas. Instead, the community poured a lot of resources into improving compatibility with Xcode and Interface Builder, getting many (if not all) of the benefits Atlas would have brought to the table.

The interface builder equivalent these days for Cappuccino is interface builder. You can actually create your Cappuccino UIs in IB.