entirely possible I’m just really bad at this stuff but I can’t get browser agents to do simple report pulls without running into a captcha or a dropdown menu that breaks its brain. hopefully this is the one!
> 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.
How does it handle context bloat between the browser and the llm?
Any plans of exposing more of the browser? For instance playwright is able to store tracing files the agent may decide to read to understand some requests / payloads…
Any plans on allowing the agent to run an arbitrary js script?
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 -- definitely 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)
What’s next 5 years look like given that you are very good at building long-term projects that last and evolve through time? And for a very specific example, what’s the plan for incorporating new standards like Agent Skills as they quickly evolve and launch?
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!
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.
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?
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.
I'd love to be able to lock down the browser to only allow certain URLs (e.g. localhost) so I can give Claude (and other tools) carte blanche to use browser automation (rather than manually approving each command). Is this something on your radar / roadmap?
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!
Neat. Any reason why the MCP server doesn't expose a JavaScript/eval tool? Current models excel at writing JS to drive and inspect the DOM. They aren't great at driving browsers via screenshots.
> 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.)
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.
My use case is mainly to make it easier to show Claude Code a problem with an SPA as I develop it. Claude’s decent at traditional server-rendered stuff, since it can curl and reason a bit about the responses, but SPAs require something more like your tool here.
Hi this looks really valuable, thanks for developing and sharing. Would you share some use cases and how you or your users use it personally? would love to see some examples and feel the aha "That's how I'd like to use it too!" and it would help me drive and se the problems I have as being solvable by this too rather than seeing a tool/solution looking for a problem. (not implying you're that, but without examples/use cases that's the default way I think)
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).
Hey man, just wanted to say thanks for Selenium - it was a game changer and had a big impact on my professional life.
I’m interested in checking out Vibium - I’ve been a reluctant adopter of Playwright and hopeful for a new approach.
Interesting, I've been using this skill https://github.com/SawyerHood/dev-browser to save on context and get some more speed. Will try this out!
yeah, looking to play more with (and support) skills with vibium soon.
big virtual hugs for @hugs... thank you for the Christmas gift of fewer keystrokes :-)
entirely possible I’m just really bad at this stuff but I can’t get browser agents to do simple report pulls without running into a captcha or a dropdown menu that breaks its brain. hopefully this is the one!
As someone who's made a good living primarily in UI automation for over a decade, thank you.
It's been an interesting journey.I do think Playwright is the defacto standard now, but Selenium was the original browser driver.
Anyway, how does Vibium compare to Playwright ? Playwright's main advantage is it has official support for multiple languages.
> 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.
How does it handle context bloat between the browser and the llm?
Any plans of exposing more of the browser? For instance playwright is able to store tracing files the agent may decide to read to understand some requests / payloads…
Any plans on allowing the agent to run an arbitrary js script?
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 -- definitely 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 wasn’t able to gather the future state plans beyond what’s noted in the V2 plans:
https://github.com/VibiumDev/vibium/blob/main/V2-ROADMAP.md
What’s next 5 years look like given that you are very good at building long-term projects that last and evolve through time? And for a very specific example, what’s the plan for incorporating new standards like Agent Skills as they quickly evolve and launch?
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!
Since it's in go, wouldn't it be great if it also expose go api?
This is very cool. We were thinking about doing something very similar with Skyvern
What was the reason you went down this path instead of extending selenium with AI features?
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.
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?
Aside from the project itself, I am learning a lot just from reading the commits. Mostly about the process when one knows how they'd do it.
https://github.com/VibiumDev/vibium/commits/main/?after=ffc3...
My number one question would be how it compares to Playwright -- differences in design goals, capabilities, advantages and disadvantages.
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.
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?
I'd love to be able to lock down the browser to only allow certain URLs (e.g. localhost) so I can give Claude (and other tools) carte blanche to use browser automation (rather than manually approving each command). Is this something on your radar / roadmap?
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
Thank you for the links / info! I'm looking forward to digging into this.
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.
Neat. Any reason why the MCP server doesn't expose a JavaScript/eval tool? Current models excel at writing JS to drive and inspect the DOM. They aren't great at driving browsers via screenshots.
> 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...
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.
How do you install it into Claude Desktop? I tried the following, but it fails.
Nice. I was just thinking of building this very thing. Glad to see I won’t have to. I’ll check it out after the holidays.
what specific things were you looking for?
My use case is mainly to make it easier to show Claude Code a problem with an SPA as I develop it. Claude’s decent at traditional server-rendered stuff, since it can curl and reason a bit about the responses, but SPAs require something more like your tool here.
You might try Google Antigravity since it is natively designed to test in the browser as it codes.
What is the benefit of using this instead of playwright?
Hi this looks really valuable, thanks for developing and sharing. Would you share some use cases and how you or your users use it personally? would love to see some examples and feel the aha "That's how I'd like to use it too!" and it would help me drive and se the problems I have as being solvable by this too rather than seeing a tool/solution looking for a problem. (not implying you're that, but without examples/use cases that's the default way I think)
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).