Releases: uNetworking/uWebSockets.js
v20.63.0
Faster String arguments
With research & benchmarks done by @BV-WebDev, this release introduces optimizations for methods taking JavaScript Strings. The following demo runs with 17% higher req/sec overall, entirely due to this faster String argument passing:
get('/', (res, req) => {
res.writeHeader("Hello", "There");
res.writeHeader("Hi", "On you");
res.end('Hello World!');
})
This optimization applies to Node.js 24 or later and relies on the new v8::String::ValueView.
v20.62.0
- Disables WebSocket.send V8 fastcall variant, suspected of causing issues for existing apps.
- Disables the UWS_REMOTE_ADDRESS_USERSPACE enabled in v20.61.0. There are cases where this feature is not fully implemented (such as use together with worker threads).
v20.61.0
10 years of uWS
If you are interested, there is a more detailed retrospect release post in the main repo. For Node.js we have the following changes:
- getRemoteAddress(), getRemoteAddressAsText() calls are now zero cost. This is a major performance boost for apps using these in hot paths.
- onDataV2 is a superior alternative to onData, explained in the linked retrospect release.
- collectBody is a helper function making optimal use of the new onDataV2. It allows efficient and easy collection of smallish HTTP posts into RAM, returned as one whole buffer.
- We now build AddressSanitizer binaries, available in branch
binaries-asan. These can be very useful for debugging or filing bug reports related to crashes and segfaults. To run the ASAN binaries, your Node.js invocation needs to be prefixed with LD_PRELOAD like so:LD_PRELOAD=$(gcc -print-file-name=libasan.so) node server.js - DeclarativeResponse can now do writeStatus as well as end with binary, not just text.
- Many documentation fixes.
- Support for symbol-keyed properties in WebSocket UserData.
- getRemotePort, getProxiedRemotePort.
v20.60.0
Bump lsquic
The experimental HTTP3 support is now building on latest lsquic 4.6.0.
v20.59.0
v20.58.0
Easier URL route debugging
Whenever a URL route isn't handled properly, we used to display a fatal error and terminate the process like so:
Error: Returning from a request handler without responding or attaching an abort handler is forbidden!
This was not an issue in C++ since you could easily catch what route is broken by using a debugger. This is not possible in JavaScript since you aren't debugging the C++ code, only the JS code and the error isn't coming from JS.
A simple ergonomical upgrade is to display method & URL as part of the error:
Error: Returning from a request handler without responding or attaching an abort handler is forbidden!
Method: "GET"
URL: "/this_url_is_unhandled_test"
terminate called without an active exception
v20.57.0
- Fixes a bug in uWS.getParts where returned parts were previously zero-copy references into the given buffer. These parts are now copies, eliminating potential complex memory issues which shouldn't have been be exposed to script. uWS.getParts is not a streaming parser unlike most of uWS, so I would still caution against using it (even though it is faster than all other such parsers for Node.js given small files).
v20.56.0
Streamlined cross-platform build & test
- All platforms (even Windows 😮 ) & all architectures now build using Clang, have the same build flow (build.yml) and smoke testing.
- Windows no longer requires any MSVCRT.dll, making it more portable.
- Binaries won't be updated without a passed smoke test (they run before upload now).
The entire build.yml is 42 lines now
v20.55.0
Massively improved Linux ARM64 builds
- Moving from QEMU emulation to GitHub's native ARM64 runners, we cut building times from 55 minutes to 5 minutes
- The same building flow and smoke testing is now shared for macOS, Linux x64 and Linux ARM64
- Build "scripts" are now less than 300 lines in total for the entire project across all platforms, versions and architectures

v20.54.0
Raise macOS target version to 15
- Fixes newly added Node.js 25 support on macOS.
- Removes old Linux 32-bit ARM stale binaries.


