4 ms·

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

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.
  - sausagefeet 15y ago
    > Is it worth the benefits I've mentioned? For me, yes. This sounds like a tacit admittance that you're willing to deal with it because you don't think you have other options, but you do. There is at least one CPS compiler for Node (TameJS), and there are other languages that allow for the same result, but more straightforward implementations of concurrent code (Erlang, Ocaml/LWT, Haskell). I'm not saying you should use though, but we can do better and we should, even if it's just compiling back to JS in the end.
wunderfool 15y ago
node.js has nothing to do with "real-time"

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.
- sausagefeet 15y ago
  > Is it worth the benefits I've mentioned? For me, yes. This sounds like a tacit admittance that you're willing to deal with it because you don't think you have other options, but you do. There is at least one CPS compiler for Node (TameJS), and there are other languages that allow for the same result, but more straightforward implementations of concurrent code (Erlang, Ocaml/LWT, Haskell). I'm not saying you should use though, but we can do better and we should, even if it's just compiling back to JS in the end.

wunderfool 15y ago

node.js has nothing to do with "real-time"