search

jakobhellermann / bevy_mod_js_scripting

Other
83 stars 6 forks source link

Thoughts on Seamless Browser Support #6

Closed zicklag closed 1 year ago

zicklag commented 2 years ago

I've just gotten this integrated with the game I'm working on and I have to say this is really great work, thanks!

In the game I'm working on, first-class support for the browser is very important, and I'm hoping to be able to support scripting with JS/TS identically both for native and the browser.

My current plan/prototype for this is to use wasm_bindgen to leverage the browser's native JS engine for running scripts in the web version of the game.

This meant I made some different decisions for how to structure the execution on native that you did in this project, so that I could accomplish and effectively similar execution pattern in the browser, where I don't have control over separate execution contexts, etc.

To get to the point, I was wondering what your thoughts on integrating browser support into this repo would be.

I ended up copying and tweaking your deno ops to get this working in my game, but if you were open to browser support and some modificiations to the way that native execution worked, then I could contribute here instead.

Someone did express concerns that using the native browser engine wouldn't be very performant, and that is a distinct possibility, but I'm having a hard time finding a good JavaScript engine with bindings to Rust that will also compile to WASM on the wasm32-unknown-unknown target, so binding through WASM-bindgen seemed like a decent workaround, and we could test to see if performance becomes an issue.

I still might find a way to get a small JavaScript engine to compile to WASM with Rust, so it still might be a possibility.

jakobhellermann commented 2 years ago

My thoughts on that for this project were basically "it should be possible to use the browsers native engine using wasm_bindgen somehow, but I haven't given it much further thought" so far. I expect that we will end up defining the exact API boundary in terms of some d.ts declarations, and then there can be multiple backends (deno, wasm_bindgen) implementing that API.

Someone did express concerns that using the native browser engine wouldn't be very performant

I'm not sure why that would have performance problems, it seems much easier and faster than interpreting Javascript inside a wasm-compiled engine inside the native browser wasm/JavaScript engine.

zicklag commented 2 years ago

I expect that we will end up defining the exact API boundary in terms of some d.ts declarations, and then there can be multiple backends (deno, wasm_bindgen) implementing that API.

Sweet, that's exactly what I was thinking! And I've already been able to prove that concept out with a logging API, I just hadn't implemented the ECS API yet.

it seems much easier and faster than interpreting Javascript inside a wasm-compiled engine inside the native browser wasm/JavaScript engine.

That was my initial thought, too, because, for instance, if we're running in Chrome, which is running v8, it'd be better to run on v8 natively than to try and Run another JS engine in WASM on v8.

The user that brought up the issue thought that it would be faster to do in WASM 'cause you don't have to copy stuff out of WASM memory, you can "just pass references", but you still have to copy to-from the JS heap inside the WASM memory anyway, so I don't know that there's much of a different.

The only thing I can think of right off that would be an issue is passing the path strings every time you do an equivalent to op_value_ref_get or set.

I once ran into a performance hit when sending uniform name strings from WASM to the browser for WebGL rendering, until I interned the strings so that they would be cached on the JavaScript side. We might be able to do a similar kind of caching on the path strings to fix that, though, if we run into it.

Anyway, it sounds like we're on the same page for the most part, so I'll open a PR that shows the approach I'm using in the game I'm working on, and we can collaborate from there, if that sounds good to you.

jakobhellermann commented 1 year ago

I think this can be closed now that web support is in, anything new deserves a new issue