Node.js is not for me (and why)

January 16, 2015

I've been aware of and occasionally poking at node.js for a fairly long time now, and periodically I've considered writing something in it; I also follow a number of people on Twitter who are deeply involved with and passionate about node.js and the whole non-browser Javascript community. But I've never actually done anything with node.js and more or less ever since I got on Twitter and started following those node enthusiasts I've been feeling increasingly like I never would. Recently all of this has coalesced and now I think I can write down why node is not for me.

(These days there is also io.js, which is a compatible fork split off from node.js for reasons both technical and political.)

Node is fast server-side JavaScript in an asynchronous event based environment that uses callbacks for most event handling; a highly vibrant community and package ecosystem has coalesced around it. It's probably the fastest dynamic language you can run on servers.

My disengagement with node is because none of those appeal to me at all. While I accept that JavaScript is an okay language it doesn't appeal to me and I have no urge to write code in it, however fast it might be on the server once everything has started. As for the rest, I think that asynchronous event-based programming that requires widespread use of callbacks is actively the wrong programming model for dealing with concurrency, as it forces more or less explicit complexity on the programmer instead of handling it for you. A model of concurrency like Go's channels and coroutines is much easier to write code for, at least for me, and is certainly less irritating (even though the channel model has limits).

(I also think that a model with explicit concurrency is going to scale to a multi-core environment much better. If you promise 'this is pure async, two things never happen at once' you're now committed to a single thread of control model, and that means only using a single core unless your language environment can determine that two chunks of code don't interact with each other and so can't tell if they're running at the same time.)

As for the package availability, well, it's basically irrelevant given the lack of the appeal of the core. You'd need a really amazingly compelling package to get me to use a programming environment that doesn't appeal to me.

Now that I've realized all of this I'm going to do my best to let go of any lingering semi-guilty feelings that I should pay attention to node and maybe play around with it and so on, just because it's such a big presence in the language ecosystem at the moment (and because people whose opinions I respect love it). The world is a big place and we don't have to all agree with each other, even about programming things.

PS: None of this means that node.js is bad. Lots of people like JavaScript (or at least have a neutral 'just another language' attitude) and I understand that there are programming models for node.js that somewhat tame the tangle of event callbacks and so on. As mention, it's just not for me.

Comments on this page:

By Chris at 2015-01-18 17:29:02:

The JavaScript community is realizing that callback hell is a thing (see, even,!), and is working to address it. Through features like promises and libraries like async and Q, JS is addressing the issue of callbacks adding a lot of complexity. If for no other reason than the fact that it's another way to think of doing async, I'd take a look at how ECMAScript 7 (yes, 7; the committee is designing both versions 6 and 7 at the same time, with the idea that they can plan for version 7 with what's going into 6) is working to make async easier.

Your other points are entirely valid, though, as is your choosing Go as a better fit for solving your problems. I just wanted to point out that JS hackers are aware of the problems with its async model and are working toward making it suck less.

By cks at 2015-01-18 19:10:01:

I should have been more clear in the entry: I think that both asynchronous event based programming and callbacks are bad ideas. Even if node moved to promises and similar things, my understanding is that it would still be left with a fundamental event based asynchronous programming model where you could not write straight line code that would execute concurrently with other of your code (and where doing anything that was actually synchronous would still be extremely dangerous).

Written on 16 January 2015.
« Using systemd-run to limit something's RAM consumption on the fly
Limited retention policies for email are user-hostile »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jan 16 23:06:08 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.