How would node.js deal with it? If there was need for a lot of JavaScript processing on server side, is node.js really so fast that it can execute JavaScript, and stand a chance against more heavyveight competitors?

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers
3

Node's kind of hard to compare directly because it's a bit of an odd bird. The critical thing to understand is that yes, while JS does block, which is intended desirable behavior in the case of Node, the other half of the system is the C++ operations under the hood that can in fact run in parallel with one another. That's the reason you do almost everything asynchronously with the JS in Node. The key thing to understand is that there are two layers. You direct traffic and handle simple data structures with the JS and its blocking nature acts as a kind of auto-queuing system. As a bonus, you get to reap all the benefits of JS being an obscenely easy language to implement messaging/event-driven paradigms with. For anything that's likely to take a while, no matter what you write it in, you're best off doing that with the C++.

The point of the JS as-blocking-interface on top of that is to bury all that nasty/messy thread-handling stuff WITHOUT actually reducing you to the use of one processor only.

People are no doubt going to write some absolutely hideously performing stuff with Node out of ignorance but I don't see any reason it couldn't scale for an enterprise(ew @ terminology)-level framework and I'm personally getting more and more excited about it the more I use it (which has so far mostly been to reduce config/build complexity of a web app triple-stack of Rails, .NET and Java).

Furthermore, modern JS JIT compilers have improved performance of JS by an order of magnitude in recent years and Node is built on Chrome's V8. I'd be surprised if JS didn't at least compare favorably to Python for single-threaded speed and like Python, you can handle the architectural glue of an app with a lot less code which tends to result in things being less messy and easier to manage in terms of basic work avoidance and writing a legible, modifiable, maintainable app, where you never have to think through what should (IMO) be obvious in higher level.

How do you really measure that semi-objectively for comparison? Barring some sort of competition with massive participation to write the same app with different stacks, you can't really. I think the best you can do is look at how apps tend to behave, what the team knows best, what tools are available, and not worry about performance comparisons unless the tool in question has a rep for crummy perf across the board. In my experience, Java wins the micro-benchmark wars, but is typically a notoriously poor performer on the server-side web compared to Rails, PHP, Python and ASP.net post-MVC for basic and not-so-basic web apps that I've worked on.

That's not to say Java couldn't outperform any app in another language or that it never does. Nor am I saying I've never seen shoddily written JS, Python, or PHP. However, given the quality of your average large Java team vs. a typically MUCH smaller team of JS or Python ninjas doing a web-app of average complexity for probably less total pay (and yes I'm absolutely offering a purely subjective opinion based on personal experience because that's all that's left) I'd put my money on an app produced by a few seasoned devs with a language that can get a lot more done in a lot fewer verbs and nouns without limiting your ability to structure things.

But ultimately, what I assume you're wanting to know is whether it's okay to use it and that involves subjective concerns.

So do you like the idea of writing apps with a given language/stack design, do you like what the community's doing with it, and barring more highly specific concerns does it not suck generally at performance in 80% of obvious use-cases? In Node's case, I'd personally say yes, yes, and yes.

But if you're not really interested in how it works and don't really care for JS, necessarily, I'd stay away from it because those are the two key things that give Node value and are requirements for keeping it performant.

So far for me, it's behaving exactly as I would expect a good JS tool to. It's reducing complexity like a champ by allowing me to wrap an inherently brittle/messy process in something that's robust and legible. That right there is why JS won the undisputed place it's had in browser UI and will continue to expand as a general-use language.

Event-driven paradigms are inherently faster than multi-threaded paradigms because there is no context switching. While one "thread" is running, the rest are blocked until that thread hits a point where it no longer needs the processor (e.g. if it is waiting for a response from, say, the database). So you shouldn't be surprised if the benchmarks show that.

However, it does require that programmers know exactly what they're doing at a much lower level. If they don't release the waiting threads while the current thread is "waiting," it's suddenly going to be a lot less efficient than multi-threaded.

There is still context switching, it's just done at a much lower level for you behind the scenes.
–
RaynosJan 13 '12 at 14:03

Just noted you were speaking of event driven paradigm
–
U MadJan 13 '12 at 14:57

@dan_waterworth Probably faster than you think by an order of magnitude if you haven't been paying attention for the last four years or so. IE8, I believe is the last non-JIT browser to be published that I'm aware of. Inline funcs locked in a specific scope can actually be performance enhancing over just repeating the statements inside them now because they can be cached.
–
Erik ReppenFeb 22 '13 at 21:55