Hacker News Reader

Comment by russell_h | Hacker News Reader

I think what he is getting at is that if you want to handle multiple requests within the same process (in order to have in-process shared state, so you can make your chat server without external dependencies or whatever), you either need an event loop, threads, or both.

If you have threads, you do have to worry about mutexes and reentrance.

View on HN

none of that has anything to do with writing web-request-handling code, it has to do with writing custom servers.

There are plenty of asynchronous solutions for writing servers, including the very widely used Twisted platform as well as the Erlang programming language. It's a tad annoying that node.js is touted largely by front end developers as solving a supposedly previously unaddressed problem.

to wit:

> emerging set of programming conventions, philosophies, and values that I see evolving in the node.js community

no, sorry, they've already emerged, they've already evolved. Go download Twisted. Use node.js if you happen to like it better. But it's not the fricking messiah.

The asynchronous aspects were a very small piece of the article for a reason. Node is doing a lot of very interesting, important, and novel things that aren't related to asynchronous events at all. Twisted in particular suffers from too much exposed surface area and having to manage the reactor yourself, which hurts reusability a lot.

I'd prefer to see a detailed article about that.

Also I'd like to see more detail on why exactly writing custom servers is so profoundly important all the sudden. I hardly see the advantage of even nginx over apache, though that's a different issue.

WebSockets probably. None of the traditional server-side web frameworks (Ruby on Rails, Django, Java Servlets, ...) can deal with them because you need to maintain open connections with each client. That also makes asynchronous I/O important (a feature of nginx over apache).

Most WebSockets solutions are clumsy at best, because you need to run something independent from the rest of your web stack. Unless you use solutions like Wt (http://www.webtoolkit.eu/wt).

What do you mean when you say "independent of your stack"?

memcached, postgres, rabbit, etc aren't written in the language I use, but they're very much a part of my stack.

Using an external application to hold the WebSocket connections and be the middleman between your app code and the user is not automatically clumsy. Clumsy would be re-writing your app in JavaScript because you believe it's the only language suited to WebSockets.

as someone that has battled with twisted, I don't think this is a fair rebuttal. Twisted does _allow_ you to create servers, but it makes it pretty difficult and messy.

Node allows you to do the same thing very elegantly.

I don't think the problem is unaddressed, but node has the most elegant solution I've seen.

Did you even read the line you quoted? He didn't say "emerging set of software capabilities." The programming conventions, philosophies, and values of the Node.js community are evolving. Your response doesn't make any sense.

Reply on news.ycombinator.com