Support wasm32-unknown-unknown backend?

[icefoxen]

Would it be possible/reasonable/desired to support a wasm32-unknown-unknown backend without needing to use emscripten? I'm a little inspired by this crate: https://github.com/ryanisaacg/quicksilver which does it by providing a Javascript interface and it seems to work okay, though I don't know what invariants winit needs to provide that wasm32-unknown-unknown might make hard (mainloop callback, presence of threads, etc).

[tomaka]

Supporting wasm32-unknown-unknown is not something obvious, as we cannot make any assumption on the environment.

It could be possible to support it by making the user create the glue manually. However if you want a glue, you might as well use emscripten since this is the whole purpose of it.

[icefoxen]

Yeah you're correct there. However I really want to be able to avoid emscripten, since I never manage to get it to work consistently, and if people are making games with ggez then I really want to make life easy for them as well. Requiring them to install emscripten kinda sucks.

So what seems like a reasonable path forward here? We more or less have a glue library in the form of stdweb now, and I've been working with the webassembly WG people to make a better one by auto-generating bindings from WebIDL specifications. Getting a new wasm32-unknown-webapi OS target into the compiler seems the obvious right thing, but it might be a bit of a long road and I don't really want to wait that long before I can start implementing this for winit. It is just, as you say, not really nice to have an unknown OS target that actually means webapi.

[OvermindDL1]

not really nice to have an unknown OS target that actually means webapi.

Especially as there are non-webbrowser interpreters for webassembly that don't have a web api at all.

[francesca64]

@icefoxen

Getting a new wasm32-unknown-webapi OS target into the compiler seems the obvious right thing

Is that something anyone's working on? If it's the obvious right thing, then it would be good to move towards that.

That said, if that's likely to take a long time, it doesn't seem ideal to wait from a strategic perspective. People are excited about WebAssembly right now, and you seem to want to work on winit's support for it right now, so it seems like a good way to make people happy.

I imagine there's a way we can handle this that would be reasonably correct, but I truthfully know very little about WebAssembly. It's something that interests me (the bulk of my past experience is in web dev), but I'm too busy with the other backends to be able to provide any insights here yet.

[icefoxen]

Yep. My current tentative plan is to make a prototype web backend for Winit using stdweb or wasm-bindgen, then use it as an example to show people why we need a new target.

…

On Thu, Apr 26, 2018, 12:14 Francesca Frangipane ***@***.***> wrote: @icefoxen <https://github.com/icefoxen> Getting a new wasm32-unknown-webapi OS target into the compiler seems the obvious right thing Is that something anyone's working on? If it's the obvious right thing, then it would be good to move towards that. That said, if that's likely to take a long time, it doesn't seem ideal to wait from a strategic perspective. People are excited about WebAssembly right now, and you seem to want to work on winit's support for it right now, so it seems like a good way to make people happy. I imagine there's a way we can handle this that would be reasonably correct, but I truthfully know very little about WebAssembly. It's something that interests me (the bulk of my past experience is in web dev), but I'm too busy with the other backends to be able to provide any insights here yet. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#395 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRfXf4NDKWJNUe9GB65YSJvTDnj2XLvks5tsfJkgaJpZM4R3m__> .

[anderspitman]

My current tentative plan is to make a prototype web backend for Winit
using stdweb or wasm-bindgen

@icefoxen @francesca64 I've been considering working on this exact thing the past couple days when I came across this thread. The focus for the project I need it for is to have enough windowing to handle a WebGL context.

@icefoxen have you started working on this? I would love to tag team it if you can use the help.

[icefoxen]

@anderspitman I haven't started working on it yet, apart from writing a prototype WebIDL-to-Rust compiler. fitzgen of the wasm_bindgen team suggested that they would welcome incorporating it into wasm_bindgen but I haven't had time for it. Once that's done we could use it to create a crate similar to stdweb except entirely machine generated; browser-api-sys or something.

It's just been a really busy couple months. :-(

[ryanisaacg]

I'd love to help with any work on this, if there is any.

