A deep dive into the new browser automation framework from the creator of Selenium

Introduction

In December 2025, the browser automation community witnessed a significant moment: Jason Huggins, the creator of Selenium (which he started 21 years ago), announced Vibium—a modern browser automation framework designed from the ground up with AI agents in mind. The announcement on Hacker News sparked a vibrant discussion about the future of browser automation, the evolution from Selenium to Playwright, and what comes next.

This blog post synthesizes the key insights from that discussion, exploring Vibium’s architecture, design philosophy, and its potential impact on the browser automation landscape.

The Genesis: From Selenium to Vibium

The Selenium Legacy

Selenium, created in 2004, revolutionized browser automation and became the de facto standard for web testing. However, as Huggins himself noted in the discussion, “i started the selenium project 21 years ago. vibium is what i’d build if i started over today with ai agents in mind.”

The world has changed dramatically since Selenium’s inception:

• AI agents are now a primary use case for browser automation
• Web standards have evolved (WebDriver BiDi is now a W3C standard)
• Developer expectations have shifted toward better developer experience
• The ecosystem has fragmented between Selenium, Playwright, and Puppeteer

The Playwright Context

The discussion revealed an interesting dynamic: while Playwright has gained significant traction, especially in startup ecosystems, Selenium maintains a massive installed base globally. As Huggins put it: “playwright wins the first derivative, but selenium wins the ‘area under the curve’.”

This observation highlights a critical gap: many Selenium users want a path forward that doesn’t require completely abandoning their existing infrastructure. Vibium aims to bridge this gap.

Vibium’s Architecture: Modern by Design

Go Binary Under the Hood

Vibium uses a Go binary (internally called “clicker”) that handles the low-level browser communication. This design choice provides several advantages:

1. Performance: Go’s compiled nature offers better performance than interpreted languages
2. Cross-platform: Single binary deployment across platforms
3. Simplicity: Developers never see the binary—it’s abstracted away

As Huggins explained: “go binary under the hood (handles browser, bidi, mcp) but devs never see it. just npm install vibium.”

WebDriver BiDi: Betting on Standards

One of Vibium’s most significant architectural decisions is using WebDriver BiDi (Browser Automation Protocol), the W3C standard for browser automation. This contrasts with Playwright’s proprietary protocol.

Why this matters:

• Standards compliance: Built on open web standards, not proprietary protocols
• Future-proofing: W3C standards provide long-term stability
• Vendor independence: Not tied to a single company’s roadmap

Huggins explicitly stated: “most of the sf world has gone all-in on playwright; i’m betting on web standards.”

MCP Integration: Built for AI Agents

Vibium includes native support for the Model Context Protocol (MCP), enabling seamless integration with AI coding assistants like Claude. This is a first-class feature, not an afterthought.

For Claude users, integration is straightforward:

claude mcp add vibium -- npx -y vibium

Current State: v1 and What’s Missing

What Works Now

Vibium v1 ships with core functionality:

• Basic browser automation (click, type, screenshot)
• WebDriver BiDi protocol support
• MCP integration for AI agents
• Simple installation: npm install vibium
• Automatic browser installation on package install

What’s Coming

The discussion revealed several features on the roadmap:

1. JavaScript Injection: Not yet available, but planned
2. DOM Modification: Coming in future releases
3. Network Request Monitoring/Modification: High on the priority list
4. Multi-language Support: Python and Java bindings are planned

One user noted: “I do those things in probably 95-99% of the time I reach for playwright mcp in claude.” Huggins acknowledged this feedback, indicating these features are “definitely on the roadmap.”

Production Readiness

Huggins was clear about the current state: “it’s just v1. good for experimenting, not for production (yet!).”

This transparency is refreshing and sets appropriate expectations for early adopters.

Design Philosophy: The “Just Clicking” Use Case

Simplicity First

A recurring theme in the discussion was the value of simplicity. Huggins emphasized: “don’t underestimate the ‘just clicking’ use case!”

This philosophy reflects a fundamental understanding: many automation tasks don’t require complex network interception or DOM manipulation. Sometimes, you just need to:

• Click a button
• Fill a form
• Take a screenshot
• Navigate between pages

Testing Philosophy Debate

The discussion revealed an interesting philosophical divide:

