# uWebSockets.js: A C++ Web Server Exposed to Node.js as a Native Addon > uWebSockets.js is a standards-compliant HTTP and WebSocket server written in C++ and exposed to Node.js as a native V8 addon. It is fast and permissively licensed, but it is not in the npm registry and it is not a framework. **uNetworking/uWebSockets.js** — μWebSockets for Node.js back-ends :metal: - Repository: https://github.com/uNetworking/uWebSockets.js - Stars: 9,160 · Forks: 624 - Language: C++ - License: Apache-2.0 - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/unetworking-uwebsockets-js ## The problem uWebSockets.js solves: a C++ core under a Node.js API Node.js back-ends that need both HTTP and WebSocket handling usually stack a framework on top of a runtime, and the framework becomes the performance ceiling. uWebSockets.js takes the other route. The README describes it as a standards-compliant web server written in 10,000 lines of C++, exposed to Node.js as a native V8 addon. The audience is engineers who want the ergonomics of JavaScript handlers without the framework layer underneath them. The repository topics list nodejs, typescript, http, websockets, router, pubsub and proxy-protocol, which maps closely to what the example files cover. It is not a general application framework and it does not pretend to be one. If your team's mental model of a Node server is app.use(...) with a chain of middleware, this project will feel like it starts one level lower. ## How the addon, router and pub/sub fit together The architecture visible in the repository is a C++ core with a thin JavaScript surface. The src/ directory holds the addon, the uWebSockets submodule holds the upstream C++ library, and build.c plus the Makefile drive the native build. On the JavaScript side you create an App, register routes on it, and call listen. The examples directory shows the shape of that surface: Router.mjs for routing, PubSub.mjs for topic-based broadcast, Upgrade.mjs and UpgradeAsync.mjs for the WebSocket handshake, Broadcast.mjs for fan-out, Backpressure.mjs and SlowReceiver.mjs for flow control, and GracefulShutdown.mjs for shutdown. Routing lives in the core rather than in a JavaScript matcher, which is why the topics list includes router. Pub/sub is likewise a first-class concept, not a library you add. The data flow is the same as any HTTP server: a socket accepts a request, the core parses it, your handler produces a response. The difference is where the parsing happens. One consequence worth stating plainly: because the addon is native, its behaviour is tied to the Node.js ABI and the platform, and the README's install path reflects that. ## Installing uWebSockets.js from GitHub and serving a first route The README is explicit that the package is not in the NPM registry, and gives the install command against a GitHub tag. Note that the documented example pins v20.70.0 while the most recent release listed is v20.71.0, so the tag you type is a choice you make rather than a value the README keeps current. ```bash npm install uNetworking/uWebSockets.js#v20.70.0 ``` After that, the README points to the examples directory for runnable code, with examples/HelloWorld.mjs as the minimal case: create the app, register a route, listen on a port, and write the response. The repository root also carries a Makefile whose default target compiles build.c and runs the resulting binary, which is how the native addon is built from source. ```bash git fetch origin binaries:binaries git checkout binaries cp dist/*.node . ``` Those three lines are the Makefile's upload_host target, the maintainers' manual path for moving prebuilt .node binaries onto a binaries branch. For an application developer the practical equivalent is pinning the GitHub tag in package.json and letting the native build run on each target platform. Beyond that, examples/Router.mjs shows parameterised routes, examples/PubSub.mjs shows subscribing a WebSocket to a topic and publishing to it, and examples/JsonPost.mjs shows reading a request body. The generated documentation linked from the README is the reference for the full App API. ## Where uWebSockets.js is the wrong choice The most concrete limitation is distribution. The README states the project is not in the NPM registry, so a dependency on it is a dependency on a GitHub tag, and your lockfile records a git URL rather than a registry version. That changes how you audit, mirror and vendor dependencies, and it means the usual npm provenance tooling does not apply. The second limitation is the missing framework layer. There is no middleware chain, no view engine, no batteries. Everything above routing, pub/sub and the WebSocket handshake is yours to build. The third is the native addon itself: a C++ core compiled against Node.js means platform and ABI are part of your deployment matrix, and the Makefile in the repository root is a small build script rather than a cross-compilation pipeline. Finally, the README's licensing section is not the plain Apache-2.0 text you might expect. It says source code is licensed Apache License 2.0, and in the same block states 'Intellectual property, all rights reserved' and asks that modified forks be made available under another product name. If your legal review treats permissive licences as interchangeable, that paragraph is the one to read first. ## uWebSockets.js compared with ws and Express The comparison people search for most is against ws, and the difference is scope. ws is a WebSocket implementation that runs on Node's own HTTP server; uWebSockets.js replaces the HTTP server as well, with the C++ core handling parsing, routing and pub/sub before JavaScript sees anything. If you already run Express and only need a WebSocket endpoint, ws plugs into that server and uWebSockets.js does not. The Express comparison is similar but sharper: Express is a middleware framework whose value is its ecosystem, and uWebSockets.js has no equivalent layer, so choosing it means giving up that ecosystem deliberately. Against Fastify the README makes a performance claim, citing 13x faster than Fastify in the v20.71.0 release notes, but that number comes from the project's own release announcement and should be treated as the project's claim rather than an independent measurement. The Bun comparison is different in kind: the README states that since 2022 a fork of µWS has carried Bun, and is responsible for its event-loop, TLS, HTTP, QUIC, WebSockets, pub/sub and URL routing. That is a statement about code lineage, not about which runtime you should use. ## Maintenance, releases and the cost of upgrading The repository is not archived, and the last push was on 2026-09-20. Releases are frequent enough to be a real upgrade cost: v20.68.0 on 2026-05-31, v20.69.0 on 2026-07-11, and v20.71.0 on 2026-09-16. Because installation targets a GitHub tag rather than a registry range, upgrading is an explicit edit of the tag in your dependency spec, followed by a native rebuild on every platform you ship. There is no semver range to absorb patch releases for you. The Makefile's default target compiles build.c and runs the resulting binary, and a separate upload_host target exists to publish prebuilt .node binaries to a binaries branch, which suggests the maintainers handle binary distribution manually rather than through a release pipeline. Plan for a rebuild step in CI for each target platform, and pin the tag deliberately instead of tracking master. ## Conclusion Adopt uWebSockets.js when you need a Node.js HTTP and WebSocket server that does not sit on top of a framework, and you accept installing it from a GitHub tag rather than npm. Do not adopt it if you want Express-style middleware, a plugin ecosystem, or an officially published npm package. Before you commit, verify that the release tag you pin actually builds on your Node.js version and platform, and read the Apache-2.0 notice in the README together with the 'Intellectual property, all rights reserved' line it sits next to. ## FAQ ### Are WebSockets outdated? The README presents uWebSockets.js as a standards-compliant web server for HTTP and WebSockets, and the repository ships examples for WebSocket upgrades, broadcast and pub/sub. Nothing in the README or the repository describes WebSockets as deprecated or superseded. ### Why is SSE better than WebSocket? The README does not argue this comparison. It does include examples/ServerSentEvents.mjs alongside the WebSocket examples, so the project supports both transports rather than treating one as a replacement for the other. ### What is the purpose of a WebSocket? In this project a WebSocket is the persistent connection you upgrade to, then subscribe to topics for pub/sub broadcast, as shown by examples/Upgrade.mjs and examples/PubSub.mjs. The README lists websockets among the repository topics. ### Is Socket.IO better than WebSocket? The README does not compare the two. It describes uWebSockets.js as a standards-compliant web server exposed to Node.js as a native V8 addon, and the repository's examples use the WebSocket handshake rather than a Socket.IO layer. ### How does uWebSockets.js compare with Fastify? The README cites the v20.71.0 release notes for a claim that it is 13x faster than Fastify. That figure is the project's own published claim and the repository does not present an independent measurement alongside it. ### How does uWebSockets.js compare with Express? Express is a middleware framework and uWebSockets.js has no equivalent middleware layer; it exposes routing, pub/sub and the WebSocket handshake from a C++ core. The README's own framing is a web server exposed to Node.js as a native V8 addon, not a framework. ## Sources - [Issues](https://github.com/uNetworking/uWebSockets.js/issues) - [License: Apache-2.0](https://github.com/uNetworking/uWebSockets.js/blob/master/LICENSE) - [README](https://github.com/uNetworking/uWebSockets.js/blob/master/README.md) - [Releases](https://github.com/uNetworking/uWebSockets.js/releases) - [uNetworking/uWebSockets.js on GitHub](https://github.com/uNetworking/uWebSockets.js) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/unetworking-uwebsockets-js