[anderspitman]

The more I've thought about this, the more I agree with @tomaka that it isn't 100% obvious how this would/should be integrated directly into winit. It's definitely desirable to be able to abstract away the windowing. It's not hard to imagine a world where gfx's OpenGL ES backend can be used with winit to write apps that almost seamlessly compile to desktop and WebGL (and hopefully eventually mobile), similar to what emscripten does.

@ryanisaacg I've been really impressed with how you've gotten this to work with quicksilver. Do you have any high-level insights or lessons learned that might help guide the design of doing something similar with winit?

I've been getting my feet wet with wasm-bindgen recently, and it's fantastic, but I haven't played with stdweb yet.

[ryanisaacg]

I actually have now done the wasm bindings twice: once hand-writing each binding in Rust and Javascript, and once with stdweb.

The first way involves a lot of custom boilerplate: basically re-implementing emscripten like tomaka wants to avoid. However, actually using emscripten is prohibitively difficult so I still preferred my way. This is fairly similar to the wasm-bindgen experience, as you have to write out the binding for each API you use in Rust. On the other hand, bindgen allows you to skip writing JS as far as I can tell.

The stdweb way honestly felt halfway like writing for a real Rust platform. There is no sound API support in stdweb (not an issue for winit obviously) and some functionality required writing some javascript bindings myself.

[anderspitman]

When you say stdweb felt halfway like writing for a real Rust platform, do you mean that it feels half-baked/hacky, or like it's almost there and with some work it could be a great approach? Or maybe I'm missing your meaning entirely.

[anderspitman]

It seems to me like a good high-level user story would be getting ggez to compile to WebAssembly with minimal knob-turning. There's already interest in that working eventually.

[ryanisaacg]

It's like writing for a real Rust platform (albeit a very odd one, being on the web rather than the desktop) but there are definitely holes in the API where you need to write Javascript bridges using the js! macro.

[ryanisaacg]

So I've taken a look at the emscripten backend and it seems not-too-difficult to port it to stdweb. First there are one or two features that should be added to stdweb (one I've already done is DPI support); then I should be able to make the port relatively quickly.

[beatgammit]

Could a simple workaround for now be an environment variable or cargo feature to tell winit to build for web? Idk how long it'll take for a wasm32-unknown-webapi target to become a thing, but it seems we could get development going now with that flag.

I'd like to start experimenting with WASM ggez and winit, but for now I'll probably play with quicksilver. I may have time to help with a winit WASM uplift if we have a clear direction forward.

[ryanisaacg]

@beatgammit I did start a WASM port ( #589 ) but we determined it would be best to just wait for the new EventsLoop 2.0 ( #459 ). Also I'm a bit heads-down in getting the next version of Quicksilver out the door, so even if we forged ahead with an EventsLoop 1.0 version, it would probably take me a few weeks to get to it.

[beatgammit]

Makes sense. I know both ggez and quicksilver are interested in this and I didn't want to wait on compiler support if it's not technically a blocker.

I'm trying to help out where I can with ggez (I'm using both for different reasons in a couple projects), and the next step for both ggez and quicksilver seems to be wasm support with winit. I'm interested in beta-testing whatever is available for wasm, hence why I want to see if there's something we can agree on to get winit "started" (and by started, I meant ready for work).

[newpavlov]

I completely agree that we need wasm32-web-unknown or a similar target(s). But for now rand uses two features wasm-bindgen and stdweb one of which should be enabled by user, maybe the same approach can be used for winit?

cc rustwasm/team#38

[est31]

stdweb PR has been opened by @ryanisaacg: #797

[spennydl]

I'd be keen on building out a wasm-bindgen backend if you're interested in it. I have a working prototype sketched out, can I open a pr?

[goddessfreya]

Go for it, @spennydl !

[elinorbgr]

@spennydl you might want to work directly on the eventloop-2.0 branch for that, similarly to #797

[spennydl]

#845 - wasm-bindgen pr is open

[est31]

@ryanisaacg thanks for fixing this! ❤️