gobwas

gobwas/ws

Go MIT Web Dev

A tiny WebSocket library for Go.

6.5k stars
386 forks
slow
GitHub

6.5k

Stars

386

Forks

27

Open issues

21

Contributors

v1.4.0 03 May 2024

AI Analysis

A minimal, high-performance WebSocket library for Go that implements RFC 6455 with a focus on zero-copy upgrades and buffer reuse. It serves backend developers and systems engineers building WebSocket servers in Go who need fine-grained control over I/O and memory allocation; it is not suited for developers wanting opinionated, batteries-included frameworks.

Web Dev Library Discovery value: 6/10
Documentation 8/10
Activity 6/10
Community 8/10
Code quality 8/10

Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.

Overall score 8/10

AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.

websocket protocol-implementation performance-focused go-library rfc6455
MIT licensed Niche/specialized use case Actively maintained Production ready
Deep Analysis · Based on README and public signals
2w ago

High-performance, low-level WebSocket library for Go with zero-copy upgrade and minimal allocations

gobwas/ws is a Go WebSocket library designed for high-throughput server scenarios where memory allocation and GC pressure matter. It exposes both a low-level API for manual frame handling and buffer reuse, and a higher-level wsutil package for developers who want simpler usage. It targets Go backend engineers building services with large numbers of concurrent WebSocket connections — chat servers, real-time APIs, game backends — where standard library or higher-level libraries introduce unacceptable overhead. It is RFC6455 compliant and passes the Autobahn Test Suite.

Origin

Created in January 2017, the library emerged from a specific performance gap: existing Go WebSocket libraries did not allow I/O buffer reuse across connections, creating GC pressure under high connection counts. It has reached v1 stability, meaning its API is considered stable.

Growth

Growth appears driven by word-of-mouth within the Go performance engineering community. Its star count (~6,464) has grown steadily but not virally, consistent with a specialized library that gets discovered when developers hit performance ceilings with gorilla/websocket or nhooyr.io/websocket. The 1 star per week in mid-2026 suggests the project has matured past explosive growth into slow, stable accumulation.

In production

The library is referenced in several Go performance articles and benchmarks as a preferred choice for high-connection-count scenarios. It has been adopted in projects like eranyanay/1m-go-websockets (a widely cited benchmark). Forks (386) and the age of the repo suggest meaningful production use, but direct evidence of named large-scale production deployments is not available in the provided metadata. Adoption appears real but not formally documented at scale.

Code analysis
Architecture

Likely structured around a core low-level frame reader/writer that operates directly on net.Conn without buffering, plus a wsutil package layered on top for higher-level use. The zero-copy upgrade path appears to parse HTTP upgrade headers in-place using registered callbacks, avoiding string allocations. Based on README, the design philosophy favors composability — callers control buffers, connections, and state machines rather than having the library own them.

Tests

README states approximately 78% test coverage and passes the Autobahn Test Suite, which is a comprehensive WebSocket protocol conformance test. This is a meaningful quality signal beyond simple unit test percentage.

Maintenance

Last push was 2026-02-12, approximately 4.5 months before the evaluation date. Given the library is v1-stable and the protocol is fixed (RFC6455), low commit frequency is not a concern — this appears to be mature maintenance rather than abandonment. CI badge is present. Active but slow maintenance is the appropriate characterization.

Honest verdict

ADOPT IF: you are building a Go server that must sustain tens of thousands or more concurrent WebSocket connections and GC pressure or memory overhead from per-connection allocations is a measurable bottleneck. AVOID IF: you need simple, idiomatic Go code with context cancellation support and do not face memory or throughput constraints — coder/websocket will serve you better with less complexity. MONITOR IF: you are planning a high-scale WebSocket service but have not yet hit performance limits — benchmark your actual workload before committing to the lower-level API.

Independent dimensions

Mainstream potential

3/10

Technical importance

8/10

Adoption evidence

4/10

Risks
  • The low-level API requires developers to correctly manage buffer lifetimes, masking, and frame state — implementation errors are more likely than with higher-level libraries.
  • 78% Autobahn coverage means some edge cases in protocol compliance may not be tested, though most production traffic will not exercise those edges.
  • Limited maintainer bandwidth: the project appears to be maintained by a single author, creating a bus-factor risk for future protocol extensions or security fixes.
  • The zero-copy upgrade pattern using raw net.Conn bypasses standard net/http middleware, which may complicate integration with existing HTTP stacks, authentication, and observability tooling.
  • Community and ecosystem around the library is smaller than alternatives — fewer tutorials, Stack Overflow answers, and drop-in middleware examples may increase onboarding time for new team members.
Prediction

The library will likely remain the preferred choice for memory-sensitive, high-concurrency Go WebSocket servers. It is unlikely to grow mainstream adoption but has a durable, stable niche among performance-focused Go engineers. No major trajectory changes expected.

0 found this helpful

Newsletter

Get analyses like this every Monday

Free weekly digest of the most interesting open-source discoveries.

Languages

Go
98.5%
Shell
0.7%
Makefile
0.5%
Dockerfile
0.3%

Information

Language
Go
License
MIT
Last updated
5mo ago
Created
115mo ago
Analyzed with
anthropic/claude-haiku-4-5

Stars over time

Loading…

Contributors over time

Top 100 contributors only — repos with more will plateau at 100.

Loading…

Similar repos

coder

coder/websocket

A minimal and idiomatic WebSocket library for Go that prioritizes simplicity...

5.3k Go Dev Tools
websockets

websockets/ws

ws is a production-grade WebSocket implementation for Node.js, providing both...

22.8k JavaScript Web Dev
link1st

link1st/gowebsocket

A distributed WebSocket-based instant messaging (IM) system written in Go,...

3.1k Go Web Dev
vs. alternatives
gorilla/websocket

The historical default for Go WebSocket. Gorilla is higher-level and easier to use but allocates per-connection buffers without clean reuse primitives. gobwas/ws is more complex to use but significantly more memory-efficient under load. Note: gorilla/websocket has been in maintenance-only mode.

coder/websocket (nhooyr.io/websocket)

A modern, idiomatic Go library with context support and cleaner API than gorilla. Better ergonomics than gobwas/ws for most use cases, but does not offer the same zero-copy, buffer-reuse control that gobwas/ws provides for extreme performance scenarios.

websockets/ws (JavaScript)

Different language entirely (Node.js). Not a direct competitor — listed as a similar repo likely due to name similarity. Not relevant for Go server workloads.

golang.org/x/net/websocket

The standard library extended package. Minimal, not actively developed for performance, lacks the low-level control gobwas/ws provides. Generally considered insufficient for production WebSocket servers.