[hugs]

i partially addressed this in the "why vibium" section of the v1 announcement: https://github.com/VibiumDev/vibium/blob/main/docs/updates/2...

but why a new thing vs extending selenium? it's a little complicated, but neither selenium nor playwright were designed with ai in mind from day 1. with vibium, i'm optimizing for "vibe coding" and ai-driven workflows first.

[suchintan]

This makes sense. I guess I wanted to understand why starting from scratch was better than "fixing" selenium, but perhaps "fixing" selenium isn't an option?

[hugs]

for the entire testing tools industry, in some ways, selenium was the "final boss" to beat. every new tool had to trash selenium in their marketing. eventually those "hit points" added up. "fixing selenium" is as much as of a branding problem as it is a technical problem. "oh, there's a new version of selenium? i heard selenium sucks!" is actually a problem that has to be dealt with. an entire new generation of coders only know "playwright rules, selenium drools".

of course, i have a new host of problems by going all in with "vibium"... i'm making a huge bet that "vibe coding" is a trend, not a fad. (it could still be a fad! we'll see if this post ages well soon enough!)

[gsnedders]

Also, as someone on the periphery of Selenium (mostly via WebDriver), some of the challenge is that Selenium has a huge amount of test code already written for it — and making radical API changes would break every test already written for it, and at that point you’re effectively a new library.

It’s gonna be very interesting to watch exactly how the adoption of WebDriver BiDi goes with Selenium, especially once WebDriver Classic starts to go away, and how API stability is balanced with exposing more and more async capabilities.

[suchintan]

That makes a lot of sense. Sometimes it's easier to leave the baggage behind. It's too bad..selenium is a masterpiece. Thanks for sharing it with the world