hugs

no kidding. it was the last demo in the video, but my first reaction seeing the zippers-instead-tent-poles demo was, "oh, that's going to be huge." weight and "how well does it handle wind?" are concerns, but i could totally see "100% zipper" tents on the market by the end of the year.

since the rise of agentic coding tools, it feels like we're in a new "eternal september" of people discovering ui end-to-end test automation.

not many people talk about mapquest anymore.

have you tried vibium's cli + agent skill?

some serious people use vibium instead. (full-disclosure: "some serious people" is me.)

that is the MCP vs CLI debate.

i wish more people knew or cared about web standards vs proprietary protocols. the webdriver bidi protocol took the good parts of cdp and made it a w3c standard, but no one knows about it. some of the people who do know about it, find one thing they don't like and give up. let's not keep giving megacorporations outsized influence and control over the web and the tools we use with it. let's celebrate standards and make them awesome.

most people just click the "internet" button and use whatever was already pre-installed.

they probably meant desktop. i do browser test automation (selenium, vibium), and the lack of google chrome on arm64 trips up new users frequently. the workaround is to just use chromium, but that's a confusing extra step for some if it's not automated and hidden for you.

on that note, it would have been nice if they also clarified if this means they'll be shipping an official "chrome for testing" for arm64 linux, too.

hi, i'm jason huggins (selenium, appium, now vibium). browser automation and testing have been my jam for a long time. for most of that time, it would be fair to say browser automation was an often forgotten and overlooked corner of the tech landscape. with vibe/agentic coding, things have changed.

the folks at kernel reached out a few weeks ago about adding support for vibium and webdriver bidi on their service. it's now live on kernel.sh's crazy-fast-browsers-as-a-service.

ama!

openclaw is the napster of itunes.

people who have been around long enough know that we're currently in the wild west of networked agentic systems. it's an exciting time to build and explore. (just like napster and early digital music.) eventually some big company will come along and pave the cow paths and make everything safe and secure. but the people who will actually deliver that are likely playing with openclaw (and openclaw-like systems) now.

possibly also a boon for automated testing tools and infra designed for ai-driven coding.

not mozilla-related, but there's also the ladybird project if you're looking for sustainable alternatives: https://ladybird.org/

vibium clicker, too. https://github.com/VibiumDev/vibium/blob/main/CONTRIBUTING.m...

"browser automation for ai agents" is a popular idea these days.

ignore the haters. this is cool. (and i've been vibe coding with claude code and termux for months. it's good stuff.)

i would highly recommend you add guidance on automated data backups, though. my pixel phone went "black screen of death" on me and one of my projects is trapped in there until i can replace the screen.

claude code 100%

i'm vibe coding vibium, a test automation tool in the spirit of playwright and selenium. (was #1 on hn last week for a little bit with a lively discussion.)

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

thanks!

it's named vibium for a reason.

google fell victim to one of the classic blunders. the most famous of which is inventing the transformer behind gpt but not productizing it first. but only slightly less well-known is this: letting puppeteer go without a plan.

i started the selenium project as just a js and python thing. but it got really popular in java circles.

vibium will also be a big tent project and support ts/js, python, java, and as many other languages we can support, too. but i started with ts/js because that's what's extremely popular right now. (and i like js!)

(side-note: i f'ing love nim, we will be supporting nim, too. getting nim on the tiobe top 20 is on my bucket list.)

it's just v1. good for experimenting, not for production (yet!).

and yes, it's perhaps impolite and silently taboo for me to say it out loud, but "not being controlled by microsoft" is on the top 10 list of "why vibium and not playwright". most of the sf world has gone all-in on playwright; i'm betting on web standards. i hope people will notice that distinction. however, i realize vibium can't win just as the "not microsoft" option; it will also need to win on the merits.

microsoft is already incredibly well-positioned to own the whole dev stack. from their investment in openai to vscode, github, and playwright... they are in a powerful position. i'm old enough to remember the last time ms had massive power over the stack (see: internet explorer 6).

which local models? (e.g. qwen, llama, mistral?)

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

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.

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.

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.

have plans for new year's eve?

100% yes. favorites?