3 ms·

Huh? how does any of this keep me from having to write callback spaghetti? If I send a call using redis or dnode or whatever, I have to wait for it, so that mea

Huh? how does any of this keep me from having to write callback spaghetti? If I send a call using redis or dnode or whatever, I have to wait for it, so that means a callback. I feel you about the polyglot and tend to agree, but I think some people are really trying to force awkward things into node, like people attempting to write big full-stack webapps using it.

benatkin 15y ago
I didn't mention any of those libraries in my reply to your original comment. To help alleviate callback noise, there's https://github.com/caolan/kanso https://github.com/caolan/kanso , which Fenn mentions in his blog post's comments, and there are EventEmitters, and there is Function.bind() and Backbone.js-style async, where you have methods that describe what each callback does. (Backbone is usable in Node.js but perhaps not as practical on the server as it is on the client.) Also callbacks to me are kind of like parenthesis in Lisp. They're annoying but they're for the greater good. :)
- UncleOxidant 15y ago
  "deal with it" is a good response. personally, I'd rather write callbacks than deal with threads any day. And there are plenty of approaches to make dealing with callbacks easier (async.js is one of many).
  - rbranson 15y ago
    Actually, "deal with it" is fucking lame, isn't a response at all, and is a good example of why I use the term "fundamentalism." Is your problem with threads or shared mutable state? Web applications should be stateless and can be written as long request-response pipelines on-top of a pool of actor threads, with the only shared state existing at either ends of the pipeline, probably hidden by a framework anyways.
    - UncleOxidant 15y ago
      The "deal with it" is the same for threads - if you're using a system with threads you have to deal with them and it's generally not too fun. Node is what it is. It's callback based. I didn't mean the "deal with it" in a hostile way, more like that's the kind of system node is so deal with it. Is node great for every kind of problem? No. Definitely not. Actors are great too (and they've usually got threads in them, but they are well contained). But for certain kinds of apps node and the careful use of callbacks work out great. I guess I was trying to counter all of the hating on callbacks - they're not so awful when you get used to them.
      - sausagefeet 15y ago
        Tamejs makes it a bit easier to deal with. Life doesn't have to suck.
chrisohara 15y ago
the thinking that async code == callback spaghetti shit has to stop. There are plenty of async idioms that make callbacks a breeze.
- rbranson 15y ago
  I'll definitely admit that many of the inventive techniques that node.js users have come up with make dealing with callbacks less absurd, but the problem is that it's just polishing shit. It's extra hoops to jump through with no benefit, outside of the C10K fapfest. Would all the developers writing apps on node.js who are doing 10,000+ concurrent requests per process please stand up?
  - chrisohara 15y ago
    Only the minority gives a shit how many Hello World requests your stack can pump out. Some of us use node.js because it's a) got some decent libraries, b) makes realtime easy, c) uses the same code server+client-side reducing context-switches, and d) gets quite enjoyable once you know what you're doing. You obviously haven't written a lot of async code so not sure why you're so against the idea.
    - rbranson 15y ago
      So again, to you, what benefit does everything being built on this async, single-threaded, event-driven model give you? Sounds like not much. You could get all of those benefits + much cleaner code using threading or fibers or actors, but that does not make for C10K badassness, so here we are, with our callbacks. Also, I'd say I've written enough code on top of node.js to be qualified to comment on this. Here's some of it that's open source: https://github.com/rbranson/glob-trie.js https://github.com/rbranson/glob-trie.js https://github.com/rbranson/twerk https://github.com/rbranson/twerk https://github.com/rbranson/node-ffi https://github.com/rbranson/node-ffi
      - chrisohara 15y ago
        I get simple scalability, server-client code reuse, easy realtime, and, despite what you or others may think, I like Javascript as a language. Node.JS was also a perfect fit for the scraping framework I wrote: https://github.com/chriso/node.io https://github.com/chriso/node.io At one stage I had the same train of thought that you have (http://chris6f.com/synchronous-nodejs http://chris6f.com/synchronous-nodejs / https://github.com/chriso/synchronous/blob/master/lib/prototype.js https://github.com/chriso/synchronous/blob/master/lib/protot...) - it would be nice to have the option of fibers, but it's not going to happen. IMO async code isn't as difficult or ugly as you make it out to be. Is async code as easy to write and follow as sync code? No. Is it worth the benefits I've mentioned? For me, yes.

