I'm not sure why rust and webassembly are significant here. All the webgl commands still need to be javascript and the shaders still need to be glsl. Almost nothing in a demo like this needs to be done on the cpu.

Such a weird comment... all the webgl commands in the article are clearly written in Rust - `gl.bind_framebuffer(GL::FRAMEBUFFER, framebuffer.as_ref());` - and that's only possible because of WebAssembly. How are they not significant?

jakelazaroff

WebGL has a Javascript API: https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API

That said, it's unnecessarily dismissive. It's still a cool project! And a useful resource for anyone who does need to use Rust with WebGL for whatever reason.

chinedufn

Miiiiinor point/caveat here but jotting it down just for others that might be less familiar!

Today WebGL is commonly referred to as a JS API because pretty much every WebGL app is written using JS.

But, even though that MDN link quite literally says "JavaScript API", it turns out that WebGL is entirely specified in WebIDL and isn't coupled to JS.

Because of this, `wasm-bindgen` [1] is able to auto-generate all of the WebGL bindings [2] that I used for this demo.

Today `wasm-bindgen` automatically generates some JS shims because that's the only way to call the WebGL APIs at this time, but once anyref and host bindings land you'll be able to interface with the WebGL APIs directly without going through JS.

`wasm-bindgen` already plans to just replace those JS shims with direct host bindings.

But yup - totally agree with your points here - just sharing this minor detail that will be more relevant in the future!

[1] - https://github.com/rustwasm/wasm-bindgen

[2] - https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.W...