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.

The "just let AI do it" moment

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.

---

Fine, what's the real difference then

	Selenium	Playwright
Speed	Slower	Faster
Setup	Annoying	Quick
Browser control	WebDriver	Direct
Waits	Manual	Built-in
SPA/React handling	Decent	Genuinely good
Network mocking	Limited	Easy
Mobile emulation	Basic	Solid
Parallel runs	Work to set up	Just works

The thing that actually matters: waiting

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 loading 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.

Same login test, both tools

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.

Where it actually pays off

If your app's built on React/Next.js with the usual loading-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.

So, worth switching?

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.