[lmiller1990]

Hi! I'll try to speak to this a bit. Disclaimer: I work on Cypress.

The main reason there are lots of articles about Playwright is it's newer and solves some issues people have with E2E testing in Cypress (like multi-tab support) and is more idiomatic JS (using async/await instead of how Cypress does it, which is waiting for each `cy` command to finish before running the next one (it queues them up and runs each one sequentially, so await/async isn't required)).

Cypress has also invested heavily in the developer experience; it has a UI that shows all the commands that executed, and lets you do "time travel" debugging, where you can go back and see the state of the test/DOM after each Cypress command ran. From what I can tell, Playwright is more focused being a solid, cross browser automation tool first. I'm not aware of any kind of interface that exists that is similar to Cypress (I haven't kept up; it's possible something similar exists).

As far as the tools go, Cypress has a lot of opinions and recommendations about how best to use the tool; Playwright seems less opinionated. Some people like tools that come with a lot of guide rails; other people prefer to take a tool and use it how they want.

Another thing to consider is target user; a lot of JS engineers who understand async/await well will have no problem with Playwright; some QA engineers I've worked with who don't come from a JS background found the Cypress API more intuitive.

To answer your original question "What are some good reasons to use Cypress over Playwright in a new project" - I think if you value the Cypress interact runner with the snapshots and command log, or if you value the style of test that the Cypress API encourages (take a look at API) it's a good choice. If you prefer a less opinionated tool, or you value certain features Cypress doesn't have (multi-tab, etc) Playwright might be a better fit.

[_ot2g]

I like Cypress. However, every response from Cypress team about async/await vs cy chaining feels like it comes from a place of defending a sunk cost, rather than than advocating for the best API. It would be hard for Cypress to change the API now because it would likely result in a loss of a large portion of the current user base. I doubt Cypress team would design the API this way if they started again today.

[lmiller1990]

Again disclaimer - I work on Cypress, but I think I can speak objectively, as I was user for many years prior to joining.

> ... defending a sunk cost, rather than than advocating for the best API ...

If you really go all-in on the Cypress API, writing custom commands, etc, not having to mess around with async/await is really nice. It's a strong point for onboarding QA devs, who might not be familiar with JS, Promises etc. This is also one of the major drawbacks - for any proficient JS devs, who are used to async/await and the usual business, the obvious question is "why isn't this just standard JS?". I definitely had the same feeling when I first starting writing Cypress tests.

> It would be hard for Cypress to change the API now ... I doubt Cypress team would design the API this way if they started again today ...

I am not sure of the technical complexity or priority of decoupling Cypress from the Chainable API. I'd assume the complexity is not supporting async/await, but supporting it alongside the current API.

I think the ideal case would be loosening the coupling between all the parts of Cypress, that would allow someone (either the Cypress team or a third party) to write their own selecting/assertion API, and they could then optionally write it with chaining, async/await, or something else. Perhaps even create bindings for another language (currently Cypress is JS only, since a lot of the code executes in the browser, unlike Playwright, where everything is via the CDP - another example where one of the main strengths of Cypress can also be a weakness).

Hopefully this gives you some more context and insight! My goal is better testing tools for the web, I think both Cypress and Playwright are solving this problem in different ways with a different philosophy. I'm glad to see so much innovation in the space, I hope we can keep pushing things forward.