Node.js is cancer 2, boogaloo

Riccardo Cagnasso
5 min readApr 30, 2019

I deeply hate Node.js.

The main reason why I hate this framework so much is twofold. I like javascript very much and I like/need things that software written in node.js does.

The careful reader will now think: “Hey, these are positive things, shouldn’t they mean that you like node.js?”. Well, yeah, they should. The problem is that Node.js is cancer. Or, maybe, a virus that will infect and horribly mutate everything it comes in contact into a slow, overgrowth blob of death.

If you read this, you probably know that there is a famous article, which is basically completely incorrect. It points out against the application server / transparent proxy architecture, which is actually quite functional, adopted by non-cancerous frameworks like python’s pyramid and definitely simpler that convoluted *GI architectures. The author, like others, also indulges in the Javascript Is a Bad Language and Real Men Don’t Write Web Stuff tropes, which is annoying.

So, why Node is cancer?

The most basic answer to this question is that the Node ecosystem lacks any basic level of skilled maintenance and optimization. To demonstrate this, I will clone a fresh repository of a small new Ember project that I just started and barely contains any code, let alone feature, and npm install.

(o35) [phas@vostok globi-muma]$ npm install
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.8 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.8: wanted {“os”:”darwin”,”arch”:”any”} (current: {“os”:”linux”,”arch”:”x64"})
added 1088 packages from 577 contributors and audited 64379 packages in 17.961s
found 1 low severity vulnerability
run `npm audit fix` to fix them, or `npm audit` for details

I could actually end this article here. Instead, I will throw a funny and not entirely on-topic comparison. How many packages the Archlinux installation on my laptop has? 1910. A whole operative system, three years old, used by a person that do a wide variety of jobs and experiments, with full stacks for programming in, at least, four languages and enough bloat that I’m seriously thinking about reinstalling the whole thing from scratch because it’s a mess. It has not two times the number of packages of a fresh Ember installation.

But let’s take a look inside those one thousand-odd packages, shall we?

This is the first time I see cloc actually giving up.

Two millions lines of code. In “I don’t have time to count or grep/sed/awk/wc” how many languages. And what in all that is good in the world is Moustache? There are 5000 locs in shader language for something that basically amounts to a small web server, a skeletal frontend framework and some glue that keep the two things together.

Some people say that this might constitute a slight security issue since it is virtually impossible to even begin to audit this… thing. I feel that those people miss the more obvious threat to the mental sanity to everyone that comes in contact with this monstrosity.

An ecosystem too young

Why does this happen? Me, I don’t know and certainly, I don’t want to investigate too much, lest I lose my fledgling sanity. But I can speculate.

Node.js is young. Insanely young for a programming platform. Python is 30 years old. Ruby is 24 years old. Node.js is 9.

This matters because, you see, computer programming is a lifetime learning experience. When you are a kid you learn what is an “if”. Then you play with your first programs. Then you go to university and learn about algorithms and structures. Then you understand how to use software libraries, reuse code, how this is a good thing and let you do much with less. Then you learn how to manage a big codebase and pay the rent with the money you earn. Finally, you get old and boring and bored and you learn how to manage those damn dependencies.

Do you remember the first time you tried to commit a new feature to an open source project? Do you remember that odd guy that came yelling at you, closed the merge request and banned you in a fit of rage because HE REALLY HATES NEW FEATURES! That kind of guy, oddly enough, is the one that you need to properly maintain a codebase.

Node.js had a big “boom” and everyone got on board and a kilometric megaton of young developers rolled up their sleeves and started to write the code that they needed. You don’t get powerful and feature rich ecosystem in a handful of years by carefully optimizing, lovingly maintain and painstakingly remove dependencies one by one.

Problem is that you don’t get a sane one without doing it.

Why is this a problem?

Let aside security issues. I mean, who really cares about security issues, right? Most programmers don't really understand computer security anyway.

What happens when I try to compile my barebone application that serves a single mostly empty page, from a codebase that uses 1000 libraries?

[phas@vostok globi-muma]$ ember s
Could not start watchman
[ … removed bloat …]
Build successful (8160ms) — Serving on http://localhost:4200/

Oh, nice. Eight seconds. I never wrote in my whole career as a computer programmer a routine that takes eight whole seconds to do something that is not pulling some hundreds of thousands of records from a database and writing them somewhere.

But it’s still manageable right? It’s just eight seconds and then you have cache, selective compiling, whatever. Yes. But put this thing into an electron application, use Atom.io to work on it, add some big static files, throw some general lack of optimization, like ember-electron copying unmodified static files every time you package. Now in my office, I have a 2000 bucks Xeon workstation with 32GB of ram and NVME storage. And I’m pissed.

Also, try to take something that you have written a couple of years ago and npm install in it. It won’t work. In theory, dependencies are all version locked by default, which is very very bad but should keep a program working through the years. In practice, some of that 1000 packages will be missing, corrupt, purged because infested, conflicting or god knows what.

Why should I care?

I don’t really like Ruby's syntax, and I have a simple solution for that problem: I don’t use Ruby. Why should someone be concerned if Node.js is cancer instead of simply not using it?

The problem here is that there’s a lot of useful software written in Node.js that doesn’t really have alternatives. You don’t get to be even half decent at programming if you don’t have a somewhat disturbing fetish for consistency. This means that a lot of good programmers with good ideas will flock to Node.js like flies to the UV light when javascript is heavily involved.

I started this article with Ember and it’s still a good example. You can’t find a modern lightweight frontend Javascript framework not based on Node. ExtJs is Java based but is not even remotely lightweight. Similarly, I can’t find a lightweight, Node.js free, alternative to Electron.

Most worryingly, the whole “new generation” text editors scene was swallowed by the node-electron nonsense. You basically have Sublime, which is great but nonfree and somewhat lagged behind, TextMate if you use Osx only (who does?), Atom.io and a million clones of the latter. Even Microsoft, of all people, couldn’t keep themselves to dabble in this idiocy.

Conclusions

Node.js is cancer.

--

--