2 ms·

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

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.

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.