Looks like a bot incorrectly flagged this?
Yup, antispam measures, sadly.
It is listed now!
Nice! I always thought Selenium testing would in theory be something Haskell is excellent at. It benefits from abstractions and composability and stuff. But whenever I tried it in the past it was rough around the edges (not just because Selenium tests can be finicky)
It’s been over 10 years since I last worked with selenium, in using playwright at work, with a bit of puppeteer before playwright was a thing.All of this in python sadly, but being able to drive the browser from the same language as the rest of the code is really nice.
Does somebody have enough experience to compare playwright and webdriver in its current state for browser testing web applications? In my vague memories, selenium tended to be super flaky with waits and so on, but I’d be very interested to hear how things are nowadays
I’ve used both and they are apples and oranges. Selenium is lower level just for driving browsers where as playwright is a whole framework, including tracing and emulators and now even an MCP server. If you are using selenium or communicating directly with WebDriver client you will end up building your own utilities on top it, or using someone else’s (like webdriver-io in the typescript world).
Also Playwright uses a socket connection vs Webdriver using an http connection but the WebDriver BiDI standard which is under development, is changing that.
Generally I prefer webdriver because the way I like to build such automation suites doesn’t fully align with playwright but I am guessing I’d be an outlier. Playwright has a lot momentum, and some of the bells and whistles are pretty cool (particularly tracing). If you an inexperienced team, which many teams doing QA automation are, they are far more likely to shoot themselves in the foot using Selenium directly than using a full blown framework like playwright.