webframe: Lightweight Web Page Execution in Go

When you need to extract data from a JavaScript-heavy website or run untrusted web code in isolation, reaching for a full browser automation framework can feel like overkill. A new Go-based tool called webframe offers a lighter alternative worth examining.

Overview

webframe, created by Jeff Lindsay, takes a minimalist approach to running web pages. Point it at a URL or local HTML file, and it executes the page in a hidden web view, piping console.log() output to standard output and exceptions to standard error. The tool runs on top of the glaze library, which provides access to system browsers - WKWebView on macOS, WebKitGTK on Linux, and WebView2 on Windows. This architecture means webframe doesn’t bundle its own browser engine, keeping the package small.

The project positions itself as a way to “run a web page like a program,” making it potentially useful for both web scraping and sandboxing scenarios.

Installation

webframe is available at https://github.com/tractordev/webframe. Since it’s written in Go and relies on system browser components, installation requires the appropriate WebKit or WebView2 dependencies for your platform.

Usage Examples

The tool’s basic operation resembles shot-scraper’s JavaScript execution mode. You can run a page and capture console output:

For scraping workflows, you’d typically inject JavaScript that extracts data and logs it as JSON. The lightweight nature makes webframe faster than heavier automation frameworks for simple extraction tasks - performance was found comparable to shot-scraper in testing.

The sandboxing use case involves running untrusted HTML and JavaScript in a controlled environment, relying on the system browser’s security model to contain potentially malicious code.

Limitations

An evaluation of webframe revealed several significant rough edges that limit its current usefulness. The tool fails on pages with Content Security Policy restrictions, which affects many modern websites. The viewport defaults to 0×0 dimensions, causing problems for pages that rely on layout calculations or responsive design logic.

Page loads sometimes hang indefinitely rather than timing out gracefully, requiring manual intervention. HTTP metadata like response headers and status codes aren’t exposed, making it difficult to handle redirects or errors properly. Browser controls are minimal - there’s no documented way to set custom headers, handle authentication, or control cookies.

These limitations mean webframe works best for simple, controlled scenarios rather than general-purpose web scraping or robust sandboxing. Pages you control or simple data extraction tasks are better fits than crawling arbitrary websites. The CSP failures and missing HTTP metadata particularly constrain scraping applications, while the hanging load issue affects reliability for both use cases.

The project’s lightweight design is appealing, but these practical constraints suggest it needs further development before matching the capabilities of more mature tools in either the scraping or sandboxing domains.