5 ms·

Previous submission & discussion is at http://news.ycombinator.com/item?id=2075111 http://news.ycombinator.com/item?id=2075111 , but as it was about 500 days ag

Previous submission & discussion is at http://news.ycombinator.com/item?id=2075111 http://news.ycombinator.com/item?id=2075111 , but as it was about 500 days ago and many, many things have changes since then, I thought re-submitting this wiki (by changing 'https' to 'http') would be OK and hopefully illuminating to some. I'm particularly eager to learn how IcedCoffeeScript has changes since then. I'm starting a rather big CoffeeScript/Node.js project and I can't decide whether to go with IcedCoffeeScript (I love its simplicity), or go the 'async.js' way... If anyone has used both Iced and async, I'd be more than thankful if they could share their experience (I Would've asked this question on StackOverflow, but I'm sure it'll be closed within 5 minutes as not a real question or something like that).

olegp 14y ago
Have you considered using plain coffee-script with node-fibers instead? It might also be worth looking into Common Node (https://github.com/olegp/common-node https://github.com/olegp/common-node) that I'm working on which provides a higher level abstraction: https://gist.github.com/1447709 https://gist.github.com/1447709
- pooriaazimi 14y ago
  Thanks. I'll look into it. One thing I forgot to mention about async.js: It's downright disgusting when you try to use it with CoffeeScript, so even though it's a mature, well-architectured piece of framework, I don't like to use it with CoffeeScript...
  - dagw 14y ago
    As someone who was just about to add some async.js to a CoffeeScript/Node project, I'd be very interested to hear about what problems you've had before I go and potentially do something stupid.
    - pooriaazimi 14y ago
      It might be just me, but async.waterfall [ (callback) -> callback null, "one", "two" (arg1, arg2, callback) -> callback null, "three" (arg1, callback) -> callback null, "done" ] just doesn't make much sense to me. I just don't like the way it looks. (code snippet from https://groups.google.com/group/coffeescript/browse_thread/thread/dd2071f3b0d73861?hl=en&noredirect=true&pli=1 https://groups.google.com/group/coffeescript/browse_thread/t... )
      - lucian1900 14y ago
        Looks fine to me, but I do agree Iced can look even better.
Kjeldahl 14y ago
I've used CoffeeScript both for front-end projects and node.js backends, and node.js based command line scripts (similar to what is often done in perl). It works great, but for things like command line stuff which typically runs synchronously, the CPS/callback style of programming gets really messy really fast. Using await/defer (as supported by IcedCoffeeScript) synchronous programming can be done cleanly, if you make sure you write all your own functions in a callback style, and then consistently use await/defer when you want to call them synchronously. Trying to mix the metaphors creates a huge mess; your own functions may be synchronous, but every lib you will be using will be async. Better to keep all functions - including your own - async, and then consistently call them using await/defer when you want sync behaviour.
statictype 14y ago
I've been using iced for a small project I'm doing in node. It works remarkably well for me. However, I've come to realize that it's biggest win is in forcing a simple convention on you for async code that makes it easy and clear to write even when you don't use iced.

olegp 14y ago

Have you considered using plain coffee-script with node-fibers instead? It might also be worth looking into Common Node (https://github.com/olegp/common-node https://github.com/olegp/common-node) that I'm working on which provides a higher level abstraction: https://gist.github.com/1447709 https://gist.github.com/1447709

pooriaazimi 14y ago
Thanks. I'll look into it. One thing I forgot to mention about async.js: It's downright disgusting when you try to use it with CoffeeScript, so even though it's a mature, well-architectured piece of framework, I don't like to use it with CoffeeScript...
- dagw 14y ago
  As someone who was just about to add some async.js to a CoffeeScript/Node project, I'd be very interested to hear about what problems you've had before I go and potentially do something stupid.
  - pooriaazimi 14y ago
    It might be just me, but async.waterfall [ (callback) -> callback null, "one", "two" (arg1, arg2, callback) -> callback null, "three" (arg1, callback) -> callback null, "done" ] just doesn't make much sense to me. I just don't like the way it looks. (code snippet from https://groups.google.com/group/coffeescript/browse_thread/thread/dd2071f3b0d73861?hl=en&noredirect=true&pli=1 https://groups.google.com/group/coffeescript/browse_thread/t... )
    - lucian1900 14y ago
      Looks fine to me, but I do agree Iced can look even better.

Kjeldahl 14y ago

I've used CoffeeScript both for front-end projects and node.js backends, and node.js based command line scripts (similar to what is often done in perl). It works great, but for things like command line stuff which typically runs synchronously, the CPS/callback style of programming gets really messy really fast. Using await/defer (as supported by IcedCoffeeScript) synchronous programming can be done cleanly, if you make sure you write all your own functions in a callback style, and then consistently use await/defer when you want to call them synchronously. Trying to mix the metaphors creates a huge mess; your own functions may be synchronous, but every lib you will be using will be async. Better to keep all functions - including your own - async, and then consistently call them using await/defer when you want sync behaviour.

statictype 14y ago

I've been using iced for a small project I'm doing in node. It works remarkably well for me. However, I've come to realize that it's biggest win is in forcing a simple convention on you for async code that makes it easy and clear to write even when you don't use iced.