Why doesn't Playwright rely on the WebDriver protocol?

WebDriver was designed as a standardized, cross-vendor HTTP protocol so any client library could drive any compliant browser the same way - a strength for portability, but it constrains what's exposed to exactly what the W3C spec defines, and every command is a synchronous-feeling HTTP request/response round trip.

Playwright's team, several of whom previously worked on Puppeteer and DevTools Protocol tooling at Google, chose instead to build directly against each browser's lower-level automation surface - patching Firefox and WebKit specifically to expose the same depth of control Chromium's DevTools Protocol already offered.

This trade-off sacrifices WebDriver's broad third-party tool compatibility in exchange for capabilities WebDriver doesn't standardize at all: intercepting network requests before they're sent, native multi-context/multi-tab support in one connection, and a persistent event-based connection instead of discrete polling requests. It's a deliberate bet that deeper browser-specific integration outweighs protocol-level standardization for the specific job of automated testing.