webframe: evaluated as a scraper and a sandbox
- ID
- 39800
- Status
- summarized
- Published
- 27 Oct 2026, 12:15 AM
- Fetched
- 27 Oct 2026, 9:07 AM
- Provider
- Simon Willison
- Category
- developer-ai
- Original URL
- https://simonwillison.net/2026/Oct/26/webframe-evaluation/
- Source URL
- https://simonwillison.net/atom/everything/
Summary
- Score
- 6.5
- Created
- 27 Oct 2026, 9:08 AM
- Tags
- Audience
- developersai_ml_learnersai_agent_users
What happened
Simon Willison ran an evaluation of webframe, Jeff Lindsay's Go project built on the glaze library that executes a URL or file in a hidden system web view (WKWebView on macOS, WebKitGTK on Linux, WebView2 on Windows) and pipes console.log() to stdout and exceptions to stderr — no bundled browser engine, no Playwright dependency. He had Claude Opus 5.5 test it as both a scraper and a potential sandboxing tool: it was fast and lightweight with scraping performance comparable to his own shot-scraper javascript command, but showed CSP failures, a 0×0 viewport, hanging loads, missing HTTP metadata, and limited browser controls.
Why it matters
If you are tempted to swap Playwright for a smaller headless runner in a scraping or agent pipeline, this evaluation names the specific failure modes to test for first: a 0×0 viewport breaks layout-dependent scraping, CSP failures block some pages outright, and missing HTTP metadata means you cannot inspect status codes or headers from the run. Treat webframe as a fast prototype tool, not a drop-in sandbox — the report did not validate it for sandboxing.
Discussion angle
The 0×0 viewport and CSP failures are the kind of rough edge that silently corrupts agent scraping output — worth asking which of these you would catch in a smoke test before shipping a lightweight runner into production.