10 ms·

Cappuccino - The Node.js Project

50 points by nikhildaga 14y ago

charliesome 14y ago
> The original build system used ant, which was then followed by rake, which ran on Ruby. In 2010 the build system was ported to JavaScript and jake (a port of rake), which ran on top of narwhal (a CommonJS runtime) and the package manager tusk. This is the system we are still using today. Sigh. No prizes for guessing what will happen in two years' time when node.js is no longer the shiny new hotness.
- legutierr 14y ago
  > 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.
  - charliesome 14y ago
    So I took a quick look at the Jakefile and it doesn't seem like it does a whole lot more than shelling out and a little bit of file manipulation. I wonder if Cappuccino has considered using make. make is maintained. make works on Windows. make is unglamorous but it works and it has worked for decades.
    - boucher 14y ago
      Being able to work in JavaScript code is valuable to our users (and to the project itself). Learning make would be a significant barrier for many of them.
    - halostatue 14y ago
      * Make introduces non-platform-related dependencies (e.g., you now need a make binary, not available by default on Windows, and not needed by anything else in the JavaScript development toolchain). * nmake, bsdmake, and gnumake are all slightly incompatible with each other if you want to do something smart.
    - tlrobinson 14y ago
      IIRC, one reason we wrote a build system in JavaScript was the compiler itself ran in Rhino, and the startup time of the JVM/Rhino was ridiculously slow when shelling out to it for each source file (hundreds of times in a full build of Cappuccino). Having the rest of the build system and compiler running in the same process eliminated that latency. And yes, we tried Nailgun (http://www.martiansoftware.com/nailgun/ http://www.martiansoftware.com/nailgun/) but I don't recall why that didn't work out. Perhaps there were better solutions, just pointing out it wasn't completely NIH syndrome.
  - SkyMarshal 14y ago
    >Honestly, I don't understand the unnecessary snarkiness of some people on this site. Reflexive negativity is a problem, pg is aware of it. Hiding comment karma score was one attempt at mitigating it, hopefully he's got some more ideas as well. Definitely one of those big problems, with the Internet in general, looking for a solution.
    - PommeDeTerre 14y ago
      I don't really see any "reflexive negativity" in the original comment. It's merely pointing out what seems to be a trend with this project and the build systems it uses. If there's any negativity involved, it's with how much time and effort (and donations...) the Cappuccino crew wastes with all of this repeated switching to the most-hyped software of the day.
      - legutierr 14y ago
        The original comment is certainly not charitable in its assumptions. Why must it be assumed that the Cappuccino team is just trying to be fashionable? What I see is a natural evolution from less appropriate alternatives to more appropriate alternatives as they gain maturity. npm is now the standard package manager for the language, something that jake might have tried to be but never was. And although node might be very fashionable and popular right now, I don't think anyone sees that role changing within the JavaScript ecosystem. If they hadn't switched people would be complaining that they use such an outdated system as jake.
        PommeDeTerre 14y ago
        If pragmatism was their main concern, then they would have been using make, shell scripts and the common UNIX commands from the very beginning. This would have given them support for Linux, Solaris, the *BSDs, Mac OS X and a number of other systems right away. Windows could've been supported with ease by using the various ports of those tools. Those tools are extremely capable and well-proven for creating reliable, cross-platform build scripts.
- hugh4life 14y ago
  "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.
  - kintamanimatt 14y ago
    There will be something, perhaps not even in the JS world, that will be the shiny new hotness. They seem to be fairly language agnostic when it comes to their build tools.
    - boucher 14y ago
      An evolution from not JS to JS for a JS library is not really language agnostic. I'm not sure you have an appropriate grasp of what the JS landscape looked like when we started Cappuccino.
      - kintamanimatt 14y ago
        I love your condescending tone. The project began with a Java-based system to a Ruby one to a JavaScript one. I appreciate things weren't as developed back in the day, but it appears the project uses what's best, regardless of the language. That, to me, is the epitome of being language agnostic and it's not a bad thing.
- visualR 14y ago
  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.
- aphexairlines 14y ago
  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.
  - pbiggar 14y ago
    Do you have the same control over JS library versions in NIX and you do in npm? I find it very unlikely...
    - aphexairlines 14y ago
      A nix package specification can depend on a specific version/build of another package (such as a JS library), with the version being as specific as the md5 hash of its contents.
- tolmasky 14y ago
  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.
kaolinite 14y ago
Anyone using Cappucino in production? Looks pretty awesome, although a bit slow I found, but not really heard of too many people using it.
- LinaLauneBaer 14y ago
  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/ 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. :/
  - javajosh 14y ago
    I'm on a fairly slow (but usually usable) connection, and your site never loaded for me. I waited for 2min and only saw a throbber. Not sure if this is a problem with Cappuccino or your site. (Chrome/OSX)
    - LinaLauneBaer 14y ago
      How slow is your connection? Cappuccino is a rather big framework and it needs more time to load on the first run than a web app which is not using Cappuccino. But as I mentioned: I haven't touched this little app for years so there may be something wrong with it.
- javajosh 14y ago
  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?)
  - 14y ago
