Node.js – v20.8.1(nodejs.org)
nodejs.org
Node.js – v20.8.1
https://nodejs.org/en/blog/release/v20.8.1
14 comments
> CVE-2023-44487: nghttp2 Security Release (High)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4448...
https://github.com/nodejs/node/pull/50121/files
> /* Stream reset rate limiter. If receiving excessive amount of stream resets, GOAWAY will be sent. */
Easy to understand how that "Google thwarted 400,000,000 requests per second" CVE that was popular on here a week ago was worked around.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4448...
https://github.com/nodejs/node/pull/50121/files
> /* Stream reset rate limiter. If receiving excessive amount of stream resets, GOAWAY will be sent. */
Easy to understand how that "Google thwarted 400,000,000 requests per second" CVE that was popular on here a week ago was worked around.
Is NodeJS becoming more performant & efficient - as competition from Bun/JustJS/etc heat up?
It was already pretty performant. The issue is as always runtime type checking. For serious stuff you really want that. Also, async everything is not fun. Simple code executed in a thread pool or whatever is so much easier to reason about.
Worker threads have been around for a bit:
https://nodejs.org/api/worker_threads.html
https://nodejs.org/api/worker_threads.html
yes and slow AF. also nobody is gonna use worker threads without async to handle API requests in NodeJS - why would you use nodejs then?
> Simple code executed in a thread pool or whatever is so much easier to reason about.
reply
Hard disagree. It's much easier to reason about async await because you don't need to worry about preemption. You (generally) don't need mutexes or anything like that.
Hard disagree. It's much easier to reason about async await because you don't need to worry about preemption. You (generally) don't need mutexes or anything like that.
hard disagree. :)
When do you have to worry about synchronization? You don't. Pull DB connection from pool, etc, done.
Async await has colored functions, promises, and other atrocities.
Even if I have some locking primitives somewhere I'll GLADLY take that over the fucking mess of async stack traces and code executed "next tick" with no trace.
When do you have to worry about synchronization? You don't. Pull DB connection from pool, etc, done.
Async await has colored functions, promises, and other atrocities.
Even if I have some locking primitives somewhere I'll GLADLY take that over the fucking mess of async stack traces and code executed "next tick" with no trace.
Performant in what sense?
as in easy to handle tens of thousands requests a second with a few DB calls on a smallish server? do you want a PHD thesus on what performant means?
Node JS caps at less than 10K RPS...
oh what machine? with how many workers? doing what?
search for "node" on this page: https://www.techempower.com/benchmarks/#section=data-r21
search for "node" on this page: https://www.techempower.com/benchmarks/#section=data-r21
Rather than searching "node" on TechEmpower I do my own comparative benchmarks in a given environment.
Node always loses. Every time. To everything. It reliably loses to Java, Python, and even other JavaScript engines. Which is why I asked... performant compared to what?
Node always loses. Every time. To everything. It reliably loses to Java, Python, and even other JavaScript engines. Which is why I asked... performant compared to what?
Express, on Linux, with one worker because that's how you benchmark apples-to-apples. Node 20, with plenty of RAM and CPU, not that it uses it.
Shameless promotion time, I have a little utility that can check a node version for CVEs or EOL:
Or with docker:
Some highlights of the tool is zero dependencies and CVEs are sourced directly from NPM changelogs instead of waiting on slow CVE release processes. See the website for more details: https://www.github.developerdan.com/node-version-audit/