#Comparison

Honest comparison against the four browser-automation tools you're most likely choosing between, and against the agent-facing tooling each of them now ships. Snapshot: 2026-08-29, against playwright 1.62.1, @playwright/mcp 0.0.79, @playwright/cli 0.1.18 and chrome-devtools-mcp 1.8.0. Every count below was taken from those packages rather than from their documentation.

#At a glance

#Pick ferridriver when

• Your team writes Rust. Tests live in the same toolchain as the product code. No Node sidecar.
• You want one binary. MCP server, BDD runner, browser installer, script runner — ferridriver.
• You want native JS / TS BDD steps without Node in the run path. Rolldown bundles, QuickJS executes. package.json and node_modules optional.
• You want an AI-driven browser without spinning up another stack. The MCP server ships in the binary.

#Pick Playwright when

• You're already on Node and the team is comfortable with the JS ecosystem.
• You need API stability today. ferridriver is pre-1.0.
• You need a richer language SDK matrix (Python, .NET, Java first-class).
• Codegen with an inspector window matters. ferridriver has UI mode and serves its own trace viewer, but its codegen has no picker window.
• You want the CLI + SKILLs shape for a coding agent. @playwright/cli ships a skill with nine reference documents, covering named sessions, request mocking, tracing, video and test generation. There is no ferridriver equivalent; the MCP server is the only agent surface here.

#Pick Puppeteer when

• You only need Chromium and want the smallest possible dependency surface in a Node project.
• You don't need a test framework wrapper — you'll BYO Jest / Vitest / Mocha.

#Pick Selenium when

• You need real Safari (safaridriver), real Edge legacy, or obscure browser-vendor drivers.
• You operate a grid for distributed cross-browser, cross-OS runs.
• You're standardizing on W3C WebDriver for vendor neutrality.

#Pick Cypress when

• Time-travel debugging in the UI runner is your team's main workflow.
• You're testing only Chromium-family browsers and the in-browser execution model fits (no multi-tab, no cross-origin, single browser per spec).

#What ferridriver doesn't do (yet)

• HAR recording — recordHar is accepted on the context options bag and does nothing, on every backend, without saying so. HAR replay (routeFromHAR) does work, on all four backends. Replay is what the network-mocking row above refers to.
• Codegen picker — ferridriver codegen records interactions and emits a runnable script (default TypeScript), but has no inspector window like Playwright's codegen. The picker itself exists as an API (page.pickLocator()); it is not wired into the codegen command.
• A CLI + skills bundle for coding agents — the MCP server is the only agent-facing surface here. See below.

#Agent tooling

The interesting comparison has moved. All three of these now ship something aimed at agents, and they have picked different shapes.

Two things worth taking from that table rather than the counts.

A large tool surface is a cost, not a feature. Every tool's schema is in the model's context on every turn. Microsoft's own README now points coding agents at @playwright/cli with SKILLs instead of the MCP server, for exactly this reason, and Google ships a --slim mode that drops chrome-devtools-mcp from 58 tools to 3. ferridriver's 13 are deliberate: run_script takes a whole program with page, context and request bound, so a loop or a conditional needs one tool call rather than a tool per verb.

Where the depth is differs. chrome-devtools-mcp is the only one of the three with PWA and extension installation; if that is the job, use it. Its thirteen heap-snapshot tools are one capability here rather than thirteen: page.takeHeapSnapshot() hands back a handle carrying the same queries, and the analysis behind them is checked against DevTools' own heap engine node by node. ferridriver's performance analysis covers the same 19 DevTools insights and is checked against the real devtools-frontend engine on recorded traces, which is a claim the others do not make about theirs, and it runs in-process rather than shelling out to a bundle.

#Performance

Rough order-of-magnitude only. Real numbers vary by hardware, network, and what each suite actually does. These figures were not re-measured for the snapshot above; everything else on this page was.

The pipe transport, Rust polling, and overlapped worker launches add up. A 200-test suite at 4 workers typically runs 2–3× faster than the same suite on @playwright/test. The gap shrinks as tests do more real work (server round-trips, DOM-heavy assertions) — those costs are the same everywhere.