| Glad you asked! There's a recent issue [1] in the wasm-bindgen repo that explains this, but essentially: - In this demo the WebGLRenderingContext was created on the Rust side (technically by calling a light JS shim), but it could've just as well have been passed in from JS. - This means that JS could very easily have had access to the WebGLRenderingContext. - This means that we cannot guarantee that it is immutable. Who is to say that there isn't a line of JS `gl.mutated! = true;` that we don't know about? We have no guarantees that whoever instantiated this WebAssembly module isn't doing something funky. - So we treat most DOM / JS APIs as if they have interior mutability, so more or less you can think of them as `RefCell`'s [2] --- As an aside. When you work with WebGL you're just making calls to the GPU and your state on the GPU gets mutated. The object just controls state (WebGlRenderingContext) does not get mutated (aside from maybe a couple things that I'm forgetting..?). As in.. `gl.viewport` doesn't actually mutate `gl`. But again.. just a small aside! In general the idea here is that we can't guarantee that there is only one mutable reference so there is no point in calling these things `&mut`, even for things that really do mutate. --- So yup! Interior mutability without runtime checks for many of the APIs is "the right way" in today's idiomatic Rust + WASM + DOM access since you can't guarantee that there isn't foul play going on from whoever instantiated the module. --- Does this cause issues? It hasn't (noticeably) for me yet but I'm only a couple months into using `web_sys` so I haven't worked with every single DOM API.. so grain of salt! [1] - https://github.com/rustwasm/wasm-bindgen/issues/1061 [2] - https://doc.rust-lang.org/std/cell/struct.RefCell.html |