Node Sucks

An objective analysis of Node and why developing with it sucks.

A High Level View Of Node's History And Architecture

Node's Origin In Google Chrome

The node engine is simply the program that processes javascript inside Google Chrome. This engine is known as V8. V8 runs in a single thread in Chrome but is built to handle asynchronous calls to outside websites.

How does V8 Handle Asynchronous Calls?

Normally a javascript thread is expected to run from start to end without interruption. The browser actually will freeze while this is happening, meaning that it will not change anything else it displays while this javascript thread is executing. In windows the browser window can be dragged around but the behavior inside the a browser tab is locked down and will not respond to events until a javascript thread completes. This single threaded behavior generally suits the user fine, until that javascript thread launches a call to another server in the middle of the current thread. When a call to another server is launched mid stream, and the developer expects the thread to continue, while the round trip to a server is made in parallel, the behavior is called asynchronous.

Unlike java, V8 cannot actually run threads in parallel, so it simulates parallel behavior by putting the side call (async call) in a queue, which it will pay attention to when other threads have completed. The developer can specify certain code to be called when this "side thread" is completed. This specified code is referred to as a callback. Callbacks allow information being returned by a side request to be processed if and when the call comes back. This is the original origin of the simulated multi-threaded behavior in javascript engines. Keep this in mind when reading more about Node below, because the implications of this are huge. Callback implementation is actually dirt simple and many developers do not understand this simple mechanism and therefore think of callbacks as some kind of magic. Yes, you can call them Promises or Promise chains, but in the end its just a queue of things waiting to happen when 1) The single javascript thread is available and 2) A callback condition is met.

What Is Node?

Node is what happened when Ryan Dahl decided that it would be a great idea to use this javascript engine outside of Chrome, and to even use javascript for a web server. Shortly after NPM a package manager for Node was created to pull in libraries. This unfortunately is where the crapfest began mostly based on very illogical conclusions and a lot of "I want to be special" sentiment.

Node Sucks As The Following Points Show

Attacking Node is probably not the greatest career moves these days. Node has become a cult, and naysayers are generally sacrificed on the unemployment line. Being near retirement age, and hopelessly objective, I'll take my chances by speaking some truth. Read the following points and decide for yourself.

  1. Java is as solid as rock and way easier to maintain than Javascript, or God forbid Typescript

    Look, I love Javascript for doing little things, client side, like making async calls, and changing screen colors, and validating input. The lack of strict typing is quite convenient because you don't have to worry as much whether a user typed a character or a number a lot of the time. Much of the time, you are just relaying characters to the server. Furthermore, script languages are nice because you can simply refresh your page to see your new code run rather than having to compile and create artifacts which then need to be deployed. Yet, Javascript is not a language you want to maintain a million lines of code in because it breaks at runtime, not compile time, meaning that avoiding mistakes is much much harder, so it is best to not write a large stack in it. Server side code is by definition quite deep so I have no idea why Ryan wants to write server side code in Javascript. Maybe he eats lettuce with a spoon too?

    For this reason Node people like to use Typescript, a super set of javascript. However, no one can tell me that Typescript is strict enough that it is on pare with Java for catching compile time errors, because from experience it simply is not. Typescript is an approximation of a typed language. Keep in mind that Typescript is transpiled into Javascript before running on the browser and that tells you all you need to know about its stability at "compile time". The fact that Typescript needs to be compiled also means that it is not a "script" language because one of the biggest advantages of script languages is that it is interpreted, enabling one to skip the compile step.

    Typescript syntax has to be one of the worst crapfests I have ever seen. Its not java, its not javascript, and there are about 100 different ways to do everything. Its a very ugly esoteric language that is hard to learn and an invitation to create code sphagetti ... with meatballs.

    So to summarize, coding a server in Node requires the developer to maintain a huge stack that is either a script language, or a language that isn't really a script language, and both are way less maintainable than Java. Why do this to yourself?


  2. NPM Is A Horrible Package Manager/Environment

    Java uses a package manager called Maven, and its pretty solid. Node instead uses a package manager called NPM, which has been superseded by a package manager called Yarn, which is faster but still not "fast". Unfortunately, Javascript doesn't have a standard library like Java or Python so the entire foundation of an NPM build is open source meaning that it includes 1000's of independent dependencies. This makes the entire environment inherently unstable. Anyone who has worked on a large Node project can tell you of the constant maintenance of a dependency chain that is constantly breaking either because of actual signature changes or because of security issues. Change one library version because of a vulnerability discovery (which often happen weekly) and frequently many other dependency versions will need to be changed manually. Yes, I said manually, manual trial and error... have fun.

    In addition to being unstable NPM/Yarn builds, on large projects, can take a very long time. Even on the latest greatest PC I have seen a full build take from 30 minutes to an hour, and the node modules produced (a type of compressed library) will be Gigs in size. If you need evidence download a large open source node project like Spotify's Backstage. I recommend making sure that no flammable materials are close to your PC during this build, especially if your PC is a Macbook. Node builds are notorious for being heavy. The Node community jokes about this regularly. For example: Heaviest Objects in the Universe. This is just hilarious until there is a production issue and millions of dollars are lost, because it takes an hour to bring production back up. For reference, I have never seen a java project taking longer than 60 seconds to build on a modern machine, and I have been on some enormously bloated monolithic applications.


  3. Leaving Multi Threading Up To Individual Developers Is A Terrible Idea

    Keep in mind what I previously explained about simulated multi-threaded behavior in Javascript engines. Originally this callback queue mechanism was created to allow parallel async calls to be kicked off without making the Javascript thread have to pause synchronously, to wait for the callback to complete.

    When using Node as a server it is imperative that one process does not hog the whole server to itself. However, in order to do this the Node community insists that all subroutine calls should be handled as callbacks. It is up to the developer to do this. This is done by calling a subroutine through a Promise (just a type of callback notation) and then preventing the calling thread from behaving asynchronously (keeping it from continuing in parallel) by calling the subroutine with the await syntax. So we call the subroutine in an asynchronous way but then block asynchronous behavior to allow the server to process other threads. What a hideous hack this is! Even worse it makes the health of the entire server dependent on developers coding in such a way that the server will be able to time slice other threads. This is a total recipe for disaster and the thing that sucks the most about Node.

I hope this has deprogrammed or at least enlighted someone. Below are some more links that might be helpful.

Links to more information

Contact Us

 If you have questions about WebRocketX, please feel free to contact us at: