4 ms·

"Definitely some feeling of being rug-pulled in the shift here." Definitely feeling rug-pulled. What I think all the people that hark on the "Don't worry, goi

"Definitely some feeling of being rug-pulled in the shift here." Definitely feeling rug-pulled. What I think all the people that hark on the "Don't worry, going through JS is good enough for you." are missing is the subtext of their message. They might objectively be right, but in the end what they are saying is that they are content with WASM being a second class citizen in the web world. This might be fine for everyone needing a quick and dirty solution now, but it is not the kind of narrative that draws in smart people to support an ecosystem in the long run. When you bet, you bet on the rider and not the domestique.

flohofwoe 1y ago
> that they are content with WASM being a second class citizen in the web world Tbh, most of the ideas so far to enable more direct access of Javascript APIs from WASM have a good chance of ruining WASM with pointless complexity. Keeping those two worlds separate, but making sure that 'raw' calls between WASM and JS are as fast as they can be (which they are) is really the best longterm solution. I think what people need to understand is that the idea of having 'pure' WASM browser applications which don't involve a single line of Javascript is a pipe dream. There will always be some sort of JS glue code, it might be generated and you don't need to directly deal with it, but it will still be there, and that's simply because web APIs are first and foremost designed for usage from Javascript. Some web APIs have started to 'appease' WASM more by adding 'garbage free' function overloads, which IMHO is a good thing because it may help to reduce overhead on the JS side, but this takes time and effort to be implemented in all browser (and most importantly, a will by mostly "JS-centric" web people to add such helper functions which mostly only benefit WASM).
- Spivak 1y ago
  Wouldn't the path forward be that the browser acts more like a kernel with a syscall interface which both V8 and WASM use? You wouldn't access "Web APIs" from WASM because those would be written in JS but you get access to the same primitives used to implement the JS API. Sure, probably equally a pipedream but if there was any serious effort to make WASM a first class citizen in the browser it would probably be something like this rather than a crappy FFI to JS which has to obey JS semantics and deal with JS types.
  - flohofwoe 1y ago
    Yeah something like that would be nice, it would probably increase the attack surface though (since each internal web api implementation now has two surfaces, one that's exposed to JS and one lower level C-like API that directly connects to the WASM import table).
    - int_19h 1y ago
      The security boundary in this scenario would be the "syscall" layer. If it's secure by itself, then any higher-level wrapper on top of it is also secure.
- int_19h 1y ago
  > There will always be some sort of JS glue code, it might be generated and you don't need to directly deal with it, but it will still be there, and that's simply because web APIs are first and foremost designed for usage from Javascript. Historically, at least, web APIs were designed for usage from all kinds of languages, which is precisely why e.g. the DOM API is defined using IDL. There's no reason why we can't get back to that situation. WinRT shows how you can have a high-level object-oriented API that can be projected into different languages in ways that reflect idiomatic use in those languages (e.g. projecting promises differently to allow for async/await to work everywhere).
zihotki 1y ago
One could say second class, another could say that's a good separation of concerns. Having direct access would lead to additional security issues and considerations. I wish it was possible to disable WASM in browsers.
- flohofwoe 1y ago
  > I wish it was possible to disable WASM in browsers. In Firefox at least: navigate to about:config and then `javascript.options.wasm => false` seems to do the job. This causes any access to the global WebAssembly object to fail with `WebAssembly is not defined` (e.g. it won't be possible to instantiate wasm blobs).
sidewndr46 1y ago
I'm always baffled by the crowd that suggests "Just use Javascript to interface it to the DOM!". If that's the outcome of using WASM, couldn't I just write Javascript?
- Muromec 1y ago
  Maybe you should just write javascript. What's wrong with that.
- fabrice_d 1y ago
  Indeed, you should. I haven't found a Rust UI project that compiles to Wasm and has good ergonomics; they all seem to make the mistake of being frameworks that control the whole app lifecycle and reinvent either markup or cumbersome ways to build your UI. What would be nice is to use Wasm for component libraries instead, or for progressive enhancement (eg. add sophisticated autocomplete support to an input field).

flohofwoe 1y ago

> that they are content with WASM being a second class citizen in the web world Tbh, most of the ideas so far to enable more direct access of Javascript APIs from WASM have a good chance of ruining WASM with pointless complexity. Keeping those two worlds separate, but making sure that 'raw' calls between WASM and JS are as fast as they can be (which they are) is really the best longterm solution. I think what people need to understand is that the idea of having 'pure' WASM browser applications which don't involve a single line of Javascript is a pipe dream. There will always be some sort of JS glue code, it might be generated and you don't need to directly deal with it, but it will still be there, and that's simply because web APIs are first and foremost designed for usage from Javascript. Some web APIs have started to 'appease' WASM more by adding 'garbage free' function overloads, which IMHO is a good thing because it may help to reduce overhead on the JS side, but this takes time and effort to be implemented in all browser (and most importantly, a will by mostly "JS-centric" web people to add such helper functions which mostly only benefit WASM).

Spivak 1y ago
Wouldn't the path forward be that the browser acts more like a kernel with a syscall interface which both V8 and WASM use? You wouldn't access "Web APIs" from WASM because those would be written in JS but you get access to the same primitives used to implement the JS API. Sure, probably equally a pipedream but if there was any serious effort to make WASM a first class citizen in the browser it would probably be something like this rather than a crappy FFI to JS which has to obey JS semantics and deal with JS types.
- flohofwoe 1y ago
  Yeah something like that would be nice, it would probably increase the attack surface though (since each internal web api implementation now has two surfaces, one that's exposed to JS and one lower level C-like API that directly connects to the WASM import table).
  - int_19h 1y ago
    The security boundary in this scenario would be the "syscall" layer. If it's secure by itself, then any higher-level wrapper on top of it is also secure.
int_19h 1y ago
> There will always be some sort of JS glue code, it might be generated and you don't need to directly deal with it, but it will still be there, and that's simply because web APIs are first and foremost designed for usage from Javascript. Historically, at least, web APIs were designed for usage from all kinds of languages, which is precisely why e.g. the DOM API is defined using IDL. There's no reason why we can't get back to that situation. WinRT shows how you can have a high-level object-oriented API that can be projected into different languages in ways that reflect idiomatic use in those languages (e.g. projecting promises differently to allow for async/await to work everywhere).

zihotki 1y ago

One could say second class, another could say that's a good separation of concerns. Having direct access would lead to additional security issues and considerations. I wish it was possible to disable WASM in browsers.

flohofwoe 1y ago
> I wish it was possible to disable WASM in browsers. In Firefox at least: navigate to about:config and then `javascript.options.wasm => false` seems to do the job. This causes any access to the global WebAssembly object to fail with `WebAssembly is not defined` (e.g. it won't be possible to instantiate wasm blobs).

sidewndr46 1y ago

I'm always baffled by the crowd that suggests "Just use Javascript to interface it to the DOM!". If that's the outcome of using WASM, couldn't I just write Javascript?

Muromec 1y ago
Maybe you should just write javascript. What's wrong with that.
fabrice_d 1y ago
Indeed, you should. I haven't found a Rust UI project that compiles to Wasm and has good ergonomics; they all seem to make the mistake of being frameworks that control the whole app lifecycle and reinvent either markup or cumbersome ways to build your UI. What would be nice is to use Wasm for component libraries instead, or for progressive enhancement (eg. add sophisticated autocomplete support to an input field).