5 ms·

What are the arguments against node.js in their use case? Not looking to start any wars, but I was under the impression that if you know what you're doing* nod

What are the arguments against node.js in their use case? Not looking to start any wars, but I was under the impression that if you know what you're doing* node.js is pretty awesome. This particular bug had to do with a misunderstanding regarding the express API. * for the most part: understand async and closures/memory leaks.

yourad_io 12y ago
To give some arguments in favour: - "Here we see our latencies drop down to 1 ms and remain there after we deployed our fix." <- Performance (from TFA) - They can hire from a vastly larger pool of developers. Since they've got both budget and brand recognition, they should have no problems hiring high end JS guys & gals.
- remon 12y ago
  Why are these arguments in favor of Node.js over their current Java based stack? Java is both considerably more speedy for this sort of workload and there's a significantly larger pool of high end Java server developers compared to high end JavaScript server developers. Budget and brand recognition are not necessarily in favor of node.js over other stacks. That simply helps with getting the better engineers in general.
  - yourad_io 12y ago
    They are arguments in favor of node.js being a reasonable tool for the job. > Java is both considerably more speedy for this sort of workload They're quoting 1ms latencies, that's pretty speedy. Maybe Java could do <1ms and/or support slightly more concurrent requests. How much difference does it actually make when you're already responding after 1 millisecond? > there's a significantly larger pool of high end Java server developers compared to high end JavaScript server developers Oh, I would have thought there are far more JS* folks out there than Java. > Budget and brand recognition are not necessarily in favor of node.js over other stacks. That simply helps with getting the better engineers in general. That's what I meant - them being in favour of Netflix as an employer - they aren't "Bob's Digital Agency" so they can have their pick of the litter of node devs. * I'm not sure if the "server" distinction is meaningful here - if you know JS, you know node.js - simply a matter of familiarizing yourself with node-specific APIs.
    - remon 12y ago
      I'm not sure if I agree. Responding after 1ms is not the same (or even very much related to) routing a request taking up 1ms of cpu time. Although there are a ton of nuances that make the following a small oversimplification it does basically mean that purely for routing alone you have a hard cap on 1k lookups/sec/core. And building server software in any language takes a whole different set of skills and knowledge than knowing how to build front ends. I'm not arguing one is harder or more involved than the other but they are different enough to make language and paradigm familiarity and the only real gain when moving from front-end JS to node.
      - mnutt 12y ago
        The parent (and the article) are both talking about 1ms request latencies, not 1ms routing latency.
  - JDiculous 12y ago
    One more advantage of Node.js over Java is that development is much faster with Node.js.
    - gasping 12y ago
      No, just please no. Any moderately competent programmer can be productive in either Java or Javascript (+ Node.js). Javascript may help incompetent programmers feel productive because Javascript has fewer compile-time constraints but in the long run the cost of maintaining code written by an incompetent more than counteracts any perceived benefit that Javascript offers.
      - JDiculous 12y ago
        Well obviously the work of an incompetent programmer is going to increase the long run cost of maintaining code. That has nothing to do with the fact that Javascript is faster to develop in.
Terr_ 12y ago
I was doing some googling about this earlier, IIRC one of the big ones was "Good when your bottleneck is I/O, not good when your bottleneck is CPU."
- remon 12y ago
  I hear this more often and it is somewhat misleading. That sentence seems to imply node.js is better in terms of I/O throughput compared to other technologies, as if it's a trade off. This is incorrect and it would be more accurate to say "Good enough when your bottleneck is I/O, not good when your bottleneck is CPU.".
- yourad_io 12y ago
  > "not good when your bottleneck is CPU" 99% of cases, your bottleneck will be I/O. In the 1% of cases where your webserver's bottleneck is the CPU, you have much bigger problems than using a hipster ;) language: you're doing it wrong (tm) on an architectural level: (a) Your processor-intensive/long-running tasks need to be in seperate worker processes and (b) you need more webserver instances. I usually try to avoid absolute statements, but I think this may be accurate: The only CPU-intensive thing your web server code should ever do, is hash passwords.
  - yourad_io 12y ago
    I shouldn't have tried to be funny on HN* . For this I apologize. Can I get a rebuttal to my points along with the downvotes, though? Is someone disputing that CPU intensive tasks should be moved off the webserver? Have you personally had experiences where your honest-to-$deity webserver bottleneck was the CPU? I'd be incredibly surprised. In most cases I'd guess you're underprovisioned and/or badly architected. * This is where we come to somberly discuss interesting things.
    - nostrademons 12y ago
      You're assuming a number of things that aren't always true: 1. Your networking pipe into the server is slow. 2. You don't have a reverse proxy in front of the webserver to buffer the slow connections. 3. You don't make decisions about what information to show the user in the webserver; your UI isn't tailored for the particular user whose request you're servicing. 4. You haven't made productivity trade-offs to move work from the developer to the computer. Google's webservers (for Search) are CPU-bound, and I can guarantee that they are neither underprovisioned nor badly architected, and CPU-intensive tasks are moved off the webserver (the total amount of CPUs for webservers is miniscule compared to the number of CPUs used for the indexing & serving system). But Google has the fastest fiber networks in the world, a massive load-balancing infrastructure, its philosophy is to serve each user only the HTML/JS that they need (to cut latency), it relies heavily on A/B tests & experimentation, and it invests significantly in developer-productivity tools so that all the bookkeeping for the last two points are done by computers rather than humans.