pixelmonkey 14y ago
uhm, grunt? http://gruntjs.com/ http://gruntjs.com/ It's exactly a "brand-new build system — reimagined from the ground up — that leverages all of the power of node, npm and their thriving ecosystems". I use it on several projects and it works really well. It's probably my favorite build system across all languages for its simplicity, extensibility, and utility.
- cincinnatus 14y ago
  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.
- btipling 14y ago
  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.
  - davemo 14y ago
    Grunt supports executing tasks when files/directories change using the grunt-contrib-watch plugin. https://github.com/gruntjs/grunt-contrib-watch https://github.com/gruntjs/grunt-contrib-watch
    - daleharvey 14y ago
      That isnt what the post you are replying to is saying make etc will realise a build target doesnt need recompiled because nothing has changed, this lets you recompile fairly large projects where only a single file has changed reasonably quickly
    - btipling 14y ago
      Yes this is not the same thing. Grunt rebuilds everything for tasks, and does not selectively build only targets that have had dependencies change. Make doesn't require any kind of running process for this.
olegp 14y ago
You could run the existing Narwhal code on Node.js using Common Node: http://olegp.github.com/common-node/ http://olegp.github.com/common-node/ The library implements most CommonJS proposals on top of Node.js using node-fibers making it possible to run RingoJS and Narwhal code on Node as is. I'm using it in production on https://starthq.com/ https://starthq.com/.
- boucher 14y ago
  Thanks for the link, that may be interesting.
slig 14y ago
Does anyone knows what happened to their cool cappuccino dot org domain?
- ahankinson 14y ago
  $> 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.
  - SnowLprd 14y ago
    It's worth pointing out that requests for cappuccino.org are re-directed to cappuccino-project.org.
nirvana 14y ago
Whatever happened to Atlas? I thought cappuccino was dead. It seemed clear to me that it needed an Interface Builder equivalent, but Atlas was in perpetual beta and ignored for years, motorola bought them and the 280 north guys went to "hot" startups. I was really interested in Cappuccino for quite awhile, still would be if it could deliver a working system that was in reasonably good shape. (I'm not saying it can't, but it's apparently being abandoned years ago made me believe I shouldn't invest time into it.)
- boucher 14y ago
  Cappuccino is an open source project, and continues to thrive. You can see the public activity on Github: http://github.com/cappuccino/cappuccino 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.
- visualR 14y ago
  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.
  - jonpaul 14y ago
    I was really disappointed with 280 North and their lack of transparency regarding Atlas. I was a beta customer and they kept promising an update on the Motorola situation. Nothing but silence.
    - deleted 14y ago
      [deleted]
- saikat 14y ago

50 points by nikhildaga 14y ago

> The original build system used ant, which was then followed by rake, which ran on Ruby. In 2010 the build system was ported to JavaScript and jake (a port of rake), which ran on top of narwhal (a CommonJS runtime) and the package manager tusk. This is the system we are still using today. Sigh. No prizes for guessing what will happen in two years' time when node.js is no longer the shiny new hotness.

