webframe tool runs a web page like a script, but has rough edges for production

What webframe is

webframe is a project by Jeff Lindsay that solves a specific problem: running a web page like a command-line script. Instead of opening a full browser and navigating manually, webframe takes a URL (or a local file) and runs the content in a hidden ("headless") browser window. Whatever the page sends to console.log() goes straight to the terminal's standard output; exceptions go to standard error.

Simon Willison, author of the blog simonwillison.net, described the project's core idea like this:

run a web page like a program

Simon Willison, author of the blog simonwillison.net

He was the one who, on October 26, 2026, published the first detailed public review of the tool.

No bundled browser: the project's bet

webframe's most relevant technical decision is not bundling its own browser engine. The project is written in Go on top of the glaze library, which gives access to the browser already installed on the operating system.

WKWebView on macOS, WebKitGTK on Linux, WebView2 on Windows.

Simon Willison, describing the glaze library used by webframe

This is the opposite of the path taken by tools like Playwright, which download and version their own Chromium, Firefox, and WebKit to guarantee identical behavior on any machine. shot-scraper, Simon Willison's own project for screenshot automation and scraping, depends on Playwright for this.

The advantage of using the system browser is obvious: the package is much smaller, there's no need to download a browser binary of hundreds of megabytes on every install, and it takes advantage of an engine the operating system already keeps updated. The disadvantage is equally obvious: behavior ends up depending on which engine is installed on each machine, with real differences between WebKit, WebKitGTK, and the Chromium behind WebView2.

An AI agent did the review, and that's part of the story

A detail that says as much about the moment as it does about the tool: Simon Willison did not test webframe manually, line by line. He asked an agent, running Claude Opus 5.5, to explore the repository, build prototypes, and write an evaluation report. The prompt he used was this:

Explore https://github.com/tractordev/webframe try running it and put it though its paces, build a few exploratory prototypes, then evaluate it as a potential sandboxing tool and as a tool for scraping web pages using the same patterns encouraged by the "shot-scraper JavaScript" command (see simonw/shot-scraper on GitHub, docs directory)

Simon Willison, in the prompt sent to the agent

For those building data pipelines, the detail matters: increasingly, the first screening layer for a new tool, even before anyone on the team looks at the code, is an agent running automated exploration. It's a pattern worth replicating when evaluating any new dependency, knowing that the report still needs human review before it becomes an architecture decision.

The rough edges that showed up in practice

The report found webframe to be fast and lightweight, with performance comparable to shot-scraper for scraping tasks, but it listed concrete problems that any production pipeline will run into:

• CSP failures: pages with a restrictive Content-Security-Policy break execution, because the site's security policy blocks exactly the kind of script injected by an automation tool.
• 0×0 viewport: in some cases the hidden window runs with no defined dimensions, which breaks any page that relies on measuring screen size to render correctly.
• Loads that hang: pages that depend on specific network events may never trigger the expected callback, leaving the process hanging with no error and no output.
• Missing HTTP metadata: the tool does not expose response headers, status code, or other information from the original request, data that is sorely missed precisely when scraping needs to validate whether the page loaded correctly.
• Limited browser controls: without fine-grained access to cookies, user-agent, authentication, or network interception, along the lines of what Playwright already offers.

None of these points invalidates the project: they describe the typical state of a new, small tool, built by one person, that hasn't yet gone through the years of friction against real-world sites that Playwright and Puppeteer have accumulated.

Scraping yes, critical sandbox not yet

The most interesting angle in the review is the split between two uses already suggested by the title of Simon Willison's report itself: scraper and sandbox.

As a scraper, webframe does one specific job well: running a JavaScript script against a page and capturing the output, the same pattern already popularized by the shot-scraper javascript command among people who scrape with Playwright. A pipeline that already follows this "inject JS, read stdout" pattern can swap Playwright's heavy dependency for a smaller Go binary, as long as the target site doesn't rely on strict CSP or on measuring the viewport.

As a sandbox, that is, as an isolated environment for safely running untrusted code, the picture changes. The CSP problems and the limited browser controls are exactly the kind of gap that matters when the goal is isolation, not just extracting text from a page. An AI agent that needs to run arbitrary JavaScript inside a sandbox depends on guarantees the report did not find ready in webframe today.

What this changes for those running scraping and agents in Brazil

In short: webframe does not replace Playwright today, but it opens an interesting path for those with simple scraping scripts who want less weight in the CI/CD pipeline.

Teams that maintain data pipelines with lightweight JavaScript scraping, without needing to deal with aggressive CSP, gain a leaner alternative to Playwright, without the step of downloading browser engines on every build. Those building a sandbox for AI agents to run web code in isolation should treat webframe as study material, not as a production component, until the security and control gaps listed in the report are closed. The project is on GitHub as tractordev/webframe, and the full review published by Simon Willison on October 26, 2026 is worth reading for anyone considering the switch.