yourad_io 12y ago

To give some arguments in favour: - "Here we see our latencies drop down to 1 ms and remain there after we deployed our fix." <- Performance (from TFA) - They can hire from a vastly larger pool of developers. Since they've got both budget and brand recognition, they should have no problems hiring high end JS guys & gals.

remon 12y ago
Why are these arguments in favor of Node.js over their current Java based stack? Java is both considerably more speedy for this sort of workload and there's a significantly larger pool of high end Java server developers compared to high end JavaScript server developers. Budget and brand recognition are not necessarily in favor of node.js over other stacks. That simply helps with getting the better engineers in general.
- yourad_io 12y ago
  They are arguments in favor of node.js being a reasonable tool for the job. > Java is both considerably more speedy for this sort of workload They're quoting 1ms latencies, that's pretty speedy. Maybe Java could do <1ms and/or support slightly more concurrent requests. How much difference does it actually make when you're already responding after 1 millisecond? > there's a significantly larger pool of high end Java server developers compared to high end JavaScript server developers Oh, I would have thought there are far more JS* folks out there than Java. > Budget and brand recognition are not necessarily in favor of node.js over other stacks. That simply helps with getting the better engineers in general. That's what I meant - them being in favour of Netflix as an employer - they aren't "Bob's Digital Agency" so they can have their pick of the litter of node devs. * I'm not sure if the "server" distinction is meaningful here - if you know JS, you know node.js - simply a matter of familiarizing yourself with node-specific APIs.
  - remon 12y ago
    I'm not sure if I agree. Responding after 1ms is not the same (or even very much related to) routing a request taking up 1ms of cpu time. Although there are a ton of nuances that make the following a small oversimplification it does basically mean that purely for routing alone you have a hard cap on 1k lookups/sec/core. And building server software in any language takes a whole different set of skills and knowledge than knowing how to build front ends. I'm not arguing one is harder or more involved than the other but they are different enough to make language and paradigm familiarity and the only real gain when moving from front-end JS to node.
    - mnutt 12y ago
      The parent (and the article) are both talking about 1ms request latencies, not 1ms routing latency.
- JDiculous 12y ago
  One more advantage of Node.js over Java is that development is much faster with Node.js.
  - gasping 12y ago
    No, just please no. Any moderately competent programmer can be productive in either Java or Javascript (+ Node.js). Javascript may help incompetent programmers feel productive because Javascript has fewer compile-time constraints but in the long run the cost of maintaining code written by an incompetent more than counteracts any perceived benefit that Javascript offers.
    - JDiculous 12y ago
      Well obviously the work of an incompetent programmer is going to increase the long run cost of maintaining code. That has nothing to do with the fact that Javascript is faster to develop in.

Terr_ 12y ago

I was doing some googling about this earlier, IIRC one of the big ones was "Good when your bottleneck is I/O, not good when your bottleneck is CPU."

remon 12y ago
I hear this more often and it is somewhat misleading. That sentence seems to imply node.js is better in terms of I/O throughput compared to other technologies, as if it's a trade off. This is incorrect and it would be more accurate to say "Good enough when your bottleneck is I/O, not good when your bottleneck is CPU.".
yourad_io 12y ago
> "not good when your bottleneck is CPU" 99% of cases, your bottleneck will be I/O. In the 1% of cases where your webserver's bottleneck is the CPU, you have much bigger problems than using a hipster ;) language: you're doing it wrong (tm) on an architectural level: (a) Your processor-intensive/long-running tasks need to be in seperate worker processes and (b) you need more webserver instances. I usually try to avoid absolute statements, but I think this may be accurate: The only CPU-intensive thing your web server code should ever do, is hash passwords.
- yourad_io 12y ago
  I shouldn't have tried to be funny on HN* . For this I apologize. Can I get a rebuttal to my points along with the downvotes, though? Is someone disputing that CPU intensive tasks should be moved off the webserver? Have you personally had experiences where your honest-to-$deity webserver bottleneck was the CPU? I'd be incredibly surprised. In most cases I'd guess you're underprovisioned and/or badly architected. * This is where we come to somberly discuss interesting things.
  - nostrademons 12y ago
    You're assuming a number of things that aren't always true: 1. Your networking pipe into the server is slow. 2. You don't have a reverse proxy in front of the webserver to buffer the slow connections. 3. You don't make decisions about what information to show the user in the webserver; your UI isn't tailored for the particular user whose request you're servicing. 4. You haven't made productivity trade-offs to move work from the developer to the computer. Google's webservers (for Search) are CPU-bound, and I can guarantee that they are neither underprovisioned nor badly architected, and CPU-intensive tasks are moved off the webserver (the total amount of CPUs for webservers is miniscule compared to the number of CPUs used for the indexing & serving system). But Google has the fastest fiber networks in the world, a massive load-balancing infrastructure, its philosophy is to serve each user only the HTML/JS that they need (to cut latency), it relies heavily on A/B tests & experimentation, and it invests significantly in developer-productivity tools so that all the bookkeeping for the last two points are done by computers rather than humans.