4 ms·
It seems we now have three camps: 1. "Node is the magic bullet." 2. "Node sucks." 3. "Nothing is that simple. Learn you some computer science." #3 is the co
by jarrett 15y ago
It seems we now have three camps:
1. "Node is the magic bullet."
2. "Node sucks."
3. "Nothing is that simple. Learn you some computer science."
#3 is the correct answer, but I'd like to see this point explored in more detail. The current back-and-forth isn't productive. What would be productive is if we had an informed discussion of what Node is good at, what not to do with it, and how it compares with other tools and approaches.
Specifically, I'd love to hear opinions on some of these points:
* Node is opinionated about threads. Negatively so. See http://nodejs.org/#about http://nodejs.org/#about . Do you agree with these claims?
* Non-blocking IO doesn't solve every performance problem under the sun. Far from it. But what problems does it solve exceptionally well?
* Is Node a breakthrough in computer science? Events and callbacks have been around for ages. What new ideas does Node bring to the table?
* Why exactly is Node supposed to be so scalable? Is scaling to more machines easier with Node than with other approaches? How about scaling to more cores on the same machine? Does Node provide any special support for distributing a task across multiple workers and possibly over the network, e.g. with something like MapReduce?
- olegp 15y agoI've been trying to debunk the overly negative views on threads in the Node community. Here is my presentation on fibers and my common-node project (includes benchmarks): http://www.slideshare.net/olegp/server-side-javascript-going-all-the-way http://www.slideshare.net/olegp/server-side-javascript-going...
- skeptical 15y ago+1 I like node (and ringojs) because it's a cool javascript interpreter with a nice set of libraries for practical use. I can buy the argument that node's single thread architecture can make things faster, but not before understanding why. I've googled this quite a lot every now and then since node showed up but noone is willing to explain why, every one just assumes is faster, lighter and easy to scale for some reason. Not doubting the slightest bit, just would like to know why is that so.
- nknight 15y ago#3 isn't even necessary -- you're telling someone to go learn calculus when all they really need is basic algebra, at most. 2-3 hours spent on layman's summaries of the practicalities of modern CPU architectures (special attention to cache coherence, what fun), user vs. kernel space and switching between them, select() and its cousins, and TCP would do most of the people involved in these debates a world of good.
- jarrett 15y agoI'd venture that 2-3 hours is far too little for someone to learn the topics you list from the ground up. But I'm just nit picking :). Your point is well-taken. But one big problem is that these are unknown unknowns for many people. Suppose a new but intelligent programmer finds Node and wants to decide whether it's good for some new project. How would that programmer know what to look up? How would s/he know that, e.g., user vs kernel space is even a relevant concern in the decision to use a single-threaded, event-based framework?