4 ms·
It's honestly not as much of an issue as it's often made out to be. There are a ton of ways to manage asynchronous code out there including but not limited to
by CitizenKane 12y ago
It's honestly not as much of an issue as it's often made out to be. There are a ton of ways to manage asynchronous code out there including but not limited to all the various promise libraries such as when.js(https://github.com/cujojs/when https://github.com/cujojs/when), q (https://github.com/kriskowal/q https://github.com/kriskowal/q), and bluebird (https://github.com/petkaantonov/bluebird https://github.com/petkaantonov/bluebird). Not to mention the Async library (https://github.com/caolan/async https://github.com/caolan/async) which is full of tools to help manage it.
As for blocking, it's something you deal with. Realistically speaking if you're doing CPU intensive tasks then Node is definitely the wrong solution. However, if you're doing tasks that are IO oriented then Node is fantastic.
- jbergens 12y agoActually I think that even a lot of CPU intensive tasks could run on Node. Split them into smaller tasks (which you probably have to do anyway if you want to use multiple threads with another language) and run those as promises. Of course js is bad for most numerical calculation but for some things it might work. Or combine it with Dart or Asm.js.
- tracker1 12y agoYou can also use multiple worker processes for your more intensive cpu tasks, keeping that out of your main loop altogether. Pooling and queue limits can prevent too many of those bound processes from running at once, and you can distribute workers across several systems.
- kxo 12y ago> Realistically speaking if you're doing CPU intensive tasks then Node is definitely the wrong solution Here's the answer: Spawn $(nproc) more Node processes, use IPC if you need to. Good luck seizing the theoretical performance gains one might see from threading (while not falling victim to diminishing returns related to context switching) in another comparable language.