Playwright vs Selenium: the comparison everyone runs skips one row

The framework war, settled in one screen

Here is the honest version of the standard comparison. Most of it is no longer a debate. Playwright drives the browser through the Chrome DevTools Protocol over one persistent WebSocket; Selenium drives it through the WebDriver protocol, historically a request and response per command. That gap is real, though Selenium 4 narrowed it by adding WebDriver BiDi, a WebSocket channel of its own. Playwright auto-waits for an element to be actionable before it acts; Selenium expects you to write the wait. Selenium reaches more languages and a wider browser matrix; Playwright covers the modern three from a single install. For greenfield web work that is enough to decide it. Read the last row carefully, because the rest of this page lives there.

The row no comparison table has: who writes the selector

Every test, in either framework, points at the page through a string a human typed. In Selenium it looks like By.xpath("//div[2]/form/button"). In Playwright it looks like getByRole('button', { name: 'Sign up' }). Playwright's version is genuinely better: it leans on the accessible role and name instead of a positional path, so it survives more changes. But it is still a string, written against the DOM and the accessible names that exist today, and committed to your repo. The day someone renames that button, the string is wrong. The framework cannot know the rename was harmless. The test fails, CI goes red, and a person has to go fix a string for a bug that never existed.

That is the part the comparison articles flatten into a single syntax footnote. Migrating from Selenium to Playwright upgrades the syntax and the waiting behavior. It does not change who is on the hook for the selector. Look at the three approaches side by side:

// Selenium 4 — you author an XPath against today's DOM shape
driver.findElement(
  By.xpath("//div[2]/form/button[contains(., 'Sign up')]")
).click();

// Playwright — cleaner syntax, still a string you own and commit
await page.getByRole('button', { name: 'Sign up' }).click();

// Assrt — there is no selector string to write or maintain
//   1. browser_snapshot()  ->  live a11y tree, every node gets [ref=eN]
//   2. browser_click({ element: 'Sign up button', ref: 'e12' })
//   ref=e12 is recomputed on the next snapshot, so nothing rots

The first two lines are the framework choice. The third is a different choice entirely: not a smarter selector, but no selector string at all. Before that makes sense, it helps to watch the cost the first two share.

The maintenance loop a framework choice does not break

This is the lifecycle of a single selector. It runs the same whether the string is an XPath or a Playwright locator. Watch it once and the recurring cost becomes obvious.

Nothing in that loop is a Playwright problem or a Selenium problem. It is a hand-written-selector problem. Auto-wait, the headline Playwright feature, never enters the loop, because the failure was not a timing failure. The element was found instantly; it just was not the element the string described anymore.

What Assrt does instead, traced through the actual code

Assrt is not a third framework competing with Playwright and Selenium. It runs on Playwright: its package.json declares @playwright/mcp ^0.0.70 as a hard dependency. What it changes is the selector layer. Instead of you writing a locator string, the agent works off the live accessibility tree.

That is the whole point. A ref like e12 is recomputed from the page on the next snapshot. When the button is renamed, the next snapshot just returns whatever is on the page now, and the agent re-matches the element by its role and visible name. There is no string in your repo to go red, because there is no string in your repo. The maintenance loop from the previous section has nowhere to start.

When Selenium is still the right call, honestly

A comparison that only ever points one direction is marketing, not analysis. There are real cases where Selenium beats Playwright and where neither one of them, plus an agent layer, is the move.

Stay on Selenium if your test code is written in a language Playwright does not bind well, Ruby being the clearest example, or if your CI is built around a Selenium Grid with device and legacy-browser coverage you are contractually on the hook for. The cost of rewriting a large, stable Selenium suite almost always exceeds the ergonomic gain, and a quiet suite is not a problem that needs solving.

Pick Playwright for greenfield JavaScript or TypeScript work. The architecture is better, auto-wait removes a whole genre of flake, and the debugging tools (trace viewer, the inspector) are excellent. This is the default for most teams starting a suite in 2026, and it is the engine Assrt runs on.

Add Assrt when the bottleneck is not the framework but the hours. If your team is choosing Playwright because the selectors will be more durable, that is true and also not enough: durable is not the same as free. Assrt removes the selector-authoring step entirely, keeps the engine as standard Playwright, and stays open source under the MIT license so the tests run in your own CI with no cloud in the path. It is the answer to the row the comparison tables never print.

Frequently asked questions