uNetworking/uWebSockets.js

μWebSockets for Node.js back-ends 🤘- I guess this is one of the fastest BE node server foundations for both websockets and http. It bypasses the regular Node bindings and reimplements everything itself with its own optimized C++.

Summary

uWebSockets.js is a C++ HTTP and WebSocket server exposed to Node.js as a native V8 addon. The project is positioned for demanding, low-latency back-ends and is also the upstream codebase that Bun forked in 2022 to power its event loop, TLS, HTTP, QUIC, WebSockets, pub/sub, and URL routing.

What it is useful for

Engineers reach for uWebSockets.js when the default Node networking layer or higher-level frameworks leave performance on the table. The README and topic tags indicate support for HTTP, WebSockets, URL routing, a pub/sub primitive, PROXY protocol, and TypeScript. The codebase is described as standards-compliant and ships with ongoing fuzz testing, which matters for parsers sitting on the network edge. Bun's adoption of the same C++ core is the clearest signal that the design is meant to scale to production web platforms, not just demo apps. The project is Apache-2.0 licensed, and the "commercial" topic combined with the README's licensing notice indicate it is intended for commercial products, with a specific requirement that modified forks be made available under a different product name.

How engineers can use it

The README explicitly warns that uWebSockets.js is not published to the NPM registry. The only documented install command is direct from GitHub:

npm install uNetworking/uWebSockets.js#v20.70.0

After installing, the README points engineers to the auto-generated function reference at unetworking.github.io/uWebSockets.js/generated/functions/App.html and to the examples/ directory in the repo. The README itself does not include a full getting-started walkthrough beyond the install line, so plan to read the examples folder to learn the API.

A few caveats from the source are worth flagging. Because the documented install command pins to a specific Git tag (v20.70.0), upgrades require explicitly bumping that tag rather than relying on semver ranges. There is no documented browser build; the description, topics, and install path all point to Node.js back-ends only. Finally, the README's licensing note says modified forks should ship under another product name, so anyone forking the project needs to plan a rename before publishing.