Everyone's migrating to Playwright. But why, actually?

Lately every other team I talk to is moving off Selenium Java and onto Playwright with JS/TS. Cool. But when I ask why, half the answers are vague. "It's faster." "Everyone's doing it." Fair, but let's actually dig into it.

So management calls a meeting. Decision's made — we're switching from Selenium to Playwright. Simple as that, right? With Claude, Cursor, Gemini, Codegen all over LinkedIn these days, there's this quiet assumption in the room: AI will just... migrate the scripts. Point it at the old suite, walk away, come back to a finished framework.

I wish.

AI genuinely helps here — it'll generate boilerplate, suggest locator strategies, scaffold a Page Object faster than you'd type it yourself. But it's not making the calls. Someone still has to decide how the framework is structured, which locators are actually stable, how step definitions map to business logic, what goes in shared utils vs. what's one-off. AI speeds up the keyboard part. It does not replace the thinking part.

Honestly, in my experience, even with AI doing the heavy lifting on syntax — centralizing locators, writing out feature files, wiring up step definitions and common functions — you're still looking at something like 70% manual effort to get it production-ready. Not because AI is bad at this. Because someone has to validate every single thing it spits out against how your app actually behaves.

So no, Playwright isn't some auto-pilot migration tool. The actual win is the architecture underneath it — better waits, real cross-browser support, parallel execution out of the box, and it plays nicely with whatever AI tooling you're already using.

If you've written Selenium for more than a week, you know this pain:

driver.wait(
  until.elementLocated(By.id("submit")),
  5000
);

Or, let's be honest, you've also done this:

Thread.sleep(3000);

Because you genuinely don't know if the page finished and you just need the test to pass right now.

Playwright skips all that:

await page.click("#submit");

It waits for the element to exist, be visible, be actually clickable, and for any animation to settle — automatically. That one thing alone kills most of the random flakiness Selenium suites are known for.

Selenium, after you've already wired up the driver:

driver.findElement(By.id("email")).sendKeys("test@gmail.com");
driver.findElement(By.id("password")).sendKeys("123456");
driver.findElement(By.id("login")).click();

Playwright:

await page.fill("#email", "abc@gmail.com");
await page.fill("#password", "abc123");
await page.click("#login");

Same outcome. Less ceremony.

If your app's built on React/Next.js with the usual -spinner-then-data pattern, Selenium tends to fight you. Playwright was built after SPAs were already the norm, so it just handles that rhythm better.

The feature I keep coming back to though is network mocking:

await page.route("/api/users", route =>
  route.fulfill({
    status: 200,
    body: JSON.stringify([{ name: "Srinath" }])
  })
);

Backend's down, or flaky, or you just don't want a UI test depending on it? Fake the response, test the frontend in isolation. Genuinely saves time on bigger projects where backend and frontend ship on different timelines.

For anything new in 2026, Selenium feels like driving a manual car — you have to shift gears for every little thing (waits, locators, parallel runs). Playwright is like an automatic — just works out of the box. The auto-wait alone saves hours of debugging flaky tests. And the trace viewer? That's like having a dashcam for your test failures.

The one case I'd hold off: you're joining a team sitting on thousands of existing Selenium tests with no real migration plan. There, you learn what's already running and pick your Playwright battles for new features instead of fighting the whole legacy suite at once.

And yeah — Thread.sleep()

is a bad habit we've all leaned on. This whole migration is basically an excuse to finally kill it.