pngine turns WebGPU wiring into S-expressions that ship inside PNG files

Hugo Daniel has released pngine, a declarative format and runtime for WebGPU that he says has been roughly two and a half years in the making. The project, described in a post on his site that reached the Hacker News front page, replaces the imperative JavaScript (or Rust) usually written to set up WebGPU with S-expressions that map one-to-one onto the WebGPU specification. WGSL shader code is deliberately left untouched, embedded as-is in string fields rather than extended with macros.

Declaring the plumbing instead of scripting it

A conventional WebGPU program calls createShaderModule and createRenderPipeline, opens a render pass, attaches pipelines and issues draws — creation, wiring and sequencing all mixed together in host-language code. Daniel argues that most of this is static configuration, and that lifting it into declarations frees the wiring from order: a render-pipeline node simply refers to a named shader-module and its entry points, and blocks can be rearranged at will. The one construct where sequence is meaningful is frame, whose :perform list names passes — uniform updates, an SDF pass, post-processing — in execution order.

As evidence the two forms are equivalent, Daniel notes that the procedural JavaScript example in his post was itself generated by pngine from the S-expression source, as one of several possible outputs.

Validation without a GPU

Because the whole configuration is structured, readable data, pngine can check it statically. According to Daniel, WGSL reflection combined with checks against the WebGPU spec produces errors and warnings without a live WebGPU context, and a language server surfaces them while you type. He ties this back to his earlier SJON work: once the program representation is ordinary data, the same representation supports validation, replay, inspection, minification, serialization and machine generation — all ahead of time and all operating on one common form.

Shipping as HTML, ZIP or a self-describing PNG

Exports come in three shapes: a single .html file, a .zip, or a .png. The PNG option explains the name. The S-expressions are compiled to a binary representation interpreted by a tiny runtime, and that runtime plus its payload can be stored in an extra PNG chunk, with the image itself serving as a preview of what is being shipped. Daniel is explicit that the PNG does not run by itself — a small player must read and execute it on demand.

The format is not browser-bound either. Daniel says the same declarations work with Rust's wgpu, players exist for Android and iOS, and CPU/WASM initialisation is included in the bundle. The code is released under CC0, with GitHub hosting issues and discussions and releases cut from his self-hosted repository.

A substrate, not a playground

Daniel points to Shadertoy and compute.toys as excellent venues for sharing and learning shader code, and is equally clear that pngine is not competing with them — there is no playground, though there is an LSP. His framing is that sharing a pipeline today forces a stack of prior agreements: which host language, how handles are represented and passed, whether the wiring belongs to a small animation, a game or something else entirely. Pngine cannot remove those choices, he writes, but it tries hard to reduce them so that one bundle can serve very different purposes and run on very different targets.

Why it matters

WebGPU's own design already pushed implicit graphics state into explicit API calls and config objects; pngine takes that trajectory one step further and makes the configuration itself the artifact. If pipelines, buffers and passes exist as portable data that can be validated offline, they can also be diffed, minified, machine-generated and retargeted across browsers, wgpu and mobile players without rewriting host code. The self-carrying PNG is a memorable trick, but the durable idea is the representation — and with a CC0 license and a minimal runtime, the barrier to experimenting with it is low. Whether S-expressions can displace the de facto convention of TypeScript-based WebGPU setup remains unproven, but as a foundation for tool builders, human or machine, the approach tackles a genuine gap in how GPU work is shared.