Evolution: From Selenium to WebDriver BiDi

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 ecosystem matures
         CLI + Skills pattern emerges for AI agents

Fun fact: Vibium is created by the same person who created Selenium (2004) and Appium (2012).

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 are converging on BiDi:

• Selenium 4 is adding BiDi support
• Puppeteer has BiDi mode
• Playwright acknowledges BiDi as the future direction
• Vibium is BiDi-native

Within 2-3 years, BiDi will likely be the dominant protocol, making the CDP vs BiDi debate moot.

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. Vibium chose to build on BiDi from day one rather than abstracting over CDP — which means one protocol, one implementation, and native cross-browser support as browsers complete their BiDi implementations. It's the same creator who started Selenium in 2004, now building on the protocol that succeeds it. The trade-off is that BiDi's feature set is still catching up to CDP in some areas, but the standards trajectory is clear."