benatkin 15y ago

I didn't mention any of those libraries in my reply to your original comment. To help alleviate callback noise, there's https://github.com/caolan/kanso https://github.com/caolan/kanso , which Fenn mentions in his blog post's comments, and there are EventEmitters, and there is Function.bind() and Backbone.js-style async, where you have methods that describe what each callback does. (Backbone is usable in Node.js but perhaps not as practical on the server as it is on the client.) Also callbacks to me are kind of like parenthesis in Lisp. They're annoying but they're for the greater good. :)

UncleOxidant 15y ago
"deal with it" is a good response. personally, I'd rather write callbacks than deal with threads any day. And there are plenty of approaches to make dealing with callbacks easier (async.js is one of many).
- rbranson 15y ago
  Actually, "deal with it" is fucking lame, isn't a response at all, and is a good example of why I use the term "fundamentalism." Is your problem with threads or shared mutable state? Web applications should be stateless and can be written as long request-response pipelines on-top of a pool of actor threads, with the only shared state existing at either ends of the pipeline, probably hidden by a framework anyways.
  - UncleOxidant 15y ago
    The "deal with it" is the same for threads - if you're using a system with threads you have to deal with them and it's generally not too fun. Node is what it is. It's callback based. I didn't mean the "deal with it" in a hostile way, more like that's the kind of system node is so deal with it. Is node great for every kind of problem? No. Definitely not. Actors are great too (and they've usually got threads in them, but they are well contained). But for certain kinds of apps node and the careful use of callbacks work out great. I guess I was trying to counter all of the hating on callbacks - they're not so awful when you get used to them.
    - sausagefeet 15y ago
      Tamejs makes it a bit easier to deal with. Life doesn't have to suck.

chrisohara 15y ago

the thinking that async code == callback spaghetti shit has to stop. There are plenty of async idioms that make callbacks a breeze.

rbranson 15y ago
I'll definitely admit that many of the inventive techniques that node.js users have come up with make dealing with callbacks less absurd, but the problem is that it's just polishing shit. It's extra hoops to jump through with no benefit, outside of the C10K fapfest. Would all the developers writing apps on node.js who are doing 10,000+ concurrent requests per process please stand up?
- chrisohara 15y ago
  Only the minority gives a shit how many Hello World requests your stack can pump out. Some of us use node.js because it's a) got some decent libraries, b) makes realtime easy, c) uses the same code server+client-side reducing context-switches, and d) gets quite enjoyable once you know what you're doing. You obviously haven't written a lot of async code so not sure why you're so against the idea.
  - rbranson 15y ago
    So again, to you, what benefit does everything being built on this async, single-threaded, event-driven model give you? Sounds like not much. You could get all of those benefits + much cleaner code using threading or fibers or actors, but that does not make for C10K badassness, so here we are, with our callbacks. Also, I'd say I've written enough code on top of node.js to be qualified to comment on this. Here's some of it that's open source: https://github.com/rbranson/glob-trie.js https://github.com/rbranson/glob-trie.js https://github.com/rbranson/twerk https://github.com/rbranson/twerk https://github.com/rbranson/node-ffi https://github.com/rbranson/node-ffi
    - chrisohara 15y ago
      I get simple scalability, server-client code reuse, easy realtime, and, despite what you or others may think, I like Javascript as a language. Node.JS was also a perfect fit for the scraping framework I wrote: https://github.com/chriso/node.io https://github.com/chriso/node.io At one stage I had the same train of thought that you have (http://chris6f.com/synchronous-nodejs http://chris6f.com/synchronous-nodejs / https://github.com/chriso/synchronous/blob/master/lib/prototype.js https://github.com/chriso/synchronous/blob/master/lib/protot...) - it would be nice to have the option of fibers, but it's not going to happen. IMO async code isn't as difficult or ugly as you make it out to be. Is async code as easy to write and follow as sync code? No. Is it worth the benefits I've mentioned? For me, yes.