Live data from Hacker News

Node.js has jumped the shark

unlimitednovelty.com

131–140 of 144 posts

Re: Node.js has jumped the shark

#131
post #125
post #117

Earlier quoted context omitted.

Summary: Ted: "Node is cancer, because it's not the one true tool that can do everything! It may be good at IO bound code but it's not so hot at CPU bound stuff". Node hackers: "Yes it is the one true tool!". Me: face-palm. OK, Threads can be used to do anything, but they are hard, while async is pretty easy (unless you want to do CPU bound stuff). async sucks for CPU bound stuff, but that's not the problem it's tryi…

Please, show us even one Node developer who posted "Yes it is the one true tool!" – or even a sentiment that is remotely similar.

Hm...

Bunch of people with limited social skills or sanity, in a virtual desert, having flame-wars with strawmen?

Sounds like burning man.

Re: Node.js has jumped the shark

#132

Earlier quoted context omitted.

> Ted Dziuba is clearly a person suffering from profound intellectual insecurity, and a lack of technical acumen. Perhaps, as the one responding to a criticism of a piece of software with personal attacks, you are the one that is insecure? I can understand how, as a fanboy of something that was criticized, you would now take it upon yourself to hurl insults on the person who has wronged you so. This is the internet a…

> I can understand how, as a fanboy of something that was criticized Can you define "fanboy" for me, please? I don't know what it means. > Actually, you opened this comment by personally attacking Ted I wasn't attacking Ted. Actually, my heart really does go out to him. I mean, he's a human being, right? Could you imagine living with such a crippling psychological disorder? Just think of it. The pain, the emptiness.…

You write node that go so fast. Why spend time on site that load so slow?

Re: Node.js has jumped the shark

#133
post #56

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 an…

#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.

Re: Node.js has jumped the shark

#134
post #61

I use node.js for long-lived connections (sending/receiving large amounts of data, or long-polling). This is a task to which it is ideally suited. Putting CPU-intensive operations inside a HTTP handler is something that is obviously not going to work in a single-process, single-threaded event-driven framework. Ted's complaining because node.js is unsuitable for something that it's not intended to be used for. Defendi…

> Defending CGI, in my opinion, also hurts his credibility. The "good old days" weren't so good. Spawning a new process for each request? Re-establishing database connections every time? That shit only worked because there were three people on the internet at the time. Apparently the server behind SQLite.org and Fossil-scm.org, which gets 250M requests/day, spawns a new HTTP server for each request. There's no databa…

fossil-scm.org uses SQLite database (in WAL mode), and the website is the repository itself.

http://www.fossil-scm.org/index.html/doc/trunk/www/selfhost....

Re: Node.js has jumped the shark

#135
post #125
post #117

Earlier quoted context omitted.

Summary: Ted: "Node is cancer, because it's not the one true tool that can do everything! It may be good at IO bound code but it's not so hot at CPU bound stuff". Node hackers: "Yes it is the one true tool!". Me: face-palm. OK, Threads can be used to do anything, but they are hard, while async is pretty easy (unless you want to do CPU bound stuff). async sucks for CPU bound stuff, but that's not the problem it's tryi…

Please, show us even one Node developer who posted "Yes it is the one true tool!" – or even a sentiment that is remotely similar.

https://github.com/glenjamin/node-fib is close enough. Trying to explain how Node can do concurrent Fibonacci without calling another process is falling for the troll's trap - Node isn't "the one true tool", and you don't need to try to prove that it is. The trolls will just say that Fibonacci is too trivial, and you wouldn't use the same approach (co-operative multi-threading) for less trivial CPU-bound tasks.

You can use a hammer to bang in screws, but it's not usually the best way. If you are using co-operative multi-threading as a way to get Node to handle concurrent CPU-bound requests, you are Doing It Wrong (TM). In general, it's better to create a second (possibly not async) server to handle CPU intensive stuff, or fork stuff off to a subprocess (depending on the actual task). There might also be other ways - I'm not an expert.

I'm sure that if glenjamin had a less trivial CPU-bound task, he/she would handle it a better way (depending on what the task was). But to the Node haters, node-fib is just troll food. It's also an interesting example of how node.js works, but the trolls don't care.

Re: Node.js has jumped the shark

#136
post #92
post #64

Earlier quoted context omitted.

So, I'm not a node.js guy, and nothing against it, but being a server-side guy in general, I'll paraphrase a quote that Zed Shaw paraphrased from Chinese Kung Fu novels: "So the intermediate guy is doing all of these backflips and spinning roundhouse kicks and all that, it's very impressive, you couldn't imagine being in that good control of your body. He decides he's pretty good and spars with a master. The master b…

I think in this case, we have yet to see the master put anyone on their ass. We have non-masters slinging insults and ineffective demonstrations. Don't typical Python and Ruby deployments also need 8 processes to utilize 8 cores? If I'm not mistaken, this is in fact how Heroku works.

http://functional-orbitz.blogspot.com/2011/10/your-favorite-...

Re: Node.js has jumped the shark

#137
post #134

Earlier quoted context omitted.

> Defending CGI, in my opinion, also hurts his credibility. The "good old days" weren't so good. Spawning a new process for each request? Re-establishing database connections every time? That shit only worked because there were three people on the internet at the time. Apparently the server behind SQLite.org and Fossil-scm.org, which gets 250M requests/day, spawns a new HTTP server for each request. There's no databa…

fossil-scm.org uses SQLite database (in WAL mode), and the website is the repository itself. http://www.fossil-scm.org/index.html/doc/trunk/www/selfhost....

Oops. Thanks.

Re: Node.js has jumped the shark

#138
I have a question about Node.js I hope it's legitimate.

If I have a endless loop in some method that is supposed to generate some part of some webpage of my webapp will it stall the whole app until I restart the server?

From my tests it seems so.

What additional facilities are required to be used so that single bug won't kill the whole app for all users?

Rant mentiones putting nginx in front of node.

UPDATE:

It seems that there is a tool called monit that can restart your server when it stalls:

http://howtonode.org/deploying-node-upstart-monit

Re: Node.js has jumped the shark

#139
post #51
post #45

Earlier quoted context omitted.

[deleted]

It's possible I'm misinterpreting the results (or the benchmark is flawed), but this seems to imply that it is often the case: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

Things will be a little different on x64 but you seem to be reading the data just fine ;-)

http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

The problem isn't really "the benchmark is flawed", the problem is that most of us seem to wish for data that tells us more than it can, magical wishful thinking on our part - Will the application I haven't designed yet be faster, and scale better, and be completed by us faster, if we write it in X or Y? :-)

http://shootout.alioth.debian.org/dont-jump-to-conclusions.p...

Re: Node.js has jumped the shark

#140
post #56

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 an…

#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.

I'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?

Post reply on HN