This is highly opinionated, but I have been using and teaching how to use Selenium and Appium for a few years so that is unavoidable :) I would say the pros of Puppeteer & Playwright:
- generally higher speed
- higher reliability (specifically lower base false-positive rate)
These are mainly due to architectural choices (less moving parts between script and browser).
That being said, Selenium has been the open-source standard in cross-browser testing for a long time now, and is more polished and feature-rich. Also, multi-language support makes it an easier choice for non-JS teams. I would suggest a quick hands-on POC if you want to use these tools in a project.
Hey, I work on browserless.io, which supports both puppeteer and selenium.
Selenium uses a chatty HTTP interface, whereas puppeteer/playwright use WebSockets or pipes to communicate. Under-the-hood, however, Selenium is simply using chrome's devtools protocol to communicate with it. The way selenium does this is by another binary, generally a `driver`, that has the protocol "baked" into it and has the HTTP selenium API as its input interface.
This is all a long way of saying that puppeteer/playwright have a lot less moving parts, and are generally more approachable. Selenium _does_ have a lot more history behind it, better support across languages and frameworks, and is more stable but it's also much larger and "clunkier" feeling. It's also a lot harder to scale with load-balancers since, again, it's all over HTTP so you'll need some way to load-balance with sticky sessions.
Practically speaking they all do the same thing at some layer. Both are high-level APIs around the devtools protocol, it's just what higher-level interface you prefer and what your language/runtime is.
^^ All of this. I work for Sauce Labs; We've been pretty focused around Selenium but we're building out support for Puppeteer, Playwrite, Cypress et al.
The newer automation tools benefit from being newer; They can take advantage of hardened, well designed interfaces (like the Dev Tool protocol). Selenium's been around for a bit longer, and was built when browsers didn't make it easy to control them. That's influenced the semantics of Selenium quite a lot, as well as explaining the extra moving parts (Drivers exist to map the Selenium Wire Protocol (or W3C protocol) to whatever they're driving because Selenium wasn't built with a specific browser in mind).
I feel like, at this point in time, the real difference is how much abstraction you want from the browser. Selenium is a set of knives, Puppeteer is a Die Cutter. You'll put in more work with Selenium, but maybe you need something do happen a REALLY specific way. Or, you might just need shapes cut, and Puppeteer will be more reliable and faster.
Seems like this doesn't support anything but Chrome/Chromium?
Edit: I was kind of wrong already and it seems I will be completely wrong soon. Which is good in this case :-) As hlenke points out below Firefox support is on its way :-)
tl;dr: Better ergonomics, faster, more reliable and more coverage of web platform.
* The Playwright API auto-waits for the right conditions on every action on the page (click, fill). This ensures automation scripts are concise to write and maintain over time.[1]
* Unlike Selenium, Playwright uses an bi-directional channel between the browser and automation script. This channel is used to listen to events from the browser (like page "load" event, network requests). These events enable Playwright scripts to be precise about browser state and prevent the need to rely on sleeps/timeouts, which contribute to flakiness of Selenium scripts. This is also exposed in the API, for more powerful automation[2].
* Playwright also has a wider coverage for modern browser features, including device emulation, web workers, shadow DOM, geolocation, and permissions.
