Hacker News new | past | comments | ask | show | jobs | submit login

Yours is not a technical argument either -- you're just pre-emptively claiming that no counterargument can be valid.



No, a technical counterargument could be valid if Node had any technical merit.

I'm claiming that no valid technical counterargument exists. If you disagree, it should be very easy for you to present a valid technical counterargument instead of trying to offload the burden of proof onto me.


geofft's reply to your grandparent comment is a valid counterargument IMO.

I noticed your reply, which is basically "nobody should be using an event loop". Whether you like it or not, that's how 99.99% of the GUI software in existence works (Win32, Cocoa, whatever). Node allows people to leverage their existing mental model into server apps.


But UI's have to be async if they want to be responsive, while the HTTP request-response cycle (which is what Node is predominantly used for) is completely synchronous.

Sure, things like WebSockets are changing this, but you don't really need an event loop if you have proper threads or a multi-process server (you know, like Node clustering, which you tend to need anyway once you outgrow the limits and pains of a single event loop).


Global event loops are fundamentally a bad abstraction for a parallel (not just concurrent) system.

It makes sense to leverage existing mental models in a lot of cases, but when you're moving to a new platform, you have to learn some new mental models because your existing mental model fundamentally doesn't work in the new system. Global event loops don't work, at all, in a system that actually needs to be parallel (i.e. most server systems).

Giving up on writing software that scales even to a basic level just so you can reuse your existing mental model isn't a good tradeoff.


The burden of proof is on you. What exactly is wrong with Node.js? It is a network server. It is programmed in a popular, expressive, dynamic language that a lot of coders already know. It has a great, well thought out base library. It does concurrency and asynchronous interactions really well. Since it is programmed in the same language as the client side, it allows code reuse between the server and the client. It has a vibrant ecosystem around it with a library for every possible need. It has a large community of developers.

So, if you want to claim that Node is bad, you need to come up with reasons why it is bad.


It lacks a coherent type system, its threading model is awful, and its security is fundamentally broken.

Your move.


To add to my other comment: the technical criticisms of Node have already been stated and were widely known. So if you're going to argue that using Node in a server environment is a technically sound choice, it's up to you now to respond to the criticisms.

And let's be clear: these are technical criticisms and if you could respond to them it would be with a technical defense of Node. Continuing to attack critics of Node or claim that we haven't already met our technical burden of proof only goes to show that your defense of Node is bankrupt from a technical perspective.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: