Why we build WebSocket-first

We did not pick WebSockets because they were fashionable. We picked them because for live data they are measurably better than a chain of polite HTTP requests: lower latency, one connection for all the traffic (a hundred messages do not stack a hundred handshakes worth of round-trip time on top of each other), channel subscriptions for clients that only care about part of the state, presence for free, peer messages ("whispers") when two users need to talk to each other instead of through a server. The default web stack of 2022 still answered "is anything new?" with an HTTP request every five seconds, which meant the server was answering "no, nothing changed" eight thousand times an hour, the user was watching a stale screen, and the bill was the worst of both worlds. WebSockets removed the trade. We have not gone back.

The Laravel ecosystem had one mature self-hosted WebSocket runtime: beyondcode/laravel-websockets. It was great, it was free, and after Laravel Reverb was announced upstream went quiet. We had production traffic on it. So we forked master and kept going. What started as "keep the lights on" turned into a small project of its own: async functionality so a slow handler does not block the event loop, hot code reload so a developer can change a channel handler without restarting the server, controller resolving so channel logic looks like the rest of a Laravel app, and most recently WebSocket attributes for normal HTTP controllers so the same controller can answer an HTTP request and a WebSocket message without duplicating itself.

The list of features sounds like infrastructure work, and it is, but on the receiving end it is product. Live dashboards that read instantly because the server pushes them. Multi-user editing with no merge conflicts because everybody sees the same state at the same time. Microcontroller telemetry that arrives in the browser the moment a sensor reads it. Form fields that validate as you type without burning a request per keystroke. Background jobs that report progress to a real bar instead of a spinner. None of that is exotic. It is what your customers already expect from Slack, Linear and Figma; we just made it cheap enough to be the default for an SME or an early-stage product.

Reverb is a fine runtime and we are happy it exists. We did not migrate because our fork solves a slightly different problem: it stays a normal Laravel app the whole way down, controllers and all, and it ships the developer-experience pieces (hot reload, the attribute syntax, the async event-loop posture) that matter when WebSockets is the default rather than the exception. Reverb makes adding real-time easy. Our fork makes building real-time-first easy. Different jobs, both useful.

You will not see "we added WebSockets" as a line item on a Blax quote. Live data is just how we build by default, the same way a 2026 web app uses TLS by default. If your product has dashboards, collaboration, live status, queues or anything a human watches for "did it change yet", assume that part comes out of the box. If we are wrong for your case (a static brochure site, a once-an-hour batch job) we will say so and skip the runtime entirely. We pick the right tool, we just refuse to keep paying the polling tax when we do not have to.