A Quick note on the Java Angle
Most Playwright content you'll find online is Node.js. The ecosystem, the examples, the tutorials - overwhelmingly JavaScript. But a huge slice of enterprise automation teams (especially those in ServiceNow, SAP, or Java-heavy stacks) live and breathe Java. The good news: Playwright has a first-class Java SDK. The slight catch: the Java docs are thinner, and you'll hit gaps that Google won't immediately solve. Keep that in mind as we go.
Setup and Project Bootstrap
Selenium (Java)
Selenium setup with Maven is familiar to the point of muscle memory:
org.seleniumhq.selenium
selenium-java
4.18.1
Add WebDriverManager to skip the manual driver binary management:
io.github.bonigarcia
webdrivermanager
5.7.0
Bootstrap a test:
WebDriverManager.chromedriver().setup();
WebDriver driver = new ChromeDriver();
driver.get("https://example.com");
Clean, well-documented, and your entire team has done this before.
Playwright (Java)
com.microsoft.playwright
playwright
1.43.0
First run requires browser installation:
mvn exec:java -e -D exec.mainClass=com.microsoft.playwright.CLI -D exec.args="install"
Bootstrap:
try (Playwright playwright = Playwright.create()) {
Browser browser = playwright.chromium().launch();
Page page = browser.newPage();
page.navigate("https://example.com");
}
The try-with-resources pattern feels natural for Java developers. Playwright bundles its own browser binaries - no WebDriverManager equivalent needed, but it does mean larger dependencies. In a corporate environment with a private npm or Maven registry, this can create friction on first setup.
Verdict: Selenium wins on familiarity. Playwright wins on self-sufficiency once bootstrapped.
Locators and Element Interaction
This is where the day-to-day feel of each framework diverges most noticeably.
Selenium
WebElement button = driver.findElement(By.cssSelector(".submit-btn"));
button.click();
// Chained interactions
new Actions(driver)
.moveToElement(button)
.click()
.perform();
Selenium gives you raw control. You find elements, you act on them. When it works, it's transparent and debuggable. When it doesn't - and the MoveTargetOutOfBoundsException or StaleElementReferenceException hits - you're writing retry logic, explicit waits, and scrolling workarounds manually.
Playwright
page.locator(".submit-btn").click();
// With auto-waiting built in
page.getByRole(AriaRole.BUTTON, new Page.GetByRoleOptions().setName("Submit")).click();
Playwright's locator model is fundamentally different. Every action auto-waits for the element to be actionable - visible, enabled, stable. That single property eliminates an entire class of flaky test bugs that Selenium developers spend hours fighting. The getByRole, getByText, getByLabel locators also encourage writing tests that mirror how users actually interact with the UI.
The StaleElementReferenceException factor: In Selenium, if the DOM re-renders after you locate an element, your reference is dead. In Playwright, locators are lazy - they re-query the DOM at the moment of interaction, so this problem largely disappears.
Verdict: Playwright's locator model is a genuine quality-of-life improvement for day-to-day test writing.
Handling Waits
This is the single biggest source of flakiness in Selenium-based suites, and it deserves its own section.
Selenium - the manual wait dance:
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement element = wait.until(
ExpectedConditions.elementToBeClickable(By.id("submit"))
);
element.click();
You do this constantly. Every dynamic element, every async operation, every page transition. Miss one wait, and your test is intermittently red on CI.
I once spent three days chasing a flaky test that failed only on CI, never locally. The culprit was a 200ms animation delay that my local machine's speed masked. One missing explicit wait. Three days.
Playwright - auto-waiting by default:
// This already waits for the element to be visible, enabled, and stable
page.locator("#submit").click();
// Need to wait for a network response? Built in.
page.waitForResponse("**/api/submit", () -> {
page.locator("#submit").click();
});
Playwright's auto-waiting isn't magic - it has a configurable default timeout (30 seconds) and you can override per action. But the cognitive load shift is real: you write the test, not the wait strategy.
Verdict: Playwright wins decisively here. Auto-waiting alone justifies evaluating it for any flake-prone suite.
Shadow DOM Handling
This is personal. I've spent more time than I'd like to admit fighting Shadow DOM in Selenium.
Selenium - painful:
// You must pierce each shadow root manually
WebElement shadowHost = driver.findElement(By.cssSelector("my-component"));
SearchContext shadowRoot = shadowHost.getShadowRoot();
WebElement innerEl = shadowRoot.findElement(By.cssSelector(".inner-button"));
innerEl.click();
This works for shallow shadow trees. Nested shadow roots? You're writing recursive helpers or falling back to JavaScript execution:
WebElement el = (WebElement) ((JavascriptExecutor) driver)
.executeScript("return document.querySelector('my-component').shadowRoot.querySelector('.inner-button')");
Maintainable? Barely.
Playwright - just works:
// Playwright pierces shadow DOM automatically
page.locator("my-component >> .inner-button").click();
// Or using the built-in shadow piercing
page.locator(".inner-button").click(); // auto-pierces by default in many cases
Playwright was built with modern web components in mind. Shadow DOM piercing is a first-class feature, not an afterthought.
Verdict: Playwright wins. If your application uses Web Components heavily, this alone may be the deciding factor.
Multi-Tab and iframe Handling
Selenium:
// Switch to new tab
String originalWindow = driver.getWindowHandle();
Set allWindows = driver.getWindowHandles();
for (String window : allWindows) {
if (!window.equals(originalWindow)) {
driver.switchTo().window(window);
break;
}
}
// Switch to iframe
driver.switchTo().frame(driver.findElement(By.id("my-iframe")));
// ... do stuff
driver.switchTo().defaultContent(); // don't forget this
The context-switching model in Selenium works, but it's stateful and error-prone. Forget to switch back and your next locator fails mysteriously.
Playwright:
// New tab/popup - event-driven
Page popup = page.waitForPopup(() -> {
page.locator("#open-popup").click();
});
popup.waitForLoadState();
popup.locator(".popup-confirm").click();
// iframe - no context switching needed
FrameLocator frame = page.frameLocator("#my-iframe");
frame.locator(".inner-element").click();
Playwright's page and frame objects are independent - you work with them directly without switching global context. This model is cleaner and less error-prone in parallel test runs.
Verdict: Playwright's model is cleaner, especially for parallel execution.
Network Interception
Selenium: Not natively supported. You need BrowserMob Proxy, WireMock, or similar external tools wired in separately.
Playwright:
// Mock an API response
page.route("/api/users", route -> {
route.fulfill(new Route.FulfillOptions()
.setStatus(200)
.setContentType("application/json")
.setBody("[{\"id\": 1, \"name\": \"Test User\"}]"));
});
// Intercept and modify requests
page.route("/api/**", route -> {
System.out.println("Request: " + route.request().url());
route.resume();
});
Network interception built directly into the framework is a significant capability. It enables faster tests (no real API calls), reliable tests (no external dependencies), and opens the door to contract testing patterns without additional tooling.
Verdict: Playwright wins, and it's not close. This capability alone makes it compelling for teams doing API-integrated UI testing.
Parallel Execution
Selenium: Parallel execution requires TestNG/JUnit configuration plus a Selenium Grid or cloud provider (BrowserStack, Sauce Labs). Managing thread-local WebDriver instances is a recurring source of bugs:
private static ThreadLocal driver = new ThreadLocal<>();
Doable, but infrastructure-heavy.
Playwright: Playwright's browser contexts are lightweight and isolated - multiple contexts from a single browser instance. Parallel tests don't each need their own browser:
BrowserContext context1 = browser.newContext();
BrowserContext context2 = browser.newContext();
Page page1 = context1.newPage();
Page page2 = context2.newPage();
// Fully isolated, run concurrently
For Java, combining this with JUnit 5's parallel execution support gives you fast, isolated, low-overhead parallel tests without a Grid.
Verdict: Playwright is architecturally better suited for modern parallel testing.
Where Selenium Still Wins
It would be dishonest to write this as a one-sided comparison. Selenium holds real advantages:
Ecosystem maturity: Selenium has been around since 2004. The number of answered Stack Overflow questions, blog posts, frameworks built on top of it (Serenity, Selenide), and team familiarity is unmatched.
Browser support: Selenium supports Safari via SafariDriver and has broader coverage of older browser versions. Playwright supports Chromium, Firefox, and WebKit - but not "real" Safari.
Corporate adoption: If your company already has a Selenium Grid, a library of Page Objects, and a team that knows Selenium deeply, the migration cost is real. I've seen Playwright migration proposals die in sprint planning because the team looked at 800 existing Page Objects and collectively decided it wasn't worth it. That's a valid call. Technical debt you know is safer than a rewrite you don't.
Java documentation: Playwright's Java documentation lags behind its TypeScript documentation. You'll sometimes need to translate TypeScript examples yourself, which adds friction.
When to Choose What
Scenario Recommendation Greenfield project, modern web app Playwright Existing large Selenium suite Selenium (migrate incrementally) Heavy Shadow DOM / Web Components Playwright Need real Safari testing Selenium Flaky test remediation is a priority Playwright Team has zero Playwright exposure Selenium (or invest in ramp-up) Need network mocking without extra tools Playwright Corporate environment with strict registry/proxy Evaluate both - setup friction varies
Final Thoughts
After a decade with Selenium, I don't regret the time I spent with it. It made me understand how browsers and automation actually work. But Playwright's design reflects ten more years of web evolution - and it shows. Auto-waiting, shadow DOM support, network interception, and the browser context model solve problems that Selenium punts to the test author.
For new projects, I'd start with Playwright. For existing Selenium suites, I'd identify the most flake-prone areas, and start replacing those with Playwright - module by module. You don't have to flip the switch overnight.
If I'm being direct - if I were starting a new project tomorrow, I would not choose Selenium. But I also wouldn't rewrite a working suite just because something newer exists. Migration has a cost and 'new' is not a business requirement. But if you haven't given Playwright's Java SDK a serious look yet, now is a good time.
Enjoyed this? I write about Java-based test automation, Playwright, and real-world QA engineering. Follow for more.
Top comments (0)