NodeJS isn’t cancer (more like a bad case of food poisoning)

Recently at work I got involved in a somewhat lengthy (and at times a little heated) discussion about the efficacy of Node.js being introduced into our stack. 

For context, our application consists of a few disparate components: a kernel of applications written in C/C++/assembler, then a huge mass of mostly Python (654,852 SLOC according to sloccount) to handle everything of core system administration to the web. There is considerable Python expertise in-house; at one point we even employed core Python committers. Our build and test rigs use Python. One of my projects, converting the internal network applications to virtual machines, makes heavy use of libvirt’s Python API. There is more Erlang in production than Javascript. 

Naturally, for the next iteration of the web side of the application, a completely from-scratch rewrite using Node.js makes the most sense, right? Of course it does. At least, that’s the argument I lost. But I’m not bitter[1].

But! I’m an adult, and so I’m aware that I either do my job or find a new one. I think the AR15 platform is a piece of shit but I didn’t really waste any time yelling at the Marine Corps that there’s lots of better ways to kill bad guys, I just did my best to keep mine clean and my proficiency at peak. (Also, we’re talking about a prototype here; we have nothing to lose and everything to gain. If it doesn’t work, no problem, we have other directions to go. If it does work, our application is that much better.)

So to prepare for the clusterfuck^Wgreat leap forward in our application, I’ve been spending some quality time with Node.js. The original Node.js rant, “Node.js is cancer”, is no longer on the web, sadly. You can find other rants elsewhere; my current favorite are on Youtube, here and here. (“You may recall sequential code; that’s the code you can read.”)

I’ve found a few things about Node that I really like, though.  It’s not all cancer.

Fun Thing The First: Modules Are Pretty Great

I really, really don’t miss modeling everything as a class. Maybe I’m just bored of OO, but organizing code by gross function feels much more natural and easy these days. I’m sure over the long run it’ll lead to tears[2] but right now it’s very pleasant to work with.

Fun Thing The Second: The Real Deal On One True Platform

One of the holy grails of web work is that you can do all your real work in one platform. For most of history, people talked about the “web stack”. Oh, it was a stack alright; a stack of fecal matter. It was perfectly reasonable to have in one medium-sized web application a set of technologies like:

  • HTML
  • JavaScript
  • CSS
  • Some sort of scripting language (Perl, Python, PHP, Ruby) for core logic
  • SQL
  • Shell scripts
  • Probably another scripting language – perhaps 2 or more – driving all the tangential parts (sysadmin, deployment, back-end services, etc etc)
  • And if you’re lucky, something compiled, like a C library/extension for one or more of your scripting languages

I’ve seen people suffer from horrible task switching: one time a coworker spent over an hour typing what amounted to Perl into a PHP file, because he’d spent the first part of the day fixing a perl script. He went right into the next task and his brain didn’t come along. We’ve all done it.

I’m pretty sure Node.js comes very close to fixing this. Throw in a NoSQL database and you don’t even need to worry about SQL! The worst case is the odd shell script here and there. 

JSLint provides a fully automated dunce-cap to keep the stupid down 

Thanks to jslint you can pretty much punch anyone in the neck who tries to do something really stupid. If you are some sort of “all Node.js, all the time” and your code doesn’t at least mostly clear a reasonable set of jslint settings, congrats! You’re awful.

It’s not cancer but I’m pretty sure it’s a lot like having food poisoning

I’m immensely frustrated with Node.js. To name but one example, everyone insists on making everything a motherfucking EventEmitter despite Node.js shipping with fully synchronous functions. Yes, the core library ships with not even remotely asynchronous functions. Why? I don’t know, maybe the core team realized sometimes it’s just easier. This logic never filtered out to the great npm-famous masses, so every time I grab a simple library for doing anything, I’m on column 120 before I get to the heart of the matter.

Moreover, I feel like I’ve been sold a bill of goods when I see 3/4 of the README dedicated to hooking up the application to memcached and Redis. Node.js is scalable, please pay no attention to the 40 proxies, key-value caches, and other doodads actually keeping the application running.

But whatever. At the end of the day, every large web application requires all that stuff anyway so perhaps building it in from the start to serve the 5 people using your application is actually the right choice.

It’s probably worth it, if Node.js can truly deliver a smaller “stack”; given the size and complexity of our system, it may end up that we can iterate faster by not having to context-switch. Moreover lots of really talented people are working on making Javascript better; Python in stuck in that weird place of “we’re not porting our library to 3 until there’s a critical mass of users/we’re not switching our app to use 3 until everyone ports their libraries to it”. That in and of itself should give any reasonable person The Fear(™); Node.js and Javascript aren’t going anywhere any time soon and to its credit Node.js has been very out in front of “this API is stable” stuff.

So no, it’s not cancer, but it gives me a lot of occasional irregularity. 


[1] Haha, I’m lying, I’m insanely bitter.

[2] I imagine code reviews thus: “What the hell is this code doing here?” “Because fuck you, I was in a hurry.”

4 thoughts on “NodeJS isn’t cancer (more like a bad case of food poisoning)

  1. I think this choice depends a lot on what your final product intends to be, and how many people are really going to use it. I see an advantage in asynchronous code when content gets delivered faster, and without blocking resources (obvious statement).
    Apart from that, you’ll probably be benefited by reducing the number of languages included in the app.
    Oh, and here’s a nice code tester: 😛

  2. Food poisoning is about the quality of 3rd party modules. With my own experience projects usually end up replacing many installed npm modules with just the functionality what it requires, and this is what the “same context” thing enables… double blade IMO. =\

    1. I like it. The team is very happy with the design and it has not let us down. That said, I’m using Pyramid for the next big thing, instead of Node, because the requirements are vastly larger and I’m not sure Node can really deal with everything. I know Python can.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s