My number one question would be how it compares to Playwright -- differences in design goals, capabilities, advantages and disadvantages.

▲

hugs 13 hours ago | parent [-]

it's a good questionn! i partially addressed this in the "why vibium" section of the v1 announcement: https://github.com/VibiumDev/vibium/blob/main/docs/updates/2...

to save a click, i'll post it here, too:

-----------

why vibium?

there are dozens of "ai-powered browser" tools now. so why this one?

the selenium ecosystem is massive: millions of tests, thousands of companies, decades of investment. but there's no obvious bridge to the ai future. many have moved to playwright — and for good reason: it's fast, easy to use, has popular features like auto-waiting, integrated video recording, and a ton of other batteries included.

vibium takes the same approach. batteries included. great dx. but built for where the industry is going: ai agents that need to drive browsers.

when i did those interviews in september, the response wasn't just "cool idea." it was relief. the community trusts us to build this bridge because we built the last two: selenium in 2004, appium in 2012.

community and ecosystem are the moat.

▲

anamexis 13 hours ago | parent [-]

Thanks! I don't think it really answers my question though.

AFAIK Playwright also takes the approach of batteries included, great dx, and has a lot of good integration with AI agents.

Basically, what sets Vibium apart?

▲

therunninglight 11 hours ago | parent [-]

vibium is hardly 2 days old. the 5-yr plan is grand. quoting hugs "goal is to embrace what playwright has done well, then extend what's possible".

▲

anamexis 4 hours ago | parent [-]

I appreciate that it's brand new, but I'm still very interested in knowing about what sets it apart, even if that is all just vision at this point. What does "extending what's possible" mean?

	▲	hugs an hour ago \| parent [-]
		i appreciate the persistence in getting an answer. :-) i was being a little too cute using "embrace" and "extend" in a previous comment (look up "embrace, extend, extinguish"). sorry about that. the big idea with vibium in v2 and beyond is to bring to test automation something old and boring in robotics: the "sense - think - act" loop. sensors observe the world, a brain makes decisions, and actuators carry them out. right now most browser tools extend what's possible at the "act" layer. they make it easier for an llm to click, type, and observe the browser. that's useful, but it mostly enables one-off demos. every run starts from scratch. there's no accumulated understanding of the app, and long workflows are navigated by guessing and retries. what vibium is trying to extend is not just action, but the loop. vibium v1 is just the "act" part, which i'm calling clicker. it clicks buttons, types, and navigates the browser. retina and cortex are coming in v2. retina turns real interaction into durable signal (manual exploration, existing tests, production usage). cortex builds on that signal to create a navigable model of workflows that an llm can plan through, instead of reasoning from raw html each time. clicker is the execution layer. playwright mcp largely lives here. vibium clicker overlaps in scope, but is designed from the start to feed sensing and planning rather than being the whole system. so yes, playwright mcp covers part of this. what's missing today is first-class sense and think. that's the gap vibium is exploring, even if v1 only ships the act layer. tl;dr: sense -> retina (v2) think -> cortex (v2) act -> clicker (v1) i've spent the past few months talking about applying the "sense - think - act" loop to browser automation, but at some point i realized i needed to "talk less, ship more". :-) i'm looking forward to shipping retina and cortex so we can see whether the full loop is actually a step change beyond what playwright or playwright+mcp can do. happy to dig deeper if helpful.