4 ms·

I don't really know much about node.js other than casual reading about it. Is there a use case for it for developers who know Twisted / EventMachine well? In ot

by icey 16y ago

I don't really know much about node.js other than casual reading about it. Is there a use case for it for developers who know Twisted / EventMachine well? In other words, can it provide something those frameworks can't?

bnoordhuis 16y ago
Node and its ecology of libraries are asynchronous from the ground up. With Twisted or EventMachine, you'll eventually call a library that performs blocking I/O (probably sooner than later) and that will be your bottleneck.
- icey 16y ago
  With Twisted at least there are usually asynchronous versions of commonly needed libraries. Given that, it sounds like they're probably fairly analogous then, right? I assume Node will have the same problem the moment someone grabs a package that's meant for a Javascript framework that isn't explicitly asynchronous.
  - weixiyen 16y ago
    That is correct.
  - mhansen 16y ago
    There aren't really Javascript frameworks that aren't explicitly asynchronous. - The browser-based APIs are all asynchronous - The other serverside JavaScript libraries will rely on blocking APIs that aren't supported in Node.JS, so they won't work.
dstein 16y ago
Performance aside, being able to write both client and server code in the same language has a lot of advantages. After seeing how well the NodeChat worked at twich.me, I am definitely interested in trying it out. I think building a real-time networked game entirely in JS would be kinda fun.
- jashkenas 16y ago
  Here's a link that might interest you then. Real-time Node.js Asteroids, written in CoffeeScript. Lazeroids.com: http://lazeroids.com/ http://lazeroids.com/ Here's the source: http://github.com/gerad/lazeroids-node/blob/master/views/application.js.coffee http://github.com/gerad/lazeroids-node/blob/master/views/app...
- mdg 16y ago
  >being able to write both client and server code in the same language has a lot of advantages. Instead of html + css + sql + js + (python, ruby, [FotM]) its just html + css + sql + js? I would not be surprised to see html + css + sql + js (dom manipulation) + js (server side). The only benefit I see is that one could re-use their input validation. Are there any examples of this in the wild? I have heard many claim that using JS on both sides is a big win, but have yet to come across anyone actually doing it (genuine question, it is something I would like to take notes from).
  - dstein 16y ago
    http://twich.me http://twich.me (based on http://chat.nodejs.org/ http://chat.nodejs.org/) was the first live Node app that I've seen.
    - mitjak 16y ago
      There is also tempalias by one of the HNrs. http://tempalias.com/#/ http://tempalias.com/#/ A very handy app indeed.
  - weixiyen 16y ago
    I use it on both sides (client and server). There's some code sharing between server and client side, but it's not a huge productivity boost that one should switch to a language they may not be comfortable with on the server side. Organizing your code into smaller modules is probably more important in Node.js than most other frameworks if you want to keep your sanity. Otherwise you'll end up with crazy arrow code due to all the callbacks. The speed that you gain from sharing the same language, you lose in the inability to write shorter code (Python/Ruby) and debugging callbacks. I think it's good to be language agnostic and have some sort of http rpc interface system to communicate between the languages.

by icey 16y ago

bnoordhuis 16y ago

Node and its ecology of libraries are asynchronous from the ground up. With Twisted or EventMachine, you'll eventually call a library that performs blocking I/O (probably sooner than later) and that will be your bottleneck.

icey 16y ago
With Twisted at least there are usually asynchronous versions of commonly needed libraries. Given that, it sounds like they're probably fairly analogous then, right? I assume Node will have the same problem the moment someone grabs a package that's meant for a Javascript framework that isn't explicitly asynchronous.
- weixiyen 16y ago
  That is correct.
- mhansen 16y ago
  There aren't really Javascript frameworks that aren't explicitly asynchronous. - The browser-based APIs are all asynchronous - The other serverside JavaScript libraries will rely on blocking APIs that aren't supported in Node.JS, so they won't work.

dstein 16y ago

Performance aside, being able to write both client and server code in the same language has a lot of advantages. After seeing how well the NodeChat worked at twich.me, I am definitely interested in trying it out. I think building a real-time networked game entirely in JS would be kinda fun.

jashkenas 16y ago
Here's a link that might interest you then. Real-time Node.js Asteroids, written in CoffeeScript. Lazeroids.com: http://lazeroids.com/ http://lazeroids.com/ Here's the source: http://github.com/gerad/lazeroids-node/blob/master/views/application.js.coffee http://github.com/gerad/lazeroids-node/blob/master/views/app...
mdg 16y ago
>being able to write both client and server code in the same language has a lot of advantages. Instead of html + css + sql + js + (python, ruby, [FotM]) its just html + css + sql + js? I would not be surprised to see html + css + sql + js (dom manipulation) + js (server side). The only benefit I see is that one could re-use their input validation. Are there any examples of this in the wild? I have heard many claim that using JS on both sides is a big win, but have yet to come across anyone actually doing it (genuine question, it is something I would like to take notes from).
- dstein 16y ago
  http://twich.me http://twich.me (based on http://chat.nodejs.org/ http://chat.nodejs.org/) was the first live Node app that I've seen.
  - mitjak 16y ago
    There is also tempalias by one of the HNrs. http://tempalias.com/#/ http://tempalias.com/#/ A very handy app indeed.
- weixiyen 16y ago
  I use it on both sides (client and server). There's some code sharing between server and client side, but it's not a huge productivity boost that one should switch to a language they may not be comfortable with on the server side. Organizing your code into smaller modules is probably more important in Node.js than most other frameworks if you want to keep your sanity. Otherwise you'll end up with crazy arrow code due to all the callbacks. The speed that you gain from sharing the same language, you lose in the inability to write shorter code (Python/Ruby) and debugging callbacks. I think it's good to be language agnostic and have some sort of http rpc interface system to communicate between the languages.