Hacker News Reader

Comment by throw14082020 | Hacker News Reader

throw14082020

I should've been clearer, sorry.

The verbosity and complexity of `wasm_bindgen`/serialization between JS and Wasm (written in Rust) is primarily the thing I am frustrated at here when I see hundreds and thousands of Rust code. A concrete example: creating a Websocket client in Javascript/Typescript vs in Rust/Wasm.

In general though (outside of Wasm), Rust is less readable.

And with regards to Rust errors, I've found Rust errors related to Tonic and Diesel to be quite annoying/unreadable. The Diesel docs seem to blame Rust for this (can't find the docs for it right now).

View on HN

Isn't this due to wasm having to access browser things mostly through browser JS interfaces?

eg Browsers provide JS functions that are intended for JS, which are not directly exposed to Wasm. So when your Wasm wants to access DOM things, access DOM functions, (etc) it needs to go through a JS shim layer instead of being able to call them directly.

If the browser dev's (or some W3C type of body?) introduced those same functions, but had them be directly accessible from wasm, then the JS shims wouldn't be needed.

The JS dev's for each of the browsers though would probably try and stop it ("security risk!" excuses, etc) though, as that would potentially cut into "their territory" and allow other languages to compete. :(

Expanding WASM to the DOM is definitely part of the roadmap. The problem at the moment, as I understand it, is that the DOM was designed with Javascript in mind, and figuring out how to translate that into something that works well for lower-level access is difficult, particularly in regards to getting garbage collection to work properly between WASM-land and JS-land. There are some alternative solutions that are being explored, but none of this has anything to do with security risks.

I hope you're right, and it does end up happening. That would very much enable many languages (LLVM based ones anyway) to become practical alternatives to JS for web dev, whereas now they're more like "can be sorta done with significant effort". ;)

Btw, my impression that it would be blocked by JS people involved in the process, was from a conversation some time ago with one of the JS people themselves.

They said (from their point of view) there's no need for WASM to directly access things instead of going through JS, and they'd block it themselves if things went that direction. Security was the lever they mentioned they'd probably be able to use.

I believe the project is called Interface Types.

Reply on news.ycombinator.com