Browser Automation and Application State Control
playwright, puppeteer, and selenium-webdriver are libraries designed for browser automation, enabling tasks like end-to-end testing, scraping, and screenshot generation. robot3 differs significantly as it is a lightweight finite state machine library for managing internal application logic rather than controlling external browsers. While the first three interact with the DOM and network from the outside, robot3 helps structure state transitions within the frontend code itself.
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Browser Automation and State Control: A Technical Deep Dive
When building robust frontend systems, you often need tools to control browsers for testing or to manage complex internal state. playwright, puppeteer, and selenium-webdriver handle browser automation, while robot3 manages application logic. Understanding their distinct roles prevents architectural mismatches. Let's compare how they initialize, handle logic, and manage errors.
🚀 Initialization and Setup
Setting up these tools varies based on whether they control a browser or manage memory state.
playwright uses a test runner or manual browser launch.
- It manages browser binaries automatically.
- Configuration is often done in
playwright.config.ts.
// playwright: Manual launch
const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch();
const page = await browser.newPage();
})();
puppeteer launches a Chrome instance directly.
- You must manage the browser process lifecycle.
- It connects via the Chrome DevTools Protocol.
// puppeteer: Launch Chrome
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
})();
selenium-webdriver requires building a driver instance.
- It often needs external driver binaries (like chromedriver).
- Configuration is more verbose than modern alternatives.
// selenium-webdriver: Build driver
const { Builder, Browser } = require('selenium-webdriver');
(async function example() {
let driver = await new Builder().forBrowser(Browser.CHROME).build();
})();
robot3 initializes a state machine in memory.
- No browser is involved.
- You define states and transitions explicitly.
// robot3: Create machine
import { machine, service, state } from 'robot3';
const toggleMachine = machine({
inactive: state({
on: { TOGGLE: 'active' }
}),
active: state({
on: { TOGGLE: 'inactive' }
})
});
⏳ Handling Asynchronous Flow
Automation tools wait for network or DOM events. State machines transition based on events.
playwright auto-waits for elements to be actionable.
- Reduces the need for manual sleep commands.
- Handles navigation and load events automatically.
// playwright: Auto-waiting
await page.click('#submit-button');
// Waits for element to be visible and enabled
puppeteer requires explicit wait commands.
- You must specify what to wait for (selector, timeout).
- Gives more control but adds more code.
// puppeteer: Explicit wait
await page.waitForSelector('#submit-button');
await page.click('#submit-button');
selenium-webdriver uses WebDriverWait for conditions.
- You define expected conditions explicitly.
- Common pattern in older test suites.
// selenium-webdriver: Explicit wait
const until = require('selenium-webdriver').until;
await driver.wait(until.elementLocated(By.id('submit-button')));
robot3 transitions state synchronously or via integration.
- It does not wait for DOM.
- You connect it to async actions manually.
// robot3: Transition state
const svc = service(toggleMachine, () => {});
svc.send('TOGGLE');
// State changes immediately in memory
⚠️ Error Handling Strategies
Failures in automation stop tests. Failures in state machines should be predictable.
playwright captures traces and screenshots on failure.
- Built-in retry logic for tests.
- Provides detailed logs for debugging.
// playwright: Test with retry
test('submit form', async ({ page }) => {
await page.goto('/form');
// Auto-retries on failure if configured
});
puppeteer throws standard Node.js errors.
- You must wrap code in try/catch blocks.
- No built-in test retry mechanism.
// puppeteer: Manual error handling
try {
await page.click('#missing-element');
} catch (err) {
console.error('Click failed', err);
}
selenium-webdriver throws WebDriverError exceptions.
- Errors often indicate driver mismatch or timeout.
- Requires careful cleanup in finally blocks.
// selenium-webdriver: Try/Finally
try {
await driver.findElement(By.id('missing'));
} catch (e) {
console.error('Element not found');
} finally {
await driver.quit();
}
robot3 guards invalid transitions.
- Sending an invalid event does nothing or throws.
- Prevents impossible states in logic.
// robot3: Invalid transition
// Sending 'CLOSE' when only 'TOGGLE' is allowed
svc.send('CLOSE');
// Machine ignores invalid event safely
🌐 Real-World Scenarios
Scenario 1: End-to-End Testing
You need to verify a checkout flow across Chrome, Firefox, and Safari.
- ✅ Best choice:
playwright - Why? It supports all three browsers natively with one API.
// playwright: Multi-browser test
const { webkit, firefox, chromium } = require('playwright');
// Same test code runs on all three
Scenario 2: Generating PDFs from Web Pages
You need to render a dynamic invoice page to PDF server-side.
- ✅ Best choice:
puppeteer - Why? It has optimized PDF generation APIs for Chrome.
// puppeteer: PDF generation
await page.pdf({ path: 'invoice.pdf', format: 'A4' });
Scenario 3: Legacy Enterprise Testing
Your company has an existing Selenium Grid with custom drivers.
- ✅ Best choice:
selenium-webdriver - Why? It integrates directly with existing grid infrastructure.
// selenium-webdriver: Remote grid
let driver = await new Builder()
.usingServer('http://grid-url:4444/wd/hub')
.build();
Scenario 4: Complex UI Component Logic
You are building a media player with play, pause, load, and error states.
- ✅ Best choice:
robot3 - Why? It prevents invalid state changes like 'pause' when 'stopped'.
// robot3: State guard
const playerMachine = machine({
stopped: state({ on: { PLAY: 'playing' } }),
playing: state({ on: { PAUSE: 'paused' } })
});
📌 Summary Table
| Feature | playwright | puppeteer | selenium-webdriver | robot3 |
|---|---|---|---|---|
| Primary Use | E2E Testing | Browser Control | Legacy Automation | State Logic |
| Browser Support | Chromium, Firefox, WebKit | Chromium (mostly) | All (via drivers) | None (In-memory) |
| Auto-Waiting | ✅ Built-in | ❌ Manual | ❌ Manual | N/A |
| Setup Complexity | Low | Low | High | Low |
| Language | JS/TS, Python, etc. | JS/TS | Multiple | JS/TS |
💡 Final Recommendation
For modern browser automation, playwright offers the best developer experience with cross-browser support and stability. Use puppeteer if you need deep Chrome-specific features like PDF generation or extension testing. Stick with selenium-webdriver only if you must maintain legacy infrastructure or require specific browser drivers not supported by newer tools.
Keep robot3 separate from your testing stack. Use it inside your application code to manage complex component states. Mixing testing tools with state management libraries leads to confusion — keep your test automation external and your state logic internal.
How to Choose: playwright vs puppeteer vs robot3 vs selenium-webdriver
- playwright:
Choose
playwrightfor modern end-to-end testing requiring cross-browser support including WebKit, Firefox, and Chromium. It offers auto-waiting mechanisms and powerful tracing tools that reduce flaky tests. This package is ideal for teams wanting a robust, all-in-one testing solution with minimal configuration. - puppeteer:
Choose
puppeteerwhen your work focuses primarily on Chrome or Chromium-based environments. It provides deep access to the Chrome DevTools Protocol for advanced debugging, PDF generation, or scraping tasks. This tool fits well for projects that need tight integration with Chrome-specific features. - robot3:
Choose
robot3when you need to manage complex UI state logic within your application code rather than testing it. It is suitable for components with many distinct states, like wizards or media players, where clear transitions prevent bugs. Use this for internal architecture, not for browser automation or testing. - selenium-webdriver:
Choose
selenium-webdriverif you require support for legacy browsers or need to integrate with an existing Selenium Grid infrastructure. It offers broad language support and stability for long-standing enterprise test suites. This package is best for teams maintaining older systems or requiring specific driver configurations.
Popular Comparisons
README for playwright
🎭 Playwright
Documentation | API reference
Playwright is a framework for web automation and testing. It drives Chromium, Firefox, and WebKit with a single API — in your tests, in your scripts, and as a tool for AI agents.
Get Started
Choose the path that fits your workflow:
| Best for | Install | |
|---|---|---|
| Playwright Test | End-to-end testing | npm init playwright@latest |
| Playwright CLI | Coding agents (Claude Code, Copilot) | npm i -g @playwright/cli@latest |
| Playwright MCP | AI agents and LLM-driven automation | npx @playwright/mcp@latest |
| Playwright Library | Browser automation scripts | npm i playwright |
| VS Code Extension | Test authoring and debugging in VS Code | Install from Marketplace |
Playwright Test
Playwright Test is a full-featured test runner built for end-to-end testing. It runs tests across Chromium, Firefox, and WebKit with full browser isolation, auto-waiting, and web-first assertions.
Install
npm init playwright@latest
Or add manually:
npm i -D @playwright/test
npx playwright install
Write a test
import { test, expect } from '@playwright/test';
test('has title', async ({ page }) => {
await page.goto('https://playwright.dev/');
await expect(page).toHaveTitle(/Playwright/);
});
test('get started link', async ({ page }) => {
await page.goto('https://playwright.dev/');
await page.getByRole('link', { name: 'Get started' }).click();
await expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible();
});
Run tests
npx playwright test
Tests run in parallel across all configured browsers, in headless mode by default. Each test gets a fresh browser context — full isolation with near-zero overhead.
Key capabilities
Auto-wait and web-first assertions. No artificial timeouts. Playwright waits for elements to be actionable, and assertions automatically retry until conditions are met.
Locators. Find elements with resilient locators that mirror how users see the page:
page.getByRole('button', { name: 'Submit' })
page.getByLabel('Email')
page.getByPlaceholder('Search...')
page.getByTestId('login-form')
Test isolation. Each test runs in its own browser context — equivalent to a fresh browser profile. Save authentication state once and reuse it across tests:
// Save state after login
await page.context().storageState({ path: 'auth.json' });
// Reuse in other tests
test.use({ storageState: 'auth.json' });
Tracing. Capture execution traces, screenshots, and videos on failure. Inspect every action, DOM snapshot, network request, and console message in the Trace Viewer:
// playwright.config.ts
export default defineConfig({
use: {
trace: 'on-first-retry',
},
});
npx playwright show-trace trace.zip
Parallelism. Tests run in parallel by default across all configured browsers.
Playwright CLI
Playwright CLI is a command-line interface for browser automation designed for coding agents. It's more token-efficient than MCP — commands avoid loading large tool schemas and accessibility trees into the model context.
Install
npm install -g @playwright/cli@latest
Optionally install skills for richer agent integration:
playwright-cli install --skills
Usage
Point your coding agent at a task:
Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Take screenshots for all successful and failing scenarios.
Or run commands directly:
playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli screenshot
Session monitoring
Use playwright-cli show to open a visual dashboard with live screencast previews of all running browser sessions. Click any session to zoom in and take remote control.
playwright-cli show
Full CLI documentation | GitHub
Playwright MCP
The Playwright MCP server gives AI agents full browser control through the Model Context Protocol. Agents interact with pages using structured accessibility snapshots — no vision models or screenshots required.
Setup
Add to your MCP client (VS Code, Cursor, Claude Desktop, Windsurf, etc.):
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}
One-click install for VS Code:
For Claude Code:
claude mcp add playwright npx @playwright/mcp@latest
How it works
Ask your AI assistant to interact with any web page:
Navigate to https://demo.playwright.dev/todomvc and add a few todo items.
The agent sees the page as a structured accessibility tree:
- heading "todos" [level=1]
- textbox "What needs to be done?" [ref=e5]
- listitem:
- checkbox "Toggle Todo" [ref=e10]
- text: "Buy groceries"
It uses element refs like e5 and e10 to click, type, and interact — deterministically and without visual ambiguity. Tools cover navigation, form filling, screenshots, network mocking, storage management, and more.
Full MCP documentation | GitHub
Playwright Library
Use playwright as a library for browser automation scripts — web scraping, PDF generation, screenshot capture, and any workflow that needs programmatic browser control without a test runner.
Install
npm i playwright
Examples
Take a screenshot:
import { chromium } from 'playwright';
const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://playwright.dev/');
await page.screenshot({ path: 'screenshot.png' });
await browser.close();
Generate a PDF:
import { chromium } from 'playwright';
const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://playwright.dev/');
await page.pdf({ path: 'page.pdf', format: 'A4' });
await browser.close();
Emulate a mobile device:
import { chromium, devices } from 'playwright';
const browser = await chromium.launch();
const context = await browser.newContext(devices['iPhone 15']);
const page = await context.newPage();
await page.goto('https://playwright.dev/');
await page.screenshot({ path: 'mobile.png' });
await browser.close();
Intercept network requests:
import { chromium } from 'playwright';
const browser = await chromium.launch();
const page = await browser.newPage();
await page.route('**/*.{png,jpg,jpeg}', route => route.abort());
await page.goto('https://playwright.dev/');
await browser.close();
Library documentation | API reference
VS Code Extension
The Playwright VS Code extension brings test running, debugging, and code generation directly into your editor.
Run and debug tests from the editor with a single click. Set breakpoints, inspect variables, and step through test execution with a live browser view.
Generate tests with CodeGen. Click "Record new" to open a browser — navigate and interact with your app while Playwright writes the test code for you.
Pick locators. Hover over any element in the browser to see the best available locator, then click to copy it to your clipboard.
Trace Viewer integration. Enable "Show Trace Viewer" in the sidebar to get a full execution trace after each test run — DOM snapshots, network requests, console logs, and screenshots at every step.
Install the extension | VS Code guide
Cross-Browser Support
| Linux | macOS | Windows | |
|---|---|---|---|
| Chromium1 148.0.7778.96 | :white_check_mark: | :white_check_mark: | :white_check_mark: |
| WebKit 26.4 | :white_check_mark: | :white_check_mark: | :white_check_mark: |
| Firefox 150.0.2 | :white_check_mark: | :white_check_mark: | :white_check_mark: |
Headless and headed execution on all platforms. 1 Uses Chrome for Testing by default.
Other Languages
Playwright is also available for Python, .NET, and Java.