In short: support for WebKit (to test Safari), out-of-process automation (not constrained by scope of in-page JavaScript, for example, to test multiple pages/frames/domains), support for non-JS language bindings. For a more comprehensive list, check out "Why Playwright?"[1].
Thanks for the feedback! I'm on the Playwright team.
We are building playwright-runner[1] to solve this problem. We are dogfooding the project internally, and a few weeks away from opening it up to early adopters.
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.
- Banning TikTok would move traffic to Instagram, not a “local Indian entrepreneur”
- the Indian startup ecosystem is dependent on external capital, a lot of which comes from China. This protectionist attitude will lead to a overall negative sentiment about investing in Indian tech.