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.

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.

A custom sh script or something for whitelists would take ~5min to setup.

For more robust governance (many policies), you can write Rego using https://github.com/eqtylab/cupcake

https://code.claude.com/docs/en/hooks#mcp-tool-naming

i did post a v2 roadmap on the github repo. might be time to start the draft for v3!

we also have a new discord server for the project that we just spun up and will be opening up more widely soon. discord could be a good place to share uses cases and experiments until we set up a more formal website structure).

as far as long term plans go, i like the tim o'reilly quote: "create more value than you capture".

with selenium, we created an entire ecosystem of tools, users, companies, and economic activity. (literally billions of usd -- it's a story frequently ignored by the tech press when looking for "open source success stories".) but i hope to do the same with vibium. there will likely be a hosted "vibium.cloud" hosted service. i also hope there will be lots of them. in a similar way, there weren't many "hosted selenium" services when i started sauce labs. now there's a bunch. browserstack, lambdatest, etc.

it was also not really an accident we did that with selenium. there is a lot of behind-the-scenes consensus building that happens to make things like a w3c webdriver standard happen. (funfact: vibium relies on the new! w3c standard "webdriver bidi" protocol heavily inspired by the chrome devtools protocol used by playwright. (tl;dr: it's just json over websockets.)

i'm betting on industry cooperation, standards, and shared prosperity. that's my 5 year plan!

also need to clarify: there are two apis exposed right now: the mcp server and a "plain old" js/ts api. the js/api does have the ability to run arbitrary js. theoretically, you could ask an agent to write a vibium script with the js/ts library, and have the ai run that... (which ironically? is also a way to deal with the issue of context bloat)

no reason other than my number #1 goal was "ship something". i only started the actual coding on dec 11. it's been a bit of a sprint the last two weeks!

though "image-based" vs "dom-based" testing approaches is a very big topic! (look forward to researching that more in the future.)

v1 announcement: https://github.com/VibiumDev/vibium/blob/main/docs/updates/2...

i'll politely pushback a little. i think it's safe (at this moment in time) to say: playwright wins the first derivative, but selenium wins the "area under the curve". selenium is very entrenched in many parts of the world, especially outside of SF/USA. part of the inbound interest i've been getting for vibium is from those selenium users who want some kind of bridge to the future, but didn't have an obvious path forward beyond "dump selenium, adopt playwright"...

part of my plan with vibium post-v1 is to give that massive (and it truly is massive, i'm not bragging) installed base of selenium users an upgrade path to more agentic coding options.