Deno: What I hate about Node.js

Created on 6 Jun 2018  路  15Comments  路  Source: denoland/deno

Hello there Ryan,

I randomly came across your talk on what you regret in Node.js.

I have a handful of opinions of where Node.js fails miserably, they are all performance related since Node.js is horribly slow at most tasks except for maybe a few corner cases where it manages to perform 1x the perf. of other servers. Mainly because it hits the Linux kernel max throughput.

I've been working with (or should I say against) Node.js for 2 years doing perf. work and the most obvious flaws are listed here:

  1. You spent too much time on low level C-code and way too little time optimizing the V8 <-> C calls. Node.js does about 5-10x fewer HTTP req/sec for small responses than what it easily could pull off if you didn't jump back and forth between JS and C and JS and C all the time. There is a significant cost jumping the fence and Node.js wrappers around V8 adds more than 200% overhead to that.

  2. Everything in the node:: namespace is horrible. ArrayBuffer is extremely much faster than Buffer, V8 native function calls are extremely much faster than the node wrappers. I boosted my server throughput 100% by swapping from passing data from C to JS via node Buffer and to using ArrayBuffer. This shows how horribly miserable the perf. control is within Node.js.

  3. libuv is a miscarriage of a networking stack and fails to properly represent the underlying operating system. It requires tons and tons of memory and does not even have SSL support. This leads to Node.js having to implement SSL which only increases the complexity and the size of the pit which obviously is going to be fallen into. You can read more on libuv failures here: https://github.com/uNetworking/uSockets. Mainly libuv fails to recognize Linux is a reactor pattern operating system.

  4. Native addons never caught on, and instead people started to write everything as JavaScript modules and NPM exploded with the most rotten, horrible code man kind ever saw. Socket.IO, Express.js and other such "core" modules became the standard and nobodoy cared to ever check just how intense the performance loss was. Socket.IO alone has a 200x (not 200%) performance loss over what you easily can achieve with native addons. Node-gyp is a disgrace to humanity and completely pointless. Writing core modules in JS is the worst possible idea -> JS is a script and should only be used to write business logic, not data base drivers and realtime libraries, etc. You can read more about the failure of NPM modules here: https://github.com/alexhultman/The-Node.js-performance-palette

  5. I will post this in next comment, I just wrote these points in a hurry. They are the most significant ones though.

  6. You need to benchmark! Benchmark everything all the time. Node.js has never been benchmarked against anything modern. People say that Apache is C and Node.js is faster than Apache thus JavaScript is faster than C. Apache was written in 1993 for a completely different era of networking. Benchmark against any modern C server and you'l find easily 5-10x the performance difference for smaller sends. Heck modern C servers outperform Node.js 4x even when using SSL and Node.js only doing TCP.

Most helpful comment

@alexhultman I believe you may have filed this ticket against the wrong project? It seems that your concerns are with Node, not deno. I suggest closing this ticket and opening one up on https://github.com/nodejs/node.

All 15 comments

@alexhultman I believe you may have filed this ticket against the wrong project? It seems that your concerns are with Node, not deno. I suggest closing this ticket and opening one up on https://github.com/nodejs/node.

@jeremyckahn I do not need any help from you thanks. This is aimed towards Ryan

Then why not send an email instead of filing an issue in an unrelated repository?

You need to benchmark!

I believe this is the point.

@FrankFang @alexhultman I agree that more benchmarking is always helpful, but being that this is an open source project, you (as well as anyone else) are free to also contribute such benchmarks. Unless there is some sort of contract or agreement with the project author, implying that they have a responsibility to do anything specifically with it is a little unfair, IMO.

It appears that this project is accepting Pull Requests!

@jeremyckahn That's a very naive view. You simply cannot fix a broken design by "contributing" to it. Design is design and something you do once and have to live with. Just look at how Node.js went with and now it's too late to ever fix with a simple PR. Design involves interfaces, not just code so it cannot be fixed in hindsight. Hence the entire point of this project. Hence the relation to Node.js.

Your infallible logic can be applied to Deno itself - why create yet another Node.js? As far as I know Node.js has a PR button too.

@alexhultman I agree! Some problems are hard to fix with just a Pull Request. However, they become even harder to fix when tickets include rebukes such as "Everything in the node:: namespace is horrible" and "Node-gyp is a disgrace to humanity."

I appreciate the time you've taken to articulate your concerns, but I believe that there are more constructive ways to solve these issues! I would suggest focusing more on the objective design issues and offering specific ways to improve them (ideally with sample code or documentation), rather than subjective opinions about them.

@jeremyckahn I don't care what you think, I directed this to Ryan. I don't take suggestions.

馃檮

I would suggest focusing more on the objective design issues and offering specific ways to improve them (ideally with sample code or documentation), rather than subjective opinions about them.

You never read my post obviously. None of this is _subjective_. I posted problably the mosty thorough benchmarking results anyone has ever done for HTTP/HTTPS in my very post. Including design documents, code, and motivation. Are you serious? Subjective! It cannot be any more objective than what I posted.

Let us not forget that criticism of Node.js is what spurred Deno in the first place.

@dsamarin :clap: :sparkles: :tada:

Please keep radio silent

https://github.com/ry/deno/issues/94

That's a lot of Ryan's in here. Or wait, _none_ of you are Ryan.

Closing and trying over mail instead. Maybe I should have known there would be a lot of Node.js fanatics in this repo - thought those would be gone since this repo is essentially a middle finger to Node.js. I was wrong.

Issues like this just create new notifications, focus on the new approach and project. If you want to express something, send an email to ry

Was this page helpful?
0 / 5 - 0 ratings

Related issues

watilde picture watilde  路  3Comments

kyeotic picture kyeotic  路  3Comments

benjamingr picture benjamingr  路  3Comments

ry picture ry  路  3Comments

ry picture ry  路  3Comments