13 ms·

The secrets of Node's success

79 points by fogus 15y ago

6ren 15y ago
A failing with programmers is we tend to focus on solutions rather than problems. Perhaps it's partly because, to be a good programmer, you need to immerse yourself in the code. Unfortunately, this takes your attention away from the bigger problem that the code solves. In this article, it's interesting that though "Node solves a problem" is stressed as key to its success, compared with the many other JS server-side projects, they don't explicitly mention the problem, except obliquely at the end! (The problem is efficiently handling massive concurrencies in network connections.) It's because of this short-sightedness of programmers that there will always be easy pickings available to anyone who actually looks at problem. Be a problem-person, not a solution-person.
- jshen 15y ago
  And it doesn't define "massive" :/ I still don't see a compelling reason to use node. I think the jvm is a better choice all around.
  - superjared 15y ago
    "Massive" in this case is terribly subjective. I think the typical definition is concurrency between 10k and 50k. Whereas when we (at Urban Airship) wanted to hit 500k, the only reasonable way to do that without resorting to pure C was by using the JVM.
    - baudehlo 15y ago
      It depends what your clients are doing. I've written perl servers (using epoll) that can cope with 300k concurrent connections, as long as they're not all talking at once. I've written perl servers coping with 50k concurrent connections where they are all talking at once too. And v8 is MUCH faster than Perl.
      - jshen 15y ago
        And slower than the JVM
        baudehlo 15y ago
        Meh, sure basic operations are always going to be slower due to lack of type information, but for most work it's going to be pretty close to the JVM in terms of I/O, database access, etc. For compute specific tasks, sure it may not be the right tool for the job.
        jshen 15y ago
        I'll be that clojure is faster and it isn't statically typed. I have far more confidence in the JVM handling heavy load that V8 which wasn't designed as a server side technology.
gvnonor 15y ago
From a couple of presentations I watched and reading online, nodejs advertises that it makes writing web servers easy. Do everyday programmers actually need node or is it meant to be a niche language?
- andrewcooke 15y ago
  it's not a language at all. it's a library for writing server-side code in javascript. it's event driven, like python's twisted. in fact, it's hard (if you assume people are rational [edit: and have perfect access to information]) to see why people find nodejs so cool, yet have been ignoring twisted for years.
  - AlexC04 15y ago
    From my point of view, it's down to a combination of good marketing and 'right place at the right time'. I've never heard of twisted - but I feel like I'm getting in on the ground floor with node. Additionally, I was positively salivating to learn a new language when it started 'emerging'. I think part of it comes down to the fact that I was already very comfortable with Javascript, so I started with node.js knowing that I at least knew some of the basics ... and thank got I did, because programming in node is very different from what I'm used to. It's sometimes difficult to know which lines of code are blocking and which aren't.
  - nxn 15y ago
    I think it was a combination of things. One, the timing was nice because JavaScript was getting more and more attention as its engines were starting to seriously compete for speed. Two, I think the fact that it was JavaScript on the server really helped get it a lot of buzz as it was somewhat "controversial". "Controversial" because I can't think of another language whose users are so split between liking and hating it. Having it invade the server meant a lot of people's blood began to boil as they thought of having to potentially deal with it outside the browser, and a lot of other people who were excited about being able to use it outside the browser. Either way, the combination of love and hate gathered a lot of talk and attention in my opinion. Now to contrast this with python: I personally have never heard of Twisted before all the talk of Node came about. Mind you, I'm not a python developer and if someone's blog title doesn't grab my attention by having some connection to me, or what I do, I'll probably just skip over it.
MatthewPhillips 15y ago
I don't see a lot of merit to the "sharing code" idea as the purpose of server side code and client side code are completely different. There are 2 possible exceptions where I can see some use: 1) Utility libraries. I have a clone method I use a lot, an would work equally well in both environments. I'm sure math libraries would be the same way. 2) Models. Maybe. Personally, my server side models contain get and save methods which make database calls. I don't want or need those on the client side. If for no reason other than wasted bandwidth. * note: I'm a node user, but I don't share any code between server and browser.
- awj 15y ago
  I definitely am in the same camp on the "sharing code" argument, but could see careful structuring make models sort-of work. Obviously the basic persistence behavior needs to change, but if you reduce validation and some of the business logic to something more composable/interchangeable you could share it between the two. Obviously then you'd need some way of distinguishing validation that is only important to one of the two ends from that which is meaningful to both, but I can see it being possible. That said, I'm still not convinced it's worth it. Especially when you look at the state of libraries in node compared to something like Python/Ruby.
