The Fall of the House of Node
TJ Holowaychuk, a long-time Nodist (from a Nodist colony?) who has contributed much to Node, finally abandoned Node in favour of Go. TJ writes:
The more I’ve been working with distributed systems, the more I’m frustrated by Node’s direction, which favours performance over usability and robustness. In the past week I’ve rewritten a relatively large distributed system in Go, and it’s robust, performs better, it’s easier to maintain, and has better test coverage since synchronous code is generally nicer and simpler to work with.
TJ is right, Go generally does outperform Node in terms of JSON serialization and request routing using HTTP pipelining, although Node does fairly well when it comes to database queries (roughly at par).
Eric Jiang also writes a great post about what’s wrong with Node. In particular, Eric points out two reasons why front-end developers use Node:
- “The frontend devs can work on the backend!”
- “We can share code between the backend and frontend!”
Whatever happened to the axiom, “Use the best tool for the job”? JavaScript on the server side is NEVER the best tool for the job. The only reason people cite for using JS is that it saves them the effort of learning another language. Wow, how lazy can you be?!
Node by itself is not a sufficiently good reason. People have been creating fast, powerful server solutions for decades in languages other than JS. There’s really no rationale to choose JS.
The idea of sharing code is risible. Enterprise-level server applications are typically very large, very sophisticated, and requiring high reliability. They need to be written in powerful languages that afford you solid engineering capabilities, such as sophisticated debugging and testing, and economical maintainability (i.e., producing a code base imbued with clarity and readability and the ability to reason easily). Does that sound like JavaScript or the Go language? JavaScript and Node are notoriously difficult to debug.
Moreover, server applications are rarely tied to one set of front-end applications written in one language, esp. if the server is providing a general public-facing web service. Thus, Reason #2 is pretty weak.
You can find some excellent answers about what’s wrong with Node here. Thom Bradford’s closing remark is very apropos:
So node was great, don’t get me wrong, but I think it’s time we admitted that node has served its purpose, and it’s time to move on to bigger and better things.
Node has outlived its usefulness.
Alexandra Grant has subsequently published an excellent article about why they abandoned Node in favour of Go:
