Is the case for playwright over puppeteer just in it's crossbrowser support?

We're currently using Cypress for some automated testing on a recent project and its extremely brittle. Considering moving to playwright or puppeteer but not sure if that will fix the brittleness.

▲

rising-sky 5 days ago | parent | next [-]

In my experience Playwright provided a much more stable or reliable experience with multiple browser support and asynchronous operations (which is the entire point) over Puppeteer. ymmv

▲

nikisweeting 5 days ago | parent | prev | next [-]

I would definitely recommend puppeteer if you can, it's maintained by the Chrome team and always does things the "approved way". The only reason we did playwright is because we're a python library and pyppeteer was abandoned.

▲

cebert 5 days ago | parent [-]

Most of the Puppeteer team left and joined Playwright under Microsoft.

▲

nikisweeting 5 days ago | parent [-]

While that is the origin story of Playwright in 2020, that's no longer really true. Puppeteer is alive and well and arguably moving faster than Playwright these days because it's updated in lockstep with https://github.com/ChromeDevTools/devtools-frontend

	▲	tbrockman 5 days ago \| parent [-]
		Also recently found it unnecessarily difficult to do profiling of page workers using Playwright's CDPSession wrapper (and they don't seem to have any plans to improve it: https://github.com/microsoft/playwright/issues/22992#issueco...), whereas it was pretty painless in Puppeteer. So, definitely more useful if you care about more than just your main thread.

▲

jonkoops 5 days ago | parent | prev | next [-]

I have converted several large E2E test suites from Cypress to Playwright, and I can vouch that it is the better option. Cypress seems to work well at first, but it is extremely legacy heavy, its API is convoluted and unintuitive, and stacks a bunch of libraries/frameworks together. In comparison, Playwright's API is much more intuitive, yes you must 'await' a lot, but it is a lot easier to handle side effects (e.g. making API calls), it can all just be promises.

It is also just really easy to write a performant test suite with Playwright, it is easy to parallelize, which is terrible in Cypress, almost intentionally so to sell their cloud products, which you do not need. The way Playwright works just feels more intuitive and stable to me.

▲

arm32 5 days ago | parent | prev | next [-]

Playwright also offers nice sugar like HTML test reports and trace viewing.

▲

gregpr07 5 days ago | parent [-]

From my experience with Playwright RR-Web recordings are MUCH better than Playwright’s replay traces, so we usually just use those.

▲

epolanski 5 days ago | parent [-]

What's RR web?

▲

nikisweeting 5 days ago | parent [-]

https://github.com/rrweb-io/rrweb

▲

jonkoops 5 days ago | parent [-]

That can be integrated with Playwright, or did you mean to say it is already used under the hood for their reports?

	▲	nikisweeting 5 days ago \| parent [-]
		Gregor was saying it works without needing playwright, and provides more detailed trace recordings than playwright does. we plan to use rr-web and maybe browsertrix for our website archival / replay system for deterministic evals.

▲

benoau 5 days ago | parent | prev [-]

They're all brittle in my experience but Playwright has a lovely test recorder and test runner which is also integrated into VSCode, and it tidies up a lot of the exceptions that would occur in puppeteer if the page state wasn't meticulously-ready for some operation.

Playwright's "trace" viewer is also fantastic providing periodic snapshots and performance debugging.