Home > Blog > I Was Wrong: Selenium vs Playwright in 2025

Author: Tomotaka ASAGI

Published: Jan 10, 2026

I'm Seeing the Shift to Playwright

As I reflect on 2025 and look ahead to 2026, I want to share a lesson learned.

Introduction

Throughout last year, I didn't have a single project where we built new automated tests with Selenium. Every conversation was about either using SaaS-based tools or building with Playwright.

All those Selenium projects that used to come in—now I'm just quietly maintaining and updating automated test systems that were originally built with Selenium.

If someone asked me today, "We're starting web test automation and you have free rein—which testing tool or framework should we choose?" I would answer Playwright is the better choice.

But a year ago, I would have said, "It doesn't matter. They all do the same thing." Looking back now, I have to admit that was completely wrong.

I was mistaken.

I think it's the price I'm paying for being too busy to properly explore new tools. Recently, I've had more opportunities to work with Playwright (thanks to AI), so I'd like to share my observations.

The Changing Landscape Around Selenium

Behind the shift to Playwright lies a transformation in the test automation landscape.

Declining Demand for Cross-Browser Testing

In the past, I received many requests for tests that would detect differences between browsers. "Please verify that it works the same on Chrome, Firefox, Edge, and Internet Explorer."

But now, such requests are rare.

The biggest impact was the end of Internet Explorer. (I know, I know—that was ages ago!) IE had its own rendering engine, and compatibility issues with other browsers were endless. With IE gone, major browsers have consolidated into Chromium-based (Chrome, Edge), Firefox, and Safari, dramatically reducing cross-browser differences.

Selenium's great strength was its ability to control multiple browsers uniformly, but the situations where that strength matters have diminished.

Selenium's Challenges and How Playwright Solves Them

With over 20 years in test automation, I've found that the challenges I felt with Selenium are being addressed by Playwright.

Challenge 1: Complex Selector Strategies

The Selenium World

In Selenium, we used selectors based on DOM structure to identify elements.

// Typical locator strategy in Selenium
driver.findElement(By.id("submit-button"));
driver.findElement(By.cssSelector("#form > div.container > button.primary"));
driver.findElement(By.xpath("//div[@class='modal']//button[contains(text(), 'Submit')]"));

We had to think about locator strategies—ID first, then name, CSS, and finally XPath—and maintain selectors every time the DOM structure changed. Tests breaking just because a developer changed a class name was not uncommon.

The Playwright World

In Playwright, role-based selectors are recommended.

// Role-based selectors in Playwright
await page.getByRole('button', { name: 'Submit' }).click();
await page.getByLabel('Email Address').fill('test@example.com');
await page.getByPlaceholder('Enter search keyword').fill('Playwright');

This identifies elements based on the role and name that users perceive, not DOM structure. As long as the button is named "Submit," the test continues to work even if the HTML structure changes.

This approach has even greater significance. Role-based selectors align with accessibility principles. Assistive technologies like screen readers also use roles and aria-labels to recognize elements. In other words, a site that's easy to test is also an accessible site.

And in the AI era, this structure becomes even more important. In AI-driven browser automation like Playwright MCP, the way pages are represented is shifting from DOM to Accessibility Tree (ARIA Snapshot). Getting comfortable with role-based selectors is an investment in the future.

Challenge 2: Cumbersome and Unstable Wait Handling

The Selenium World

The most frustrating aspect of Selenium was wait handling.

// Wait handling in Selenium
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement element = wait.until(
    ExpectedConditions.elementToBeClickable(By.id("submit-button"))
);

// Or the common "just wait" anti-pattern
Thread.sleep(3000);  // Fixed 3-second wait

Setting appropriate wait conditions was difficult, so we often ended up with fixed waits like "Thread.sleep(3000)" just to be safe. As a result:

• Test execution time became unnecessarily long
• Tests still failed in some environments due to timing issues
• Increasing wait times caused overall execution time to balloon

We were constantly struggling with this trade-off between "stability" and "speed."

The Playwright World

Playwright has Auto-waiting built in.

// Wait handling is automatic in Playwright
await page.getByRole('button', { name: 'Submit' }).click();
// ↑ Automatically waits until the button is clickable

Playwright automatically waits until elements are visible, enabled, and animations are complete. Fixed wait times are almost never needed, and tests now wait only as long as necessary and proceed as soon as they're ready.

This achieves:

• Reduced test execution time
• Fewer flaky tests
• Lower maintenance costs

Feature Comparison

Here's a summary of the key differences between Selenium and Playwright.

• Playwright Test is only available for TypeScript/JavaScript. The Java version requires separate frameworks like JUnit.

Regarding browser management, Selenium does have its advantages. Selenium launches the actual browsers installed on your PC, so you can test in the same environment as your users. Playwright, on the other hand, automatically downloads and uses dedicated browser binaries—easier to set up, but strictly speaking, not "the exact browser your users are using."

As you can see from this table, Selenium is "a mechanism to automate browsers," and in terms of testing, it required separate test frameworks. This meant needing various peripheral knowledge—JUnit, TestNG, wait handling best practices, reporting tools, and more.

Playwright, on the other hand, is a test framework itself. It comes packed with testing-specific features, and being able to capture screenshots and videos with just configuration settings is truly convenient.

Conclusion

Selenium is a great tool that pioneered web browser automation. I personally relied on it for many years.

However, the test automation landscape is changing:

• Browser differences have decreased, relatively lowering the importance of cross-browser testing
• Role-based selectors enable more stable tests
• Auto-waiting frees us from flaky tests and wasted wait time

Most importantly, Playwright is designed as a "test automation platform," not just a "browser automation tool."

For those just starting with web test automation, or those considering migration from Selenium, I highly recommend Playwright.

Next time, I'll compare the feature differences between TypeScript and Java when using Playwright.

This article is Part 1 of the Playwright series.

• Part 1: From Selenium to Playwright (this article)
• Part 2: TypeScript vs Java - Feature Differences by Language
• Part 3: BDD Framework Comparison - Cucumber.js vs Playwright-bdd