This is the culmination of a long journey — it started in TypeScript, moved through WebGL1 with Rust bindings, then WebGL2, and now finally WebGPU. Woohoo :D
AwsmRenderer is a browser-native WebGPU renderer written in Rust, using web-sys directly (not wgpu). It’s intended to be high quality and ergonomic for typical gamedev use-cases, while keeping the API surface relatively small and explicit.
Fair warning: this is fresh off the push and only lightly tested so far. It requires a WebGPU-capable browser and is currently intended for desktop use.
Longer-term, the goal is to empower AAA-like gamedev in the browser with WASM. Internally, the API centers around keys that can be converted to/from u64, which should make it easier to move data across workers or future WASM component boundaries, and to integrate with physics engines or core game code.
Curious to hear thoughts from folks with WebGPU, Rust, or browser graphics experience.
mendyberger•3w ago
Curious, why use web-sys directly instead of wgpu?
dakom•3w ago
Mostly because I want insight and control at a lower level, which breaks down into two different use-cases:
1. Debugging. The nature of bugs in this space is a lot more of "it doesn't look right on the screen" as opposed to "it breaks compilation", so I want to easily do things like peek into my buffers, use native js logging, etc. It's just a lot easier for me to reason about when I have more manual control.
2. Leaky abstractions. wgpu is a pretty low-level but it can't avoid the pain that comes with different backends, async where it should it shouldn't be, features that aren't available everywhere, etc.
That said, it would probably be pretty straightforward to convert the renderer into wgpu, most of the data structures and concepts should map cleanly
mendyberger•3w ago
Fair enough.
For me, having wgpu's rust native api feels so much nicer than having to deal with the unergenomic web_sys api. Tradeoffs.
dakom•3w ago
Yeah, I split the crates so `renderer-core` deals with the web-sys part, `renderer` is pretty much plain Rust (and wgsl with Askama templates)
I prefer this for 100% browser-only, but that's a niche. I do think wgpu makes more sense when you like the WebGPU headspace but want to target other backends (native, mobile, VR, etc.)
dakom•3w ago
AwsmRenderer is a browser-native WebGPU renderer written in Rust, using web-sys directly (not wgpu). It’s intended to be high quality and ergonomic for typical gamedev use-cases, while keeping the API surface relatively small and explicit.
Fair warning: this is fresh off the push and only lightly tested so far. It requires a WebGPU-capable browser and is currently intended for desktop use.
Longer-term, the goal is to empower AAA-like gamedev in the browser with WASM. Internally, the API centers around keys that can be converted to/from u64, which should make it easier to move data across workers or future WASM component boundaries, and to integrate with physics engines or core game code.
Source: https://github.com/dakom/awsm-renderer
Curious to hear thoughts from folks with WebGPU, Rust, or browser graphics experience.
mendyberger•3w ago
dakom•3w ago
1. Debugging. The nature of bugs in this space is a lot more of "it doesn't look right on the screen" as opposed to "it breaks compilation", so I want to easily do things like peek into my buffers, use native js logging, etc. It's just a lot easier for me to reason about when I have more manual control.
2. Leaky abstractions. wgpu is a pretty low-level but it can't avoid the pain that comes with different backends, async where it should it shouldn't be, features that aren't available everywhere, etc.
That said, it would probably be pretty straightforward to convert the renderer into wgpu, most of the data structures and concepts should map cleanly
mendyberger•3w ago
For me, having wgpu's rust native api feels so much nicer than having to deal with the unergenomic web_sys api. Tradeoffs.
dakom•3w ago
I prefer this for 100% browser-only, but that's a niche. I do think wgpu makes more sense when you like the WebGPU headspace but want to target other backends (native, mobile, VR, etc.)