4 ms·

That's really cool. I think node.js is one of the most exciting new projects out there, and getting support for it into the cloud means uptake can be that much

That's really cool. I think node.js is one of the most exciting new projects out there, and getting support for it into the cloud means uptake can be that much faster.

swannodette 16y ago
I'm excited about it. But I think the verdict's out on whether a medium to large Node.js program will not be a steaming spaghetti shaped pile of callbacks. Nothing I've seen coming from the Node.js community seems to address the fact that debugging/refactoring callback heavy code is hellish. Pretty please point me to literature/code that shows otherwise. For small nuggets of async goodness Node.js looks great.
- deleted 16y ago
  [deleted]
- tlrobinson 16y ago
  I suspect we'll see people building better abstractions on top of the raw callback APIs Node provides. "Promises" (similar to deferreds/futures), um, promise to help with this.
  - thegoleffect 16y ago
    I think Promises were removed recently.
    - tlrobinson 16y ago
      Correct, but they can still be implemented on top of the callback based APIs.
      - devinus 16y ago
        They already are: http://github.com/kriszyp/node-promise http://github.com/kriszyp/node-promise
        xal 16y ago
        promises need to be build into the language and all libraries have to be build with promises in mind for this to work. Look at io-lang's @ syntax or for a slightly different ( much better ) take, look at go's channels.
- deleted 16y ago
  [deleted]
- tr4nslator 16y ago
  Actually, a bunch of us are working on taking the pain out of async programming. Here's my approach, using (fab)'s chained continuations: http://www.flickr.com/photos/tr4nslator/4532445014/in/set-72157623883700702/ http://www.flickr.com/photos/tr4nslator/4532445014/in/set-72...
  - swannodette 16y ago
    While this is cool, when you get to this point with JavaScript syntax why not just write your program in a Lisp like Clojure? People keep saying that JavaScript is good for asynchronous code, but that might not true at all. It's just that we JS hackers become very accustomed to a style of code that works great for simple user-driven events. In my experience this does not scale for much else. Maybe we can make it work, but I don't like what I've seen thus far. I want people to adopt a syntax that doesn't affect standard JS style: http://mootools.net/shell/q9ASd/28/ http://mootools.net/shell/q9ASd/28/
    - tr4nslator 16y ago
      Because I'd rather write my programs in a Lisp like Javascript?
- felixge 16y ago
  Lessons learned from somebody who wrote a pretty large node app and is almost done with a rewrite: * Yes, async coding is hard. * Debugging can be tough, but good coding helps. * 95% of most node apps will be pure JS that does not perform any I/O. * Test driven development really shines in combination with node Make sure you keep that last point in mind when you build something with node. Reasoning about async code can be tricky, but TDD will force designs upon you that make it simple. --fg

That's really cool. I think node.js is one of the most exciting new projects out there, and getting support for it into the cloud means uptake can be that much faster.

swannodette 16y ago

I'm excited about it. But I think the verdict's out on whether a medium to large Node.js program will not be a steaming spaghetti shaped pile of callbacks. Nothing I've seen coming from the Node.js community seems to address the fact that debugging/refactoring callback heavy code is hellish. Pretty please point me to literature/code that shows otherwise. For small nuggets of async goodness Node.js looks great.

deleted 16y ago
[deleted]
tlrobinson 16y ago
I suspect we'll see people building better abstractions on top of the raw callback APIs Node provides. "Promises" (similar to deferreds/futures), um, promise to help with this.
- thegoleffect 16y ago
  I think Promises were removed recently.
  - tlrobinson 16y ago
    Correct, but they can still be implemented on top of the callback based APIs.
    - devinus 16y ago
      They already are: http://github.com/kriszyp/node-promise http://github.com/kriszyp/node-promise
      - xal 16y ago
        promises need to be build into the language and all libraries have to be build with promises in mind for this to work. Look at io-lang's @ syntax or for a slightly different ( much better ) take, look at go's channels.
deleted 16y ago
[deleted]
tr4nslator 16y ago
Actually, a bunch of us are working on taking the pain out of async programming. Here's my approach, using (fab)'s chained continuations: http://www.flickr.com/photos/tr4nslator/4532445014/in/set-72157623883700702/ http://www.flickr.com/photos/tr4nslator/4532445014/in/set-72...
- swannodette 16y ago
  While this is cool, when you get to this point with JavaScript syntax why not just write your program in a Lisp like Clojure? People keep saying that JavaScript is good for asynchronous code, but that might not true at all. It's just that we JS hackers become very accustomed to a style of code that works great for simple user-driven events. In my experience this does not scale for much else. Maybe we can make it work, but I don't like what I've seen thus far. I want people to adopt a syntax that doesn't affect standard JS style: http://mootools.net/shell/q9ASd/28/ http://mootools.net/shell/q9ASd/28/
  - tr4nslator 16y ago
    Because I'd rather write my programs in a Lisp like Javascript?
felixge 16y ago
Lessons learned from somebody who wrote a pretty large node app and is almost done with a rewrite: * Yes, async coding is hard. * Debugging can be tough, but good coding helps. * 95% of most node apps will be pure JS that does not perform any I/O. * Test driven development really shines in combination with node Make sure you keep that last point in mind when you build something with node. Reasoning about async code can be tricky, but TDD will force designs upon you that make it simple. --fg