- baudehlo 15y ago
  The way I've heard it argued is that as more and more things happen in the client, you want some level of data validation there. But as we all know, it's not enough to just validate the data in the client - you need to do it on the server too. So hence code duplication.
- jules 15y ago
  Example: You are building an editable list. The client insert and delete items from the list, which is then synchronized with the database. Now you need the HTML generating code on both the client and the server. Another example: validation. You want to validate on the client for responsiveness, but on the server for integrity.
  - 15y ago
dreamdu5t 15y ago
The secret to Node's success? The V8 engine. ;)
- BasDirks 15y ago
  Node hooks into it quite neatly.
- pavlov 15y ago
  But would anyone really notice if Node used WebKit's JavaScriptCore (a.k.a. "Nitro") instead? There isn't a huge performance gap between the two engines these days... But V8 is easier to embed in C++, I think.
  - rbranson 15y ago
    All of the native extensions that would break would notice.
  - grayrest 15y ago
    The js team at mozilla mentioned that they had a jagermonkey version running internally as part of a test for the embedding api updates they're working on.
rbranson 15y ago
Node.js is neat, and I have contributed some things to the community, but it has a long way to go honestly if it's to be taken seriously in the performance and infrastructure realm. Articles like this don't help it's image either. It's as if a naive PHP developer suddenly discovered long-running processes, eliciting a chorus of rolling eyes from those who've written server software in the last 30 years. Ryan and team are talented people, but they're mostly dependent on the V8 team, which is focused on building a JavaScript interpreter for a browser. Node.js/V8 has come tremendously far in the last 18 months, but still hits some particularly nasty walls when it comes to massive concurrency and managing big pools of memory in non-trivial applications. It will take some serious time for these challenges to be overcome. The JVM, Erlang/OTP, and C are particularly good platforms for this type of software because they're mature and well tested in these environments. I really hope for the sake of the project that the hype surrounding Node.js blows over and the hipster crowd moves on.
- bergie 15y ago
  The PHP community is just now discovering long-running processes. Yesterday we made TYPO3 run on AppServer-in-PHP, and this simple setup change gave a 2-4x performance boost depending on complexity of request
samlittlewood 15y ago
And another thing .. Buffers, which is partly down to V8's external indexed data, and node's wrapping of that in the Buffer classes which are then used by the various async. IO operations. This means that content can flow through a node service with being touched by javascript, and without adding work to the garbage collector.

79 points by fogus 15y ago

6ren 15y ago

A failing with programmers is we tend to focus on solutions rather than problems. Perhaps it's partly because, to be a good programmer, you need to immerse yourself in the code. Unfortunately, this takes your attention away from the bigger problem that the code solves. In this article, it's interesting that though "Node solves a problem" is stressed as key to its success, compared with the many other JS server-side projects, they don't explicitly mention the problem, except obliquely at the end! (The problem is efficiently handling massive concurrencies in network connections.) It's because of this short-sightedness of programmers that there will always be easy pickings available to anyone who actually looks at problem. Be a problem-person, not a solution-person.

jshen 15y ago
And it doesn't define "massive" :/ I still don't see a compelling reason to use node. I think the jvm is a better choice all around.
- superjared 15y ago
  "Massive" in this case is terribly subjective. I think the typical definition is concurrency between 10k and 50k. Whereas when we (at Urban Airship) wanted to hit 500k, the only reasonable way to do that without resorting to pure C was by using the JVM.
  - baudehlo 15y ago
    It depends what your clients are doing. I've written perl servers (using epoll) that can cope with 300k concurrent connections, as long as they're not all talking at once. I've written perl servers coping with 50k concurrent connections where they are all talking at once too. And v8 is MUCH faster than Perl.
    - jshen 15y ago
      And slower than the JVM
      - baudehlo 15y ago
        Meh, sure basic operations are always going to be slower due to lack of type information, but for most work it's going to be pretty close to the JVM in terms of I/O, database access, etc. For compute specific tasks, sure it may not be the right tool for the job.
        jshen 15y ago
        I'll be that clojure is faster and it isn't statically typed. I have far more confidence in the JVM handling heavy load that V8 which wasn't designed as a server side technology.

gvnonor 15y ago

From a couple of presentations I watched and reading online, nodejs advertises that it makes writing web servers easy. Do everyday programmers actually need node or is it meant to be a niche language?

andrewcooke 15y ago
it's not a language at all. it's a library for writing server-side code in javascript. it's event driven, like python's twisted. in fact, it's hard (if you assume people are rational [edit: and have perfect access to information]) to see why people find nodejs so cool, yet have been ignoring twisted for years.
- AlexC04 15y ago
  From my point of view, it's down to a combination of good marketing and 'right place at the right time'. I've never heard of twisted - but I feel like I'm getting in on the ground floor with node. Additionally, I was positively salivating to learn a new language when it started 'emerging'. I think part of it comes down to the fact that I was already very comfortable with Javascript, so I started with node.js knowing that I at least knew some of the basics ... and thank got I did, because programming in node is very different from what I'm used to. It's sometimes difficult to know which lines of code are blocking and which aren't.
- nxn 15y ago
  I think it was a combination of things. One, the timing was nice because JavaScript was getting more and more attention as its engines were starting to seriously compete for speed. Two, I think the fact that it was JavaScript on the server really helped get it a lot of buzz as it was somewhat "controversial". "Controversial" because I can't think of another language whose users are so split between liking and hating it. Having it invade the server meant a lot of people's blood began to boil as they thought of having to potentially deal with it outside the browser, and a lot of other people who were excited about being able to use it outside the browser. Either way, the combination of love and hate gathered a lot of talk and attention in my opinion. Now to contrast this with python: I personally have never heard of Twisted before all the talk of Node came about. Mind you, I'm not a python developer and if someone's blog title doesn't grab my attention by having some connection to me, or what I do, I'll probably just skip over it.

MatthewPhillips 15y ago

I don't see a lot of merit to the "sharing code" idea as the purpose of server side code and client side code are completely different. There are 2 possible exceptions where I can see some use: 1) Utility libraries. I have a clone method I use a lot, an would work equally well in both environments. I'm sure math libraries would be the same way. 2) Models. Maybe. Personally, my server side models contain get and save methods which make database calls. I don't want or need those on the client side. If for no reason other than wasted bandwidth. * note: I'm a node user, but I don't share any code between server and browser.

awj 15y ago
I definitely am in the same camp on the "sharing code" argument, but could see careful structuring make models sort-of work. Obviously the basic persistence behavior needs to change, but if you reduce validation and some of the business logic to something more composable/interchangeable you could share it between the two. Obviously then you'd need some way of distinguishing validation that is only important to one of the two ends from that which is meaningful to both, but I can see it being possible. That said, I'm still not convinced it's worth it. Especially when you look at the state of libraries in node compared to something like Python/Ruby.
baudehlo 15y ago
The way I've heard it argued is that as more and more things happen in the client, you want some level of data validation there. But as we all know, it's not enough to just validate the data in the client - you need to do it on the server too. So hence code duplication.
jules 15y ago
Example: You are building an editable list. The client insert and delete items from the list, which is then synchronized with the database. Now you need the HTML generating code on both the client and the server. Another example: validation. You want to validate on the client for responsiveness, but on the server for integrity.
- 15y ago

dreamdu5t 15y ago

The secret to Node's success? The V8 engine. ;)

BasDirks 15y ago
Node hooks into it quite neatly.
pavlov 15y ago
But would anyone really notice if Node used WebKit's JavaScriptCore (a.k.a. "Nitro") instead? There isn't a huge performance gap between the two engines these days... But V8 is easier to embed in C++, I think.
- rbranson 15y ago
  All of the native extensions that would break would notice.
- grayrest 15y ago
  The js team at mozilla mentioned that they had a jagermonkey version running internally as part of a test for the embedding api updates they're working on.

rbranson 15y ago

Node.js is neat, and I have contributed some things to the community, but it has a long way to go honestly if it's to be taken seriously in the performance and infrastructure realm. Articles like this don't help it's image either. It's as if a naive PHP developer suddenly discovered long-running processes, eliciting a chorus of rolling eyes from those who've written server software in the last 30 years. Ryan and team are talented people, but they're mostly dependent on the V8 team, which is focused on building a JavaScript interpreter for a browser. Node.js/V8 has come tremendously far in the last 18 months, but still hits some particularly nasty walls when it comes to massive concurrency and managing big pools of memory in non-trivial applications. It will take some serious time for these challenges to be overcome. The JVM, Erlang/OTP, and C are particularly good platforms for this type of software because they're mature and well tested in these environments. I really hope for the sake of the project that the hype surrounding Node.js blows over and the hipster crowd moves on.

bergie 15y ago
The PHP community is just now discovering long-running processes. Yesterday we made TYPO3 run on AppServer-in-PHP, and this simple setup change gave a 2-4x performance boost depending on complexity of request

samlittlewood 15y ago

And another thing .. Buffers, which is partly down to V8's external indexed data, and node's wrapping of that in the Buffer classes which are then used by the various async. IO operations. This means that content can flow through a node service with being touched by javascript, and without adding work to the garbage collector.