playwright got a lot of things right. one of the big ones was a fast websockets+json way to drive the browser. (vibium is using the w3c standard equivalent - webdriver bidi). but they also raised the bar on usability and developer experience. i hope to get to the level of "click, click, awesome" out-of-the-box experience that playwright did so well.

If you're already using Playwright, I'd love for you to give Stagehand a try (https://github.com/browserbase/stagehand) - it has compatible-ish API, but built for automation, not testing.

> I’ve been a reluctant adopter of Playwright and hopeful for a new approach.

Out of curiosity, why?

Personally, I'm a massive lover of playwright. Flakiness has been so much lower for us.

I think the future is mobile when it comes AI agents, If you are also looking for a new approach, I would suggest DeepWalker. It is mobile first automation, currently works on android.

[0]: https://deepwalker.xyz

> inject js, modify the DOM, and most crucially monitor/modify network requests

not yet. definitely on the roadmap, though. goal is to embrace what playwright has done well, then extend what's possible...

all i want is monitored network requests, because flutter + amazon appsync apps are so radioactive

> I do think Playwright is the defacto standard now

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.

You might also want to look into Stagewright.

Any idea how did Puppeteer lose the race?

yeah, looking to play more with (and support) skills with vibium soon.

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.

If using Claude Code, a simple hook can govern `browser_navigate` (mcp)

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

fully aware of the "blast radius" risk of using claude to do stuff. i'm doing all my vibium dev in a vm using UTM (and you should, too!). wonder if there are some network rules we can add.

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

As I see it, the only real solution is to put it into a container that has a firewall with a short whitelist.

Maybe this is something: https://github.com/vibheksoni/stealth-browser-mcp

i definitely have plans to expose more of the browser! at the moment, it's very limited. i'm not sure if anyone has completely nailed the context bloat problem -- it's worth more study and benchmarking. i suspect the long term answer is "don't use mcp". but mcp (warts and all) felt like a table-stakes feature for a v1 release.

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)

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.

likewise, watching it take shape in real time is fascinating

thanks. if ai-assisted development is the future of software (and i think it is), it was important i put my money where my mouth is and develop it by doing exactly that.

For right now, the MCP server doesn’t expose quite enough to navigate on its own.

I’ve added a browser_evaluate tool in my fork—though I haven’t committed or pushed a PR yet. With that, the agent can call JavaScript to get the accessibility tree and then use that to navigate via browser_find.

This and much more will be coming soon. See the V2 roadmap for more insight: https://github.com/VibiumDev/vibium/blob/main/V2-ROADMAP.md

short term: yeah, we should totally add agent skills asap! new year's eve goal?

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!

lots of people have already been posting examples of how they used vibium on linkedin. (code's only been available for a day or two, so we're just getting started!)

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).

thanks for using it! <heart-emoji/>

i try to say this often, but it never feels like enough: yes, i started the project, but it's a relay race. i ran the first few laps, but the project has been going for 21 years now. there's dozens (hundreds?) of people to thank at this point for the success and impact that the selenium project has achieved.

thanks!

i apologize, but i'll answer your question with a metaphor.

i want to build an island resort and a bridge from the mainland to get there. do i build the island resort first or the bridge first?

here's my thinking: if the resort is popular and a fun place to be, there will be a huge incentive to build the bridge next. but we might also find out that building the bridge will ultimately be economically impractical and we should just stick to using ferry boats. at least we'll have a cool island resort to go to, though!

so for now, i'm just focusing on building the island resort at the moment. but i really, really want to build that bridge, too, asap.

what specific things were you looking for?

there's generally only 3 ways to make money in browser automation:

1) test automation (my specialty)

2) data scraping / crawling

3) business/robotic process automation (e.g. back-office data entry, processing invoices, etc.)

when it comes to handling login sessions, cookies, etc. test automation is the easiest. (you create disposable test logins and use them in each test. it's mostly a solved problem.)

handling logins is a way gnarlier problem in data scraping and business process automation. i'm focused on test automation in v1. (i'm hoping experts in data scraping and process automation can help me improve vibium in this regard.)

"vibium": {

"command": "npx",

"args": [

"-y",

"vibium"

]

}

source: https://www.linkedin.com/posts/apzal-bahin_ai-mcp-browseraut...

FWIW, if you have Claude Code or the like, you can quickly prompt your way to an eval function in MCP. It already exists in clicker and the client API. You can use it to get the accessibility tree, for example, and use that to find what to fill out and click.

> why the MCP server doesn't expose a JavaScript/eval tool?

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...

good security will always be the eternal enemy of easy automation.

short-term mediation is always always always run it in a virtual machine with as minimal credentials as possible.

- No LLM Getting Started with Vibium (beginner-friendly): https://github.com/VibiumDev/vibium/blob/main/docs/tutorials...

- MCP option (where tokens will eventually get burned) Getting Started with Vibium MCP: https://github.com/VibiumDev/vibium/blob/main/docs/tutorials...

python client coming soon to PyPi

have plans for new year's eve?

yes, yes it would!

100% yes. favorites?

I thought about it as well. Might do it at some point.

not today. but the plan is to be very "big tent" and support as many options as possible.

it will be more obvious in v2.

v1 is about getting to a base-line of functionality.

things get interesting in v2: https://github.com/VibiumDev/vibium/blob/main/V2-ROADMAP.md