Are you saying I should have seen more of a difference than I actually did? Maybe I was doing it wrong, but I said it makes Node's performance look "mediocre" rather than "bad" because Node is still pretty damn fast compared to the rest of the field (also, I like Node.js a lot and use it daily).

Also, this was by no means a scientific benchmark - it wasn't a comparison of raw ops/sec, or anything like that: just the requests/sec on a few different routes (pretty close as far as implementation logic). I'm sure the chosen frameworks played into the results as well, but I'd consider that a more pragmatic benchmark anyways.

This is the sort of improvement you'd see if your program was fully IO bound.

I'm not a fan of dynamic typing, nor am I a compiler expert, but I'm pretty sure this is wrong for (at least) JS engines, which are JIT-compiled down to static machine code and which use automatic type deduction. Only when types on existing variables change all the time it would be a performance problem. If JS code is 10x slower then it's native equivalent it's probably because some slow-path is hit (too many objects created and destroyed, burdening the garbage collector, or too "dynamic code" which causes many recompiles at runtime, or code not to be compiled at all but running through the interpreter..).