legutierr 14y ago
> 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.
- charliesome 14y ago
  So I took a quick look at the Jakefile and it doesn't seem like it does a whole lot more than shelling out and a little bit of file manipulation. I wonder if Cappuccino has considered using make. make is maintained. make works on Windows. make is unglamorous but it works and it has worked for decades.
  - boucher 14y ago
    Being able to work in JavaScript code is valuable to our users (and to the project itself). Learning make would be a significant barrier for many of them.
  - halostatue 14y ago
    * Make introduces non-platform-related dependencies (e.g., you now need a make binary, not available by default on Windows, and not needed by anything else in the JavaScript development toolchain). * nmake, bsdmake, and gnumake are all slightly incompatible with each other if you want to do something smart.
  - tlrobinson 14y ago
    IIRC, one reason we wrote a build system in JavaScript was the compiler itself ran in Rhino, and the startup time of the JVM/Rhino was ridiculously slow when shelling out to it for each source file (hundreds of times in a full build of Cappuccino). Having the rest of the build system and compiler running in the same process eliminated that latency. And yes, we tried Nailgun (http://www.martiansoftware.com/nailgun/ http://www.martiansoftware.com/nailgun/) but I don't recall why that didn't work out. Perhaps there were better solutions, just pointing out it wasn't completely NIH syndrome.
- SkyMarshal 14y ago
  >Honestly, I don't understand the unnecessary snarkiness of some people on this site. Reflexive negativity is a problem, pg is aware of it. Hiding comment karma score was one attempt at mitigating it, hopefully he's got some more ideas as well. Definitely one of those big problems, with the Internet in general, looking for a solution.
  - PommeDeTerre 14y ago
    I don't really see any "reflexive negativity" in the original comment. It's merely pointing out what seems to be a trend with this project and the build systems it uses. If there's any negativity involved, it's with how much time and effort (and donations...) the Cappuccino crew wastes with all of this repeated switching to the most-hyped software of the day.
    - legutierr 14y ago
      The original comment is certainly not charitable in its assumptions. Why must it be assumed that the Cappuccino team is just trying to be fashionable? What I see is a natural evolution from less appropriate alternatives to more appropriate alternatives as they gain maturity. npm is now the standard package manager for the language, something that jake might have tried to be but never was. And although node might be very fashionable and popular right now, I don't think anyone sees that role changing within the JavaScript ecosystem. If they hadn't switched people would be complaining that they use such an outdated system as jake.
      - PommeDeTerre 14y ago
        If pragmatism was their main concern, then they would have been using make, shell scripts and the common UNIX commands from the very beginning. This would have given them support for Linux, Solaris, the *BSDs, Mac OS X and a number of other systems right away. Windows could've been supported with ease by using the various ports of those tools. Those tools are extremely capable and well-proven for creating reliable, cross-platform build scripts.
hugh4life 14y ago
"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.
- kintamanimatt 14y ago
  There will be something, perhaps not even in the JS world, that will be the shiny new hotness. They seem to be fairly language agnostic when it comes to their build tools.
  - boucher 14y ago
    An evolution from not JS to JS for a JS library is not really language agnostic. I'm not sure you have an appropriate grasp of what the JS landscape looked like when we started Cappuccino.
    - kintamanimatt 14y ago
      I love your condescending tone. The project began with a Java-based system to a Ruby one to a JavaScript one. I appreciate things weren't as developed back in the day, but it appears the project uses what's best, regardless of the language. That, to me, is the epitome of being language agnostic and it's not a bad thing.
visualR 14y ago
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.
aphexairlines 14y ago
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.
- pbiggar 14y ago
  Do you have the same control over JS library versions in NIX and you do in npm? I find it very unlikely...
  - aphexairlines 14y ago
    A nix package specification can depend on a specific version/build of another package (such as a JS library), with the version being as specific as the md5 hash of its contents.
tolmasky 14y ago
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.

kaolinite 14y ago

Anyone using Cappucino in production? Looks pretty awesome, although a bit slow I found, but not really heard of too many people using it.

LinaLauneBaer 14y ago
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/ 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. :/
- javajosh 14y ago
  I'm on a fairly slow (but usually usable) connection, and your site never loaded for me. I waited for 2min and only saw a throbber. Not sure if this is a problem with Cappuccino or your site. (Chrome/OSX)
  - LinaLauneBaer 14y ago
    How slow is your connection? Cappuccino is a rather big framework and it needs more time to load on the first run than a web app which is not using Cappuccino. But as I mentioned: I haven't touched this little app for years so there may be something wrong with it.
javajosh 14y ago
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?)
- 14y ago

pixelmonkey 14y ago

uhm, grunt? http://gruntjs.com/ http://gruntjs.com/ It's exactly a "brand-new build system — reimagined from the ground up — that leverages all of the power of node, npm and their thriving ecosystems". I use it on several projects and it works really well. It's probably my favorite build system across all languages for its simplicity, extensibility, and utility.

cincinnatus 14y ago
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.
btipling 14y ago
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.
- davemo 14y ago
  Grunt supports executing tasks when files/directories change using the grunt-contrib-watch plugin. https://github.com/gruntjs/grunt-contrib-watch https://github.com/gruntjs/grunt-contrib-watch
  - daleharvey 14y ago
    That isnt what the post you are replying to is saying make etc will realise a build target doesnt need recompiled because nothing has changed, this lets you recompile fairly large projects where only a single file has changed reasonably quickly
  - btipling 14y ago
    Yes this is not the same thing. Grunt rebuilds everything for tasks, and does not selectively build only targets that have had dependencies change. Make doesn't require any kind of running process for this.

olegp 14y ago

You could run the existing Narwhal code on Node.js using Common Node: http://olegp.github.com/common-node/ http://olegp.github.com/common-node/ The library implements most CommonJS proposals on top of Node.js using node-fibers making it possible to run RingoJS and Narwhal code on Node as is. I'm using it in production on https://starthq.com/ https://starthq.com/.

boucher 14y ago
Thanks for the link, that may be interesting.

slig 14y ago

Does anyone knows what happened to their cool cappuccino dot org domain?

ahankinson 14y ago
$> 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.
- SnowLprd 14y ago
  It's worth pointing out that requests for cappuccino.org are re-directed to cappuccino-project.org.

nirvana 14y ago

Whatever happened to Atlas? I thought cappuccino was dead. It seemed clear to me that it needed an Interface Builder equivalent, but Atlas was in perpetual beta and ignored for years, motorola bought them and the 280 north guys went to "hot" startups. I was really interested in Cappuccino for quite awhile, still would be if it could deliver a working system that was in reasonably good shape. (I'm not saying it can't, but it's apparently being abandoned years ago made me believe I shouldn't invest time into it.)

boucher 14y ago
Cappuccino is an open source project, and continues to thrive. You can see the public activity on Github: http://github.com/cappuccino/cappuccino 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.
visualR 14y ago
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.
- jonpaul 14y ago
  I was really disappointed with 280 North and their lack of transparency regarding Atlas. I was a beta customer and they kept promising an update on the Motorola situation. Nothing but silence.
  - deleted 14y ago
    [deleted]
saikat 14y ago