Q4 of 48 · Cypress
What is the architecture of Cypress and how does it differ from WebDriver-based tools?
Short answer
Short answer: Cypress runs *inside* the browser as JavaScript with full DOM and network access. WebDriver tools run as a separate process driving the browser remotely over HTTP. The in-browser model gives Cypress automatic waiting, network interception, and time-travel debugging, but locks you into JavaScript and a single browser tab.
Detail
WebDriver-based tools (Selenium, the historical default) follow a client-server architecture. Your test code, in any language, sends commands over the W3C WebDriver protocol to a browser driver process, which executes them in the browser. Each command is a round-trip: write, wait, read.
Cypress flips this. The Cypress runner injects itself into the browser and runs your test code in the same JavaScript context as the application under test. There's no remote protocol — the test directly accesses the DOM, the network layer, and the browser's APIs.
Architectural consequences flow from this. Cypress can automatically wait for elements because it polls the DOM in-process. It can stub network requests without a proxy because it intercepts fetch and XMLHttpRequest directly. It gets time-travel debugging because every command snapshots the DOM. And test failures show exactly what the app saw at that moment.
The trade-offs: you're locked into JavaScript/TypeScript, multi-tab and multi-origin scenarios are painful (improved in 12+, still constrained), and very long test runs hit memory limits. Selenium and Playwright don't have these constraints; they're driving the browser from outside.