WebDriver BiDi vs Classic WebDriver

WebDriver BiDi and classic WebDriver are both W3C standards for browser automation, but they communicate in fundamentally different ways: classic WebDriver is one-way HTTP request/response, while WebDriver BiDi is bidirectional over WebSockets and can push events to the client in real time. With classic WebDriver, your tool asks ("click this button") and the browser answers — it can never volunteer information. With BiDi, the browser holds an open WebSocket and can push console errors, network requests, and DOM changes the instant they happen, no polling required. BiDi doesn't replace classic; it extends it, blending the standardization of WebDriver with the event-driven model that made the Chrome DevTools Protocol so powerful. Vibium is built on BiDi precisely because that event stream powers its auto-wait and rich data collection — and because BiDi needs no separate driver binary.

At a glance

Here is the honest, side-by-side breakdown of the two protocols.

How does classic WebDriver work?

Classic WebDriver uses HTTP and JSON: each command is a separate request, and the browser sends back one response. It became a W3C standard in 2018 and is the foundation Selenium has used for years. The model is simple and reliable — send a POST to click a button, get a JSON result — but it is fundamentally one-way. If a console error fires or a network request fails, classic WebDriver has no way to tell you until you explicitly ask. There is no live channel; the client always initiates.

How does WebDriver BiDi work?

WebDriver BiDi keeps a single WebSocket connection open and exchanges JSON in both directions. The client still sends commands and gets responses, but the browser can also emit events unprompted. A command looks familiar:

{"id": 1, "method": "browsingContext.navigate", "params": {"url": "https://example.com"}}

The browser responds — and then, separately, can push something you never requested:

{"method": "log.entryAdded", "params": {"level": "error", "text": "Uncaught TypeError..."}}

That pushed log.entryAdded message is the entire point. Classic WebDriver could never surface a console error the moment it occurred. For the full history of how BiDi emerged from the WebDriver and CDP eras, see what is WebDriver BiDi.

When should you choose classic WebDriver?

Classic WebDriver is the pragmatic choice when maturity and breadth matter more than live events. Reach for it when:

• You have a large existing Selenium suite built on it and no reason to rewrite.
• You need rock-solid, widely supported cross-browser commands today, including older browser versions.
• Your tests are command/response in nature — fill a form, assert text — and never need to react to pushed events.

Classic WebDriver is everywhere, deeply documented, and battle-tested. That ubiquity is a real advantage, and it is fair to say BiDi support is still catching up to it across every vendor and version.

When should you choose WebDriver BiDi?

WebDriver BiDi is the better fit when you want real-time insight or modern conveniences. Reach for it when:

• You need live console logs, network activity, or DOM events instead of polling for them.
• You want auto-wait and richer data collection — the event stream is what makes server-side actionability efficient.
• You're building AI agents that observe and react to the page as it changes.
• You'd rather skip driver binaries — Firefox speaks BiDi natively, and the protocol is designed to be cross-browser as support matures.

This is the lane Vibium lives in. Its single Go binary proxies BiDi to the browser and turns those pushed events into features like actionability auto-wait and full session tracing.

Verdict

There is no universal winner — the two protocols suit different needs, and BiDi is additive, not a replacement. Choose classic WebDriver when you have a mature suite, need the widest possible browser support, and your automation is purely request/response. Choose WebDriver BiDi when you want real-time events, auto-wait, no driver binaries, or you're building AI-driven automation. For new, modern, agent-friendly projects, BiDi is the forward-looking bet — which is exactly why Vibium was built on it. To be fair to classic WebDriver: its enormous installed base and proven stability mean it will remain the safe, supported default for many teams for years to come.

Next steps

• What is WebDriver BiDi?
• Inside Vibium's single Go binary architecture
• Vibium vs Selenium