# Autobahn|JS, a WAMP client that speaks RPC and PubSub over one WebSocket

> Autobahn|JS is the JavaScript implementation of WAMP, the Web Application Messaging Protocol, offering asynchronous remote procedure calls and publish/subscribe in a single session over WebSocket. The same source runs unchanged in the browser and in Node.js, and the npm packages cover both, plus separate XBR builds.

**crossbario/autobahn-js** — WAMP in JavaScript for Browsers and NodeJS

- Repository: https://github.com/crossbario/autobahn-js
- Website: http://crossbar.io/autobahn
- Stars: 1,450 · Forks: 229
- Language: JavaScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/crossbario-autobahn-js

## One protocol, two messaging patterns, one socket

WAMP is a protocol on top of WebSocket that carries two things at once: asynchronous remote procedure calls and publish/subscribe. Autobahn|JS implements version 2 of that protocol, and the project is explicit that it works with any WAMP server, so the broker is not part of the library. The design goal is distributed realtime applications: distributing live updates to connected clients through the PubSub pattern, and calling procedures on remote components through RPC. The documented use cases span multi-user database driven business applications, realtime charts, sensor networks for IoT, instant messaging and massively multi-player online games. The architectural argument for WAMP is polyglot by design. Because implementations exist for multiple languages, a component can be written in the language that fits it and still take part in the same application, from embedded sensors to mobile clients to the browser, with application code distributed across processes and devices by functional aspect rather than by language boundary.

## The four roles, in one snippet that runs in both places

The README's example is worth reading closely, because it demonstrates all four roles a client can take: publisher, subscriber, caller and callee. A connection is opened with a url and a realm, and inside the open handler you subscribe to a topic, publish an event on it, register a procedure and then call a remote one. The same file is claimed to run unaltered in the browser and in Node.js, and the only accommodation for that is the require call at the top wrapped in a try block, since in the browser the library is available globally. The realm is the routing scope: a router keeps sessions with different realms apart, so `realm1` in the example is what scopes the topic and procedure names. The API is promise based, and the remote call returns a promise that resolves with the result array.

```javascript
try {
   // for Node.js
   var autobahn = require('autobahn');
} catch (e) {
   // for browsers (where AutobahnJS is available globally)
}

var connection = new autobahn.Connection({url: 'ws://127.0.0.1:9000/', realm: 'realm1'});
```

The rest of the example stays inside the open handler, where the subscribe, publish, register and call calls all take the session as their first argument.

## Calls, events and progressive results

The four roles map onto two method families on the session object. `session.subscribe` takes a topic and a handler, and the handler receives the event payload as an array, which is why the example logs `args[0]`. `session.publish` sends an event to a topic. `session.register` offers a procedure, and the registered function returns the result, so the `add2` example takes two arguments and returns their sum. `session.call` invokes a remote procedure and returns a promise, and the example chains a success handler that logs the result. The library also supports progressive calls, where a long running procedure streams partial results before the final one, and this is where the promise implementation matters. Promises and deferreds are pluggable, with when.js as the built-in option and support for progress notification. The dependency list is deliberately short: when.js for promises and CryptoJS for WAMP-CRA authentication, and the README puts the source size at roughly 250kB, 110kB minified and 35kB gzipped.

## Node.js 22 and up, and what happens below that

The platform requirement is recent and worth reading before you plan a deployment. Autobahn|JS targets Node.js 22 and above, using the native WebSocket implementation, so no external WebSocket library is needed. For older Node.js versions, below 22, the project points you at the v20.x line of AutobahnJS, which is the one that includes the ws library. That split has a practical consequence: choosing a runtime pins the library major version, and the two lines are not interchangeable. The supported version table lists 22.x as maintenance LTS with support until Apr 2027, 24.x as the active LTS, named Krypton, with support until Apr 2028, and 25.x as current with no end date given, and the recommendation is to use 24.x for production deployments. Modern browsers are supported at their current versions across Chrome, Firefox, Edge and Safari, and there are fallback transports for old browsers, with WebSocket or HTTP long-poll as the transport options.

## Installing and checking the install

For Node.js, the library is on npm and the install is a single command.

```bash
npm install autobahn
```

The README then gives a verification step that prints the loaded version, which is a cheap way to confirm the module resolves and which build you actually got.

```bash
node -e "var autobahn = require('autobahn'); console.log('AutobahnJS version:', autobahn.version);"
```

The npm quicklinks list four packages: `autobahn` for Node.js, `autobahn-browser` for browsers, and `autobahn-xbr` and `autobahn-xbr-browser` for the XBR flavour, with the XBR protocol and its own documentation hosted separately. Browser development takes a different route: the built release is retrieved by cloning a separate repository, the autobahn-js-browser one, and hosted wherever you need it, and that repository also carries the complete history of previous releases and works with Bower, where the documented install is `bower install autobahn`. So a browser build can also be a clone and host step, while `autobahn-browser` is on npm.

## A monorepo with a justfile, a vitest suite and a private root package

The repository layout tells you the project has been restructured recently. The root `package.json` is named autobahn-development and is marked private, described as a local development package never published, used for library development and CI, and it carries no runtime dependencies, only dev tooling: browserify, eslint, prettier, vitest, deep-equal, google-closure-compiler and dotenv. The actual libraries live under `packages/`, and the root also has a `justfile` for task running, a `vitest.config.js` for the test runner, an `eslint.config.mjs`, an `aspects.toml`, and directories such as `.cicd`, `.crossbar`, `docs/`, `packages/` and `.ai`, plus policy files named AI_POLICY.md, CLAUDE.md, OVERVIEW.md, MODERNIZATION.md and DEVELOPMENT.md. The justfile itself shows the shape of the workflow: it imports shared recipes from a workflow file, defines the project directory, creates a directory for Python virtual environments used by crossbar, and names the supported Python environments. The default recipe prints the package version read from `packages/autobahn/package.json` and the current git revision.

## Release naming and what it tells you

The published artifacts are named after the branch and the timestamp, which is a signal about how the project ships. The recent releases are `master-202610102251` on 2026-10-10, `master-202609291736` on 2026-09-29, and one fork build, `fork-2afaa147-oberstet_autobahn_js-fix_611-202610102025` on the same day as the last of them. The last push to the repository was on 2026-10-10 and the repository is not archived. There is no semantic version series in the release names here, which means a consumer pinning a build is pinning a point in the master branch rather than a tagged API contract, and the presence of fork-named builds suggests continuous integration runs produce artifacts for contributions as well. The licence is MIT, with the text in the `LICENSE` file at the repository root, and the project describes itself as a subproject of the wider Autobahn project, with the full documentation set in the `doc/` directory including a Getting Started guide and a programming introduction.

## Conclusion

Adopt Autobahn|JS if you are building a realtime application in JavaScript and want a WAMP client that does not tie you to one broker, since the library works against any WAMP server and the same file runs in a browser and in Node.js. Skip it if you only need a one-way event stream to a fixed backend, because a full RPC and PubSub protocol is more than the job needs, or if you are stuck on Node.js below 22, since the current line requires the native WebSocket implementation and the older v20.x line is the one that bundles the ws library. Verify three things first: that your WAMP router speaks the dialect you need, since the library implements WAMP v2 and works with any WAMP server; that progressive calls are what you expect, since the promise implementation is pluggable and when.js is the built-in option; and that the version you pin matches your Node.js line, since the support table ends 22.x at Apr 2027.

## FAQ

### What is Autobahn|JS and what protocol does it implement?

It is the open source JavaScript implementation of WAMP, the Web Application Messaging Protocol version 2, providing asynchronous remote procedure calls and publish and subscribe messaging over WebSocket. It is a subproject of the wider Autobahn project and is MIT licensed.

### How do I install Autobahn|JS for Node.js and confirm it works?

Run `npm install autobahn`, then verify with the documented check that requires the module and prints `autobahn.version`. The library targets Node.js 22 and above using the native WebSocket implementation; for older Node.js versions use the v20.x line, which includes the ws library.

### What Node.js versions does Autobahn|JS support?

The table lists 22.x as maintenance LTS with support until Apr 2027, 24.x as active LTS with support until Apr 2028, and 25.x as current. The README recommends 24.x for production deployments.

### Can I use Autobahn|JS in a browser as well as Node.js?

Yes, the same code runs unaltered in both. The browser build is obtained by cloning the separate autobahn-js-browser repository and hosting it, and that repository can also be installed with Bower using `bower install autobahn`. On npm there is a separate `autobahn-browser` package.

### Does Autobahn|JS work with any WAMP server?

The project states that it supports WAMP v2 and works with any WAMP server, and that the promise and deferred implementation is pluggable, with when.js built in and progress support for WAMP progressive calls.

## Sources

- [crossbario/autobahn-js on GitHub](https://github.com/crossbario/autobahn-js)
- [License: MIT](https://github.com/crossbario/autobahn-js/blob/master/LICENSE)
- [Project website](http://crossbar.io/autobahn)
- [README](https://github.com/crossbario/autobahn-js/blob/master/README.md)
- [Releases](https://github.com/crossbario/autobahn-js/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crossbario-autobahn-js