Motivation

This was talked about in #999 but that was nearly a year ago so I wanted to see how people's thoughts on the matter have changed, if at all. Essentially, https://github.com/rust-windowing/raw-window-handle wants to solve the problem of version breaking between windowing implementations and graphics libraries by adding a layer of indirection that can be represented as primitive types such as integers or pointers. As it is, if a graphics library is designed to work with a JsValue from wasm-bindgen 0.2.49 and a windowing system insists on one from wasm-bindgen 0.2.48, there's absolutely zero ways to really make them cooperate, even if nothing about the JsValue or how they work has changed between versions.

This is a real and persistent problem: gfx-hal 0.2's DX12 backend relies on Winit 0.19, so if you're using gfx-hal 0.2 you're going to be using winit 0.19, and that's that unless you write your own windowing code. If you're using gfx-hal 0.3 you're going to be still using winit 0.19 even when winit 0.20 gets released; you can't use any of the 0.20 release candidates, and when winit 0.20 gets released it will require a breaking change for gfx-hal to also be released. But, if winit exposes types that raw-window-handle can work with, and raw-window-handle exposes types that gfx-hal can work with, then it breaks the link tying gfx-hal and winit to specific versions of each other.

This solution is similar to how the mint crate provides interoperability between vector math libraries, so libraries like ggez don't tie their users to a particular version of nalgebra or cgmath. It basically solves helps the problem of different crates moving at different speeds, since no matter what else the API binding them together moves at the speed of the interoperability crate, which is intended to be pretty stable.

Proposed Solution

So, anyway. This is a long-winded way of saying "it would be useful if we could turn a JsValue into a raw handle of some kind that doesn't depend on a particular version of wasm-bindgen, even unsafely".

Alternatives

raw-window-handle could expose handles based on the version of wasm-bindgen, such as WasmHandle02(JsValue), WasmHandle03(JsValue), and so on, and use feature flags to offer the right ones at compile time. It would work. But it would kinda suck.

The root problem is really that raw-window-handle goes for its portability by handing out the OS's underlying types, which are all either pointers and integers. And it's hard for an API to get more stable than Windows and X11's basic windowing junk. Wasm is a much younger system, and still evolving.