What does Playwright do that Selenium can't do?

It's just nicer to work with.

I'm pretty sure they have equivalent (or very close to that) functionality, in that anything you can do in Playwright can be expressed in Selenium and vice-versa.

But Playwright, from my experience, is much easier to use. The documentation is more comprehensive, and the API design is much more aligned with the kind of things I want to get done.

This is because Playwright has benefited from decades of experience in the space which started with Selenium. The engineers behind Playwright previously built Puppeteer, which was itself an evolution of ideas from Selenium.

Playwright can run tests in multiple windows as well as tests that cross multiple domain origins. My team builds a collaborative app where we wanted to cover scenarios where two different users collaborated on the same page. This was easy to implement in Playwright, in Cypress it is not possible. We can open two browser windows with Playwright and simulate two or more users simultaneously editing a page.

Also Playwright is a general browser automation tool and can be used for more things than just testing. For example, scraping website data or generating preview thumbnails for URLs.

Selenium can definitely run tests in multiple windows.

You can open multiple tabs within the same browser window, or you can create multiple WebDriver instances for multiple windows.

Fair point. Cypress cannot, the initiator of this comment thread context asked what Selenium can’t do that Playwright can, but my brain misred this as “Cypress”. Sorry about that.

Are there any good tutorials out there for using Playwright for scraping? Never tried it but I have a need right now.

The main difference is that Playwright uses custom headless builds of "browser projects" (like chromium) rather than attempting to automate a normal consumer build of the browser via the webdriver api. The webdriver api is kind of slow, browsers don't always implement it well, and it doesn't have a good mechanism for the browser to push events back to the test application which ends up requiring selenium to do a lot of polling for changes so it can miss events that happen quickly.

> The main difference is that Playwright uses custom headless builds of "browser projects" (like chromium) rather than attempting to automate a normal consumer build of the browser via the webdriver api.

I think you're wrong there. See [1].

It doesn't use custom browser builds, but specific versions of official builds of mainstream unbranded browsers (you can also use branded ones if you wish). There are no "custom headless builds". All browsers support headless mode, and you can use it on your main browser by passing a CLI flag.

The reason it officially supports only specific versions is because there may be slight incompatibilities with the Chrome DevTools Protocol in each browser version, so they suggest running supported versions only. But like a sibling comment mentioned, you can also connect it to any existing browser instance, and, assuming there are no CDP incompatibilities, it will likely work.

[1]: https://playwright.dev/docs/browsers

Events are the bane of automation existence.

Back in Windows-heavyweight app land, it made way more sense to interpose a low overhead shim to intercept and copy events.

I can't imagine the pain you'd encounter trying to paper over the other way around.

> Events are the bane of automation existence.

They do make some tasks tricky to handle, like tracking state, or avoiding race conditions, but in reality events are a good fit for interacting with browser DOM events, representing browser activity, and being able to react to it.

Consider the complexity of an average modern web site, that loads dozens of scripts, uses a frontend framework, is highly dynamic and interactive (likely a SPA), contains multiple frames, etc. All of this happens concurrently, and the only abstraction that makes sense to represent it is an event-based system. You can't achieve the same level of responsiveness using a traditional request/response protocol.

This is why modern browser automation protocols are event-based, and built on top of WebSocket. Selenium is pushing for WebDriver BiDi, while the browser standard is the Chrome DevTools Protocol.

That wasn't an argument against events! It was an argument against the futility of not being able to sit in the middle (-ing) of them, for automation.

Ah, apologies, I misread.

Fully agree then. The only sane way to handle browser automation is by exposing all of them.

Does it have a mode where it can drive a real browser? Most real-world UI test matrixes for web apps want the tests run on their real targets for any final acceptance. "Fake" headless browsers tend to be more useful for first-tier CI and just keeping tests warm.

If it can only drive its internal browser engine, that'd possibly be a big argument against it for any test strategy I was architecting. I'd want the tests to be portable and usable cross-browser for acceptance--particularly UI-driven E2E tests, since that's really the only time they are critical.

Playwright does use "real" web browsers (Chromium, Firefox, WebKit). It just supports specific versions, as otherwise it would be difficult to maintain. It runs them in headless mode, which most browsers support, and should behave exactly as a headed version would. You can start a test in headed mode if you want to see the browser window.

The era of custom headless browsers like PhantomJS, or Selenium/WebDriver for that matter, is dead, IMO. The Chrome DevTools Protocol is the modern standard API to interact with a browser programmatically.

Oh, OK! I misunderstood the comment entirely then. Thanks for correcting me there, especially since I was apparently too lazy to look for myself.

This does sound more promising then, if they've found new ways to add maintainability or QoL aspects to record/replay. As I said elsewhere, I think r/r gets a bad rap, and those sorts of improvements would increase the number of situations where it makes sense (at least for testing in incubation).

I think the mistake was in the comment you replied to, that suggested Playwright used custom browser builds.

I do recommend giving it a try. The web browser automation landscape is much more reliable these days for writing E2E tests than back when Selenium was state of the art.

Yep, it’s just a matter of setting headless=false and it can launch a normal firefox/safari/chromium exe. You can even have it attach to an existing instance of your personal browser (via the debugging protocol).

Funny this popped up...I've been looking at replacing our slow and flaky Selenium test suite recently.

From what I can tell here are the benefits:

* With Playwright you don't need to put manual waits in your program. It's async.

* You also don't need to keep updating the Selenium.Webdriver to stay in sync with your browser version. This is a 15-20 minute time sink each time it happens.

* Can run in headless mode which will run the test suite much faster than selenium.

* Also appears to have better command line options to be run from a CI/CD environment

selenium also supports headless mode though, or is playwright's one different?

Selenium supports things like waiting till an element is clickable?

The webdriver issue is definitely annoying though. Not sure if there's a better way, but we're using a binary regex on the electron app in question to find a matching version and download it on the fly as part of test setup.

> With Playwright you don't need to put manual waits in your program. It's async.

That is just choosing between a blocking method or... a blocking method which suspends and resumes a thread.

> headless mode

That is really up to the browser driver to implement that, and you can do that perfectly fine in Selenium.

Run inside a container with near zero effort for CI pipelines

The author says the killer feature is:

> Playwright "records" your steps and even gives you a running Python script you can just directly use (or extract parts from). I'm serious about the running part- I can literally record a few steps and I will have a script I can then run with zero changes.

Does Selenium have that ?

Selenium IDE does, although it is much easier to do in Playwright IMO. I think there is honestly no contest now between selenium and playwright for most needs; I wouldn't ever go back to Selenium. If you are starting a brand new project today in Selenium, I honestly think that is foolish given the better alternatives now out there. Selenium was a great project, but it is strangled by its own success - very hard to meaningfully redesign its API now so much of it is in legacy projects who will want to update their dependencies one day.

However, regardless of the tech used, recording playback of HTML manipulation is pretty brittle - if you think adopting playwright because it has a record feature will save any kind of time/effort/money, you are in for a surprise. This is a feature everyone tries once and goes "wow, neat!" and then quickly realizes none of the suggested code is production ready, or even likely to work on a 2nd run for anything other than the most basic of static sites.

Is stable and reliable

Selenium sucks

Auto-waiting.