Network Interception as a Smell? One participant argued: “To me doing network interception in browser driven tests is a smell… I’m a big fan of testing exactly like a user. Users don’t use network intercepts, timeouts, etc.”

The Counter-Argument: Another user responded: “Almost nothing I do has to do with what users actually see though. It’s all things like ‘why didn’t the SSO flow work’.”

This debate highlights that different use cases require different tools. Vibium’s initial focus on simplicity doesn’t preclude adding advanced features—it just prioritizes getting the basics right first.

The Microsoft Factor: Independence and Standards

The Playwright-Microsoft Connection

A significant theme in the discussion was Microsoft’s control over Playwright. Huggins was candid: “not being controlled by microsoft” is on the top 10 list of “why vibium and not playwright.”

He elaborated: “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).”

The Standards-Based Alternative

Vibium’s commitment to W3C standards provides an alternative path that isn’t dependent on a single vendor’s decisions. This resonates with developers concerned about vendor lock-in.

Language Support: A “Big Tent” Approach

Current: TypeScript/JavaScript

Vibium v1 ships with TypeScript/JavaScript support, reflecting current market trends. As Huggins noted: “i started with ts/js because that’s what’s extremely popular right now. (and i like js!)”

Coming: Python, Java, and More

Vibium aims to be a “big tent” project, supporting multiple languages:

• Python: Coming soon
• Java: Planned
• Nim: A personal favorite of Huggins (“i f’ing love nim, we will be supporting nim, too. getting nim on the tiobe top 20 is on my bucket list.”)

This multi-language approach mirrors Selenium’s evolution, which started as JS/Python but became most popular in Java circles.

The Selenium Migration Path

The Upgrade Challenge

One of Vibium’s key value propositions is providing an upgrade path for the massive Selenium installed base. Huggins explained: “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’.”

Post-v1 Plans

Huggins indicated that post-v1, Vibium will focus on: “giving that massive (and it truly is massive, i’m not bragging) installed base of selenium users an upgrade path to more agentic coding options.”

This suggests compatibility layers or migration tools that could help teams transition gradually rather than requiring a complete rewrite.

Developer Experience: Learning from Playwright

What Playwright Got Right

Huggins acknowledged Playwright’s strengths: “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.”

He aims to match Playwright’s developer experience: “i hope to get to the level of ‘click, click, awesome’ out-of-the-box experience that playwright did so well.”

Installation Simplicity

Like Playwright, Vibium simplifies setup:

• npm install vibium automatically installs the needed browser
• No separate browser driver installation required
• Works out of the box

The AI Agent Use Case

Built for AI from Day One

Unlike Selenium (built before AI agents existed) or Playwright (adapted for AI use), Vibium was designed with AI agents as a primary use case from the start.

This manifests in several ways:

1. MCP Integration: Native support for Model Context Protocol
2. Simplified API: Easier for AI to generate correct code
3. Clear Error Messages: Better feedback for AI debugging
4. Agent-Friendly Patterns: API design optimized for AI code generation

The “Vibecoded” Approach

One commenter quipped: “So it’s vibecoded?” (referring to AI-assisted coding). Huggins confirmed: “it’s named vibium for a reason.”

This suggests that Vibium itself is being developed with significant AI assistance, which could inform its design to be more AI-friendly.

Community and Development Model

Solo Development (For Now)

Currently, Vibium is primarily developed by Huggins with AI assistance: “right now, code-wise — for the code you see in github at the moment — it’s just me and my ai pal, claude.”

However, he noted: “there’s a growing cast of (human!) characters also helping with all the other things we need to do to run a successful project. patches and tokens welcome!”

Open Source Commitment

The project appears committed to open source, with contributions welcome. The question of whether it will remain community-driven or seek funding remains open, but the early signals suggest a community-first approach.

Competitive Landscape

Stagehand and Director.ai

The discussion mentioned related projects:

• Stagehand: Built by Browserbase, has a “compatible-ish API” with Playwright but built for automation, not testing
• Director.ai: Uses Stagehand for AI natural language browser automation

Huggins acknowledged: “stagehand is good stuff!” This suggests a collaborative rather than competitive relationship with the broader ecosystem.

DeepWalker: Mobile-First Alternative

