Introducing miniray — a WGSL minifier

I've been spending a lot of time playing with WebGPU shaders just for fun.

Coming from JS/TS world and bouncing back and forth between compute.toys and pngine (a portable shader runtime I am working on) has led me to miss some of the things we take for granted in frontend development that are actually useful when doing stuff in other more specific languages such as WGSL.

Minification and pre-validation are a few of these things.

This post introduces a tool for those purposes and more called "miniray". Courtesy of Claude Code (some parts by me, but mostly Claude Code).

Inércia demoparty 2025 "gataria" demo

I spent more time than I would like to admit doing a demo for the Inércia Demoparty. This happened in December 2025. The final result had a lot of issues, it was a testbed for bad practices and failed ideas and approaches, while desperately trying to punch way above its weight.

When the event demoparty competition arrived, the demo didn't even run to the end. It crashed the tab and the browser of the compo machine.

On top of that it was a huge final file for what it had, around 1MB, we could have done the same in much less space (if only we had more time).

Most of the ~1MB of the demo was occupied with WGSL shader code. It had a video asset (~300KB), a small runtime (~50KB) and the rest was occupied by glorious WGSL strings.

These strings were developed for fun, nothing more. But there were also some painful parts to it, such as not being able to show the entire demo ahah!

Strings for fun

WGSL is a text-based format (unlike SPIR-V binary), and like JS, minification can provide for significant savings.

Having hand-coded (or brain-coded, or whatever people are calling writing regular code these days) the demo shaders made me realize that I didn't want to have a full hard minimization of the code. Some things would be important to be kept as is:

• entrypoints: these are used by the WebGPU plumbing, which I didn't want to be updating after minification.
• uniforms: some reflection on the code was being done for these, which made them important not to mess with when minimizing.
• @location and @builtin: these names provide a bridge between pipeline stages, I had a few contraptions for them in other places outside WGSL and didn't want them to be mangled with.

On top of these, there was a whole custom graphics engine framework that took me a year and a half to do. This also required special care and considerations here and there for the minification process.

Having met Claude Opus 4.5 recently I thought that it would be cool to talk it through a WGSL minification tool. The WGSL validation, reflection and minification are going to be important parts of my foreseeable future projects, just ripe to be off-shored by capitalism.

Validation

In WebGPU the dance mandates that the WGSL string gets compiled into a Shader Module, which then gets placed in a pipeline, which then gets placed in a pass, which then gets placed in an encoder.

Some errors of that string are caught early in the compilation stage, but some errors are more aligned with life traditions and only blow up in delicate situations when the project is running.

One thing about WebGPU is that WGSL compilation happens in runtime. Compilation errors are deferred to runtime because you compile in the browser, while the code is running.

Since miniray is going to build a whole AST of WGSL why not validate it semantically as well? This way we could demote compilation errors (which in WebGPU happen in runtime) to become pre-compilation errors, by running an offline tool beforehand.

Yeah Claude, let's bring WGSL validation to the CLI without having to go through the WebGPU runtime.

Unlike us, Claude has eaten for breakfast the souls and dreams of humanity finest works, but I knew it wasn't enough. So I fed it the WebGPU Dawn WGSL tests. It was fun seeing all that work getting eaten in a frivolous manner like it was getting sucked by an unstoppable machine whose efficiency is matched only by the steamroller force of the free markets.

Now miniray can do WGSL validation in the command line in a way comparable to what Google Chrome does in the browser. Claude, my greatest friend, fetch me a C FFI, and wasm build for this as well. It might come in handy for future projects.

Meeting Claude

The year is ending, and with it a lot of old school developers are writing about their points of view on LLMs and AIs. Strongly opinionated pieces show up here and there. Charged with emotional anxious tone, these posts have taken the place of the "Why I left Google/Facebook/etc" commotion that used to show up before these firms started laying off people like cattle.

This is one of those posts.

Claude excels in delivering rapid, high-impact results, maintains a strong solutions-oriented mindset, and has demonstrated performance that warrants serious consideration for increased responsibility and compensation. At the end of the day, it's the last person who should end up anywhere near a PIP.

Occasionally shows an unusual level of deference toward me. I'm not entirely sure why. Engineers aren't typically known for their people skills, but in my experience that level of flattery was usually directed elsewhere. Not that I'm complaining.

I feel that 2026 will be the year of ass-kissing.

Miniray

Unlike UNIX tooling, miniray is meant to do three things and do them well: minifies WGSL code, validates it, and outputs the reflection structured output about the code. In the future it might do a couple more things if the need arises.

It is also heavily tested, and under constant usage by me. I am focusing on stability now and releasing it to the public domain (I hope Claude doesn't mind).

I love reading the esbuild code (go check it out). The miniray inspiration that inspired Claude, was inspired by it. It is done in Go, a language I can mostly read, and respect (and that's about it, because I never tried to write Go).

Specs aside, I believe WGSL programming will be an important part of my future as it becomes the target of creative fun explorations, an island of refuge in a sea of mechanical automatisms such as miniray.

Conclusion

Miniray started as an experiment, became a tool, and will probably end up powering a bunch of my WebGPU experiments in 2026. If you write shader code and feel the need for any of these three things (minification, validation and reflection), then miniray is intended to be a useful solid tool in doing them.

Try it online here.