undefined | Better HN

0 pointsduxup6y ago0 comments

That sounds like the use case would be to insert some WASM component (that is a big heavy application / operation) into traditional web application framework as needed.

Less so an entire overhaul of web applications as it is a powerful tool to be deployed for things we don't do in the browser now because there is no way to / it would be a bear to do in JavaScript due to ... JavaScript being JavaScript ;)

Of course the amount of WASM to traditional JS or anything else could vary from application to application.

Granted we're predicting the future here so obviously it could be off.

0 comments

ajross6y ago

Really the only available use case is inserting a wasm component into a traditional web application framework. Wasm code can only be loaded from JS, it can only be invoked from JS, and it's only way to affecting the world outside the VM is to call functions in JS that are going to do something to a user-visible DOM.

This is all still traditional web development. It's just a way to target other runtimes to a sandbox in the same environment.

krapp6y ago

>Wasm code can only be loaded from JS, it can only be invoked from JS, and it's only way to affecting the world outside the VM is to call functions in JS that are going to do something to a user-visible DOM.

Incorrect. WASM was designed from the beginning to be run both on and off the web[0], and native clients already exist[1].

[0]https://webassembly.org/docs/non-web/

[1]https://github.com/mbasso/awesome-wasm#non-web-embeddings

voxic116y ago

Actually with the WebAssembly System Interface you can interface WebAssembly with any platform, it doesn't need to be a javascript vm. https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...

j / k navigate · click thread line to collapse