1. 16

  2. 2

    That’s some potential for a rebirth of the demoscene. Portability of the abstract machine plus all opportunities for hand-coded optimization for size. I hope soon it will be possible to run such programs without JS wrapping, just load them with <script> and point them to a canvas element.

    1. 1

      Why is it desirable to get rid of JS wrapping here? I guess it’s a bit more tidy. Anything else?

      1. 1

        Why use many language when few will do?

        Also, it would be nice to do all the relevant Web API things from WASM.

        1. 1

          Why would it be nice to do all Web API from WASM (apart from preference)? Since all web API need to be available to JS as well, it would just increase code for binding, not reduce it.

          1. 1

            Because of the runtime and complexity costs of using 3 systems (WASM, JS, Browser engine (Rust or CPP)).

            If you can just create WASM blobs that do it all then there are fewer things to get wrong and you don’t have to context shift to another language.

            1. 1

              Eh, I meant, you can already do that, no browser modification is needed. My question was what is rationale for implementing WASM binding in browser, as opposed to using existing JS binding in browser through WASM/JS interface.

              1. 2

                I think you’re talking about the rust toolchain wasm_bindgen stuff?

                I think that is bad because even though the developer doesn’t need to use JS, the machine still has to (and moving through multiple languages is more expensive) and someone has to write that bindgen infrastructure correctly for each language that compiles to WASM and wants Web API stuff.