tractordev/webframe

webframe is worth a look if you have a page that must run in a real browser engine but you want to treat it like a CLI process rather than drive Chrome over a remote-debugging protocol. It is early, platform-dependent, and small in scope, so pick it for a specific scripting job rather than as a general browser automation replacement.

The problem

You have code that needs a browser engine: WASM modules, WebGPU, Web Audio, DOM libraries, or an emulator that only ships as a page. Getting that into a script or cron job today usually means installing a browser automation stack, wiring up a control protocol, and forwarding console output back by hand. webframe changes the last step: it loads a URL or local file in a hidden system webview and treats the page as the program. console output goes to stdout, exceptions to stderr, and stdin can evaluate JavaScript in the live page. The result is a page you can start, observe, and poke at from a shell or a Go caller.

What's different

The mechanism is the distinguishing part. Instead of bundling Chromium, it uses the webview the OS already provides through glaze: WebKit on macOS, WebKitGTK on Linux, WebView2 on Windows. That gives a single small binary, no bundled browser, and in most cases no cgo. Errors are surfaced with engine detail where available, and the -c console mode lets you evaluate lines against a running page, including a v86 example that boots Linux and connects its serial console to webframe.

The trade-off is that the browser engine is the OS's, so behavior and limitations follow it. Errors from file:// pages and cross-origin scripts without CORS show only Script error., which the README attributes to WebKit rather than webframe. alert, confirm and prompt are auto-dismissed rather than interactive. Timer throttling is disabled on macOS, but the README says other platforms may still throttle hidden pages. Windows does not report page load failures like DNS or connection errors. These are real constraints for a daemon that must stay fast or observably correct everywhere.

Who should try it

A good fit is a developer with a browser-only workload who wants to run it from CI, cron, or a REPL: a benchmark page, a WASM tool, or an emulator with a serial console. The Go library also fits callers who want page events and evaluation with their own policy for formatting and exit codes. A poor fit is anyone who needs fleet-wide, deterministic browser automation with consistent engine behavior, or interactive pages that depend on dialogs. If you need a full browser stack or cross-browser fidelity, the OS-webview approach is not the abstraction you want.

Requirements and limitations

Platform setup is the main ongoing cost. macOS needs nothing beyond the binary. Windows needs the Edge WebView2 Runtime, preinstalled on Windows 10/11. Linux needs WebKitGTK 4.1 or 6.0 plus a display or Xvfb; the README notes that webframe starts a private Xvfb when no display is set, and the Alpine path needs the linux-musl build with webkit2gtk-4.1 and xvfb installed. The Docker image bakes these in, at roughly 580 MB, almost all WebKitGTK.

Building has its own boundary. Most targets use CGO_ENABLED=0 and cross-compile with plain Go, but the linux-musl build uses cgo against musl and needs zig. The Linux binaries still depend on the system glibc and loader. For the Go library, the webview runs on the main thread; callers must lock the OS thread and call Run from the main goroutine, and only New and Run are restricted to that thread. The README's VM setup for macOS and Windows notes auto-login because webframe needs a desktop session; that is testing infrastructure, not a requirement for normal CLI use.

HotRepo's take

HotRepo's only dated observation is 40 total stars on the NEW-REPOSITORY board (go filter), #6, seen 2026-10-25. That is a single snapshot with no comparable daily history, so persistence cannot yet be judged. Given the 0-day age and OS-webview dependence, the first thing to verify is whether your target machine has the required runtime and display setup; the README's platform table and Dockerfile are the concrete places to check before committing.