Skip to content

Instantly share code, notes, and snippets.

@Raynos
Created November 19, 2011 18:17
Show Gist options
  • Save Raynos/1379163 to your computer and use it in GitHub Desktop.
Save Raynos/1379163 to your computer and use it in GitHub Desktop.

Common concerns about node

It's not even version 1 yet

So what? Version numbers matter these days? All software I realise never get's upto version "1".

Node.js is stable and it's a shining example for asynchronous IO using javascript.

Socket.io is stable and the best cross platform websocket abstraction I've seen. You want to use websockets in production today? Use socket.io

There's no real multi-tasking

That's a lie. Node.js does asynchronous IO. That means all IO is automatically parallelised. If you make 10 HTTP requests in asynchronously then all 10 will run in parallel. The fact that javascript is single threaded is being worked on.

Currently we simply run multiple processes (node --cluster will run your process n times with a small load balancer in front of it). There is work being on done on exposing threads through v8 isolates for 0.8 (january).

I will agree that it's far from ideal. There are other superior languages, like Erlang. But that's a massive learning curve. And it simply doesn't have the community effort node has. Wish it did.

Why wait for the database when it takes just .001 second, there's nothing to gain

Of course there is. Do you really think those million nanoseconds couldn't be put to better use? That's a couple of million cpu cycles your wasting sitting on your ass. If you really want to scale you can't afford to waste cycles like that.

The asynchronous style makes software so much more complicated

Misconception. Node isn't more complex. It's different. And if you attack from a generic synchronous mindset yes it is more complex. I'm afraid you'll have to learn callbacks and how to do it elegantly.

<insert standalone phrase> they are not your bottleneck

Every single blocking operation is a bottleneck. The operation with the maximum latency is your server bottleneck. If this is 1ms then your stuck to 1000req/s. If this is 100ns your stuck to 10k req/s.

But it's not for real-time applications. It's not for hardcore processing or big calculations.

Correct, it shouldn't be used for hard real-time applications. But you shouldn't use the web for hard real-time applications. It shouldn't be used for hardcore processing or big calculations, but hey you have the database for that, and failing that it's easy to plugin C++ into v8 and expose it to your scripting language (js).

However for soft real-time applications, and that's what we mean when we talk about real-time on the web, you need reduced latency. Node & socket.io are very good at reduced latency.> That is an extremely complicated and hard to debug process.

Only if you don't know what your doing. However the platform and tools have not hit the maturity of say Java yet. It's more difficult, but your overstating that difference in difficulty.

you will simply get tired of mocking.

I write unit tests every day for node.js. And I'll tell you now that since javascript is a flexible language they are easier to write then Java or C# or any other unit tests for any other platform I've used.

It's difficult enough in browser. How much more difficult could it be in server-side app

What are you even ranting about? JavaScript on the browser is difficult because of cross platform support and browser bugs, not because JavaScript or the host objects are hard.

And with node, the host objects are simpler.

It simply has nothing to do with real-time applications and parallelism

Hard real-time, no. Soft real-time yes.

As for parallelism, well non blocking IO gives you it for free. And then node --cluster gives you a ton more parallelism for free. Mind you, whether you should be using it in production completely depends on how skilled you are with node & javascript.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment