Evolution: From Selenium to WebDriver BiDi

Updated Aug 2026

The Timeline

2004 ──── Selenium 1.0 (JavaScript injection)
   │
2011 ──── Selenium 2.0 / WebDriver (HTTP + JSON)
   │
2017 ──── Chrome DevTools Protocol (CDP) gains traction
   │      Puppeteer launches (CDP-based)
   │
2018 ──── WebDriver becomes W3C standard
   │
2020 ──── Playwright launches (CDP-based, multi-browser)
   │
2021 ──── WebDriver BiDi work begins at W3C
   │
2023 ──── Puppeteer adds BiDi support
   │
2024 ──── Selenium 4 integrates BiDi
   │
2025 ──── Vibium launches (BiDi-native)
   │      Playwright MCP server ships
   │
2026 ──── BiDi is mainstream: WebdriverIO v9 defaults to it,
         ~70% of CDP surface covered (Chrome + Firefox)
         CLI + Skills becomes the recommended AI-agent path
         (Microsoft's own Playwright CLI adopts it)

Fun fact: Vibium is created by Jason Huggins — the same person who created Selenium back in 2004.

Era 1: Selenium and JavaScript Injection (2004-2011)

How It Worked

Selenium injected JavaScript into the browser to simulate user actions. A Java-based "Selenium RC" server acted as a proxy.

Test Script → Selenium RC Server → Injected JS in Browser

Problems

• Same-Origin Policy: JavaScript couldn't cross domain boundaries
• Browser security: Increasingly restricted what injected JS could do
• Fragile: Depended on browser internals that changed frequently
• Slow: HTTP round trips for every action

Era 2: WebDriver and Native Browser APIs (2011-2017)

How It Worked

Each browser vendor provided a "driver" binary (chromedriver, geckodriver) that used native browser APIs to control the browser. Communication was HTTP + JSON.

Test Script ──HTTP──► ChromeDriver ──Native API──► Chrome

The WebDriver Protocol (W3C Standard, 2018)

POST /session                          → Create session
POST /session/{id}/url                 → Navigate
POST /session/{id}/element             → Find element
POST /session/{id}/element/{id}/click  → Click element
POST /session/{id}/element/{id}/value  → Type text
GET  /session/{id}/screenshot          → Take screenshot
DELETE /session/{id}                   → Close session

Advantages Over Selenium 1

• Native control: No JavaScript injection needed
• Cross-domain: No same-origin restrictions
• Standardized: W3C standard, all browsers implement it
• Reliable: Using browser's own APIs

Limitations

• Unidirectional: Client asks, browser answers. No events.
• Coarse-grained: Limited to what the spec defines
• No real-time: Can't listen for console logs, network events, etc.
• Polling required: To detect page changes, must repeatedly ask

Era 3: Chrome DevTools Protocol — CDP (2017-present)

How It Worked

Chrome exposed its developer tools interface as a WebSocket API. Puppeteer (Google) and Playwright (Microsoft) built on this.

Test Script ──WebSocket──► Chrome (DevTools)

What CDP Enabled

// Bidirectional: Browser pushes events
{"method": "Console.messageAdded", "params": {"message": {"text": "error!"}}}

// Network interception
{"method": "Network.requestWillBeSent", "params": {"request": {"url": "..."}}}

// DOM manipulation
{"method": "DOM.getDocument", "params": {}}

// Performance profiling
{"method": "Performance.getMetrics", "params": {}}

Advantages Over WebDriver

• Bidirectional: Events push from browser to client
• Rich: Network, performance, DOM, coverage, accessibility
• Fast: WebSocket is lower overhead than HTTP

Problems

• Chrome-only: CDP is Chrome's internal protocol
• Unstable: Google can change it without notice (it's "internal")
• Browser-specific: Playwright had to write separate backends for Firefox, WebKit
• Vendor lock-in: Your tests depend on a Google-controlled protocol

Playwright's Workaround

Playwright abstracts CDP (Chrome), a patched Firefox protocol, and WebKit's debugging protocol behind a unified API. This is impressive engineering but creates a maintenance burden — Playwright must track internal changes in three browsers.

Era 4: WebDriver BiDi (2021-present)

The Best of Both Worlds

How BiDi Solves CDP's Problems

1. Standardized by W3C — Browser vendors commit to implementing it
2. Cross-browser by design — Chrome, Firefox, Safari, Edge all participate
3. Stable API contract — Changes go through a standards process
4. Same power as CDP — Events, network, scripting, input

Current Browser Support (2026)

Where Vibium Fits

Vibium is BiDi-native from day one. It doesn't abstract over CDP or legacy WebDriver — it speaks BiDi directly.

Traditional stack:           Vibium stack:

Test → Playwright → CDP      Test → Vibium → BiDi
       Playwright → Firefox         (same protocol for all browsers)
       Playwright → WebKit

Advantages

• No abstraction overhead — BiDi is the protocol, not a compatibility layer
• Future-proof — As BiDi improves, Vibium improves
• Cross-browser potential — When Safari completes BiDi support, Vibium works there
• Simple — One protocol, one implementation, one binary

The Trade-off

• BiDi is newer than CDP — some advanced features (network interception, coverage) are still being standardized
• Chrome's CDP is more feature-rich today — but it's not standardized
• Playwright's CDP-based approach gives you more features now at the cost of vendor dependency

Impact on Test Automation Strategy

For Architects Choosing a Stack

The Convergence

All major tools have converged on BiDi — as of July 2026 this is fact, not forecast:

• Selenium 4 ships low-level BiDi today (~70% of CDP surface, Chrome + Firefox); high-level APIs are the headline for the still-unreleased Selenium 5
• WebdriverIO v9 uses BiDi by default
• Puppeteer has BiDi mode
• Vibium is BiDi-native

Teach BiDi as the present tense of browser automation protocols. The remaining question is timing on Safari completeness and Selenium 5 — not whether BiDi wins.

Interview Talking Point

"Browser automation has evolved through four eras. Selenium 1 used JavaScript injection, WebDriver added native browser APIs over HTTP, CDP brought bidirectional WebSocket communication but was Chrome-specific and unstable, and now WebDriver BiDi combines standardization with bidirectionality. As of 2026 BiDi is the present, not the future: WebdriverIO v9 defaults to it, Selenium 4 exposes it at the low level with high-level APIs coming in Selenium 5, and it covers roughly 70% of what CDP offers across Chrome and Firefox. Even Jason Huggins — who started Selenium in 2004 — built his new tool, Vibium, BiDi-native from day one. The trade-off is that BiDi's feature set is still catching up to CDP in some areas, but the standards trajectory is settled."