Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The node.js aesthetic

substack.net

Post reply on HN
Print view View original

21–30 of 81 posts

Re: The node.js aesthetic

#21

Post by MostAwesomeDude »

uast23 wrote: post #14
zzzeek wrote: post #5

>You don't need to reason about multiple instruction pointers or mutexes or re-entrant, interruptible execution because all the javascript you write just lives in a single thread. I see....on the other hand, when I write request-handling code using (any web framework ever on any platform), you're suggesting that we do worry about mutexes and reentrance (not to mention, handling a single request uses multiple threads?…

My understanding is: When you are using a ruby or python based web framework, each request is a blocking request i.e. after each request you wait for the response before proceeding further e.g. urllib.urlopen(), which as a result causes the no of requests handled/second to go down. Using eventmachine or gevent respectively for ruby or python is one way to overcome this. In node.js there is no such concept of blocking…

How did you find gevent and totally miss Twisted, which is linked on the front page of nodejs.org?

There are a handful of frameworks that assume every request is fully concurrent and non-blocking. Twisted-based stuff is the most prevalent, for Python, like Nevow, Athena, and the stuff baked into twisted.web. However, WSGI itself doesn't say anything about the concurrency of individual requests, and it's totally possible for WSGI requests to be multithreaded, multiprocess, or otherwise concurrent.

Re: The node.js aesthetic

#22

Post by nknight »

koen wrote: post #13

> A big part of what empowers node to make these kinds of interfaces possible is its asynchronous nature. No longer do you have statelessness imposed from on high by the likes of apache or rails. You can keep intermediate state around in memory just like in any ordinary program. Should that not be: A big part of what empowers node to make these kinds of interfaces possible is its "statefull" nature. ... Really, that…

It's frowned upon by people who need high availability with minimum complexity of hardware and software configuration.

There's very little state one can reasonably store on a single web server without interrupting sessions if the server fails, and there's almost none you can store if you can't guarantee user X will always connect to server X for the duration of the session.

Not everyone must solve these problems, but they quickly come to the forefront for anything beyond rather low-traffic sites.

Re: The node.js aesthetic

#23

Post by moe »

substack wrote: post #4
gbog wrote: post #2

Hmm, seems a bit hand-waving to me, but to be fair I have never tried Node.js and would probably have hard time convincing my finger to type javascript code for server things. Javascript always seemed to me a language that you used, and tried to use correctly, because you had to. On a server I have the choice, right? So my choice is currently Python so I read this article with some bias. In the section "batteries not…

> But still, having dealt with library version issues sometimes, I think "concurrent library versioning" and "sophisticated package management" sound awfully nightmarishly black-magic to me. I guess I would be more on the "let's understand the most of what happens and not change what don't need to" kind. Concurrent versioning lets you do the "not change what don't need to" part really, really, well. Versions of packa…

because node and npm are already paranoid on your behalf.

Yes, until npm blows up in obscure ways. Which it likes to do frequently.

Re: The node.js aesthetic

#24

Post by russell_h »

zzzeek wrote: post #5

>You don't need to reason about multiple instruction pointers or mutexes or re-entrant, interruptible execution because all the javascript you write just lives in a single thread. I see....on the other hand, when I write request-handling code using (any web framework ever on any platform), you're suggesting that we do worry about mutexes and reentrance (not to mention, handling a single request uses multiple threads?…

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.

Re: The node.js aesthetic

#25

Post by munificent »

> So if a module "foo" was tested against and depends on "baz@0.1.x" and a module "bar" depends on "baz@0.2.x", then when you go to use both "foo" and "bar" in your own program, "foo" and "bar" will both use the version of "baz" that they were tested and depend against!

That sounds like a recipe for disaster if I get an object from "bar" that came from "baz@0.2.x" and try to give it to "foo" which then gives it to "baz@0.1.x".

I'm suspicious of silver bullets in general and I'm deeply suspicious of any silver bullet that claims to slay version hell. Versioning is hard.

Re: The node.js aesthetic

#26

Post by [deleted] »

viscanti wrote: post #19
phamilton wrote: post #12

Could someone clarify something for me? Is http.createServer robust enough for production? It is my understanding that running it as is in production is not a good idea. You want to at least configure nginx between node and the world. If that's the case, doesn't that undermine the whole "focus on your application, not the configuration" point he's making? Sure you can call startServer multiple times, but then you wou…

I don't want to sound like I'm over qualifying things, but it really depends on the situation. For most applications http.createServer will be robust enough for production. There are node based solutions for dealing with load balancing, that would make nginx unnecessary in almost all cases. It really comes down to tradeoffs. If your primary concern is the most simultaneous connections, then you'll need to find a spec…

[deleted]

Re: The node.js aesthetic

#27

Post by jahewson »

phamilton wrote: post #12

Could someone clarify something for me? Is http.createServer robust enough for production? It is my understanding that running it as is in production is not a good idea. You want to at least configure nginx between node and the world. If that's the case, doesn't that undermine the whole "focus on your application, not the configuration" point he's making? Sure you can call startServer multiple times, but then you wou…

To the best of my knowledges: yes. Using nginx in front of node seems to have originated as a non-root way of getting access to port 80, prior to node supporting setuid. A better way on Linux is just to use the kernel TCP routing, for example:

sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

However, if you're using HTTP virtual servers and you already use nginx, sure, place node behind it.

Re: The node.js aesthetic

#28

Post by mbucc »

uast23 wrote: post #14
zzzeek wrote: post #5

>You don't need to reason about multiple instruction pointers or mutexes or re-entrant, interruptible execution because all the javascript you write just lives in a single thread. I see....on the other hand, when I write request-handling code using (any web framework ever on any platform), you're suggesting that we do worry about mutexes and reentrance (not to mention, handling a single request uses multiple threads?…

My understanding is: When you are using a ruby or python based web framework, each request is a blocking request i.e. after each request you wait for the response before proceeding further e.g. urllib.urlopen(), which as a result causes the no of requests handled/second to go down. Using eventmachine or gevent respectively for ruby or python is one way to overcome this. In node.js there is no such concept of blocking…

blocking / non-blocking has nothing to do with language; for e.g., see tornado for async request handling in python.

Re: The node.js aesthetic

#29

Post by zzzeek »

russell_h wrote: post #24
zzzeek wrote: post #5

>You don't need to reason about multiple instruction pointers or mutexes or re-entrant, interruptible execution because all the javascript you write just lives in a single thread. I see....on the other hand, when I write request-handling code using (any web framework ever on any platform), you're suggesting that we do worry about mutexes and reentrance (not to mention, handling a single request uses multiple threads?…

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.

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.

Re: The node.js aesthetic

#30

Post by substack »

zzzeek wrote: post #29
russell_h wrote: post #24

Earlier quoted context omitted.

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.

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…

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.
Post reply on HN