3 ms·
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
by 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 agoI'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 agoThe parent (and the article) are both talking about 1ms request latencies, not 1ms routing latency.