One participant mentioned DeepWalker, a mobile-first automation tool for Android, suggesting that the future of AI agents might be mobile-focused. This highlights that browser automation is just one part of a broader automation landscape.

Technical Deep Dive: WebDriver BiDi

What is WebDriver BiDi?

WebDriver BiDi (Bidirectional) is the W3C standard protocol for browser automation. Unlike the classic WebDriver protocol (used by Selenium), BiDi supports:

• Bidirectional communication (hence the name)
• Event-driven architecture
• Better performance through WebSocket connections
• Standardized across browsers

Why It Matters

Huggins chose BiDi over Playwright’s proprietary protocol because:

1. Standards-based: Not dependent on a single vendor
2. Future-proof: W3C standards provide long-term stability
3. Performance: WebSocket-based communication is fast
4. Interoperability: Works across different browser implementations

Use Cases and Limitations

What Vibium Excels At (Currently)

1. Simple automation tasks: Clicking, typing, navigation
2. AI agent integration: Native MCP support
3. Quick prototyping: Easy setup and simple API
4. Standards-based automation: For teams prioritizing W3C compliance

Current Limitations

1. Network interception: Not yet available (highly requested)
2. DOM manipulation: Coming in future releases
3. JavaScript injection: On the roadmap
4. Production readiness: v1 is for experimentation, not production

The Network Request Debate

The discussion revealed a significant divide:

• Testing purists: Prefer testing like users, avoiding network interception
• Debugging practitioners: Need network monitoring to debug issues like SSO failures

Vibium’s roadmap suggests it will support both philosophies, with network request features coming soon.

The Road Ahead

Short Term (v1+)

1. Core feature completion: Network monitoring, DOM manipulation, JS injection
2. Python bindings: Expand language support
3. Documentation: Match Playwright’s excellent docs
4. Stability improvements: Move toward production readiness

Medium Term

1. Java bindings: Tap into the massive Java/Selenium ecosystem
2. Selenium compatibility layer: Help migration from Selenium
3. Advanced features: Match Playwright’s feature set
4. Community growth: Build contributor base

Long Term Vision

1. Multi-language support: Including niche languages like Nim
2. AI-first features: Capabilities unique to AI agent use cases
3. Ecosystem tools: Testing frameworks, CI/CD integrations
4. Industry adoption: Become a viable alternative to Playwright

Conclusion: A New Chapter in Browser Automation

Vibium represents more than just another browser automation tool. It’s a statement about:

• Standards over proprietary solutions: Betting on W3C WebDriver BiDi
• AI-first design: Built for the age of AI agents
• Vendor independence: Not controlled by a single corporation
• Developer experience: Learning from Playwright’s successes
• Migration paths: Helping the massive Selenium user base evolve

Key Takeaways

1. Vibium is v1: Good for experimentation, not production yet
2. Standards-based: Uses W3C WebDriver BiDi, not proprietary protocols
3. AI-native: Designed for AI agents from day one
4. Multi-language: Will support TS/JS, Python, Java, and more
5. Community-driven: Open source with growing contributor base
6. Selenium bridge: Aims to provide upgrade path for Selenium users

Should You Try Vibium?

Yes, if you:

• Want to experiment with AI agent browser automation
• Prefer standards-based solutions
• Are concerned about vendor lock-in
• Want to support an independent alternative
• Are building new automation projects

Wait, if you:

• Need production-ready stability
• Require network interception immediately
• Need advanced DOM manipulation
• Are heavily invested in Playwright with no migration needs

The Bigger Picture

The browser automation landscape is evolving. Selenium established the foundation. Playwright raised the bar for developer experience. Vibium aims to combine the best of both while adding AI-native capabilities and standards-based architecture.

As Huggins noted: “i realize vibium can’t win just as the ‘not microsoft’ option; it will also need to win on the merits.”

The coming months will reveal whether Vibium can deliver on its ambitious vision. But one thing is clear: having the creator of Selenium return to build the next generation of browser automation is a significant moment for the community.

This blog post is based on the Hacker News discussion about Vibium: Show HN: Vibium – Browser automation for AI and humans, by Selenium’s creator

For more information about Vibium, visit: https://github.com/VibiumDev/vibium