3 ms·

> And performance wise it gets them a lot of benefits. I am not convinced about that for two reasons: 1. Good money has been invested into making JS fast. If

> And performance wise it gets them a lot of benefits. I am not convinced about that for two reasons: 1. Good money has been invested into making JS fast. If you look at actual benchmarks it is currently quite easy to end up in a situation were your WASM-based solutions might perform WORSE. So at least for now the performance advantages are not that great to begin with. 2. On the frontend, you still need JS to use the DOM. Getting data back and forth from JS to WASM can become a bottleneck. Plus rare processing speed is rarely an issue on the frontend and IO-bound stuff is something JS is already good at. If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support. (Edit: If you are after performance mainly and don't care about sandboxing and other advantages.) Yes, if you need to do some image processing on the frontend or want your users to mine crypto for you, yes WASM has already uses but generally I am a bit skeptical. Now WASM is awesome for getting you the C/C++/Rust world in the browser, sure. The performance improvements might be overrated though considering the additional development costs compared to just using JS. (That was more a dig at the WASM hype in general, of course. Not meant to throw any specific shade at AssemblyScript. Still an interesting project regardless.)

DanielHB 4y ago
1. While true, in practice what I have tested it is that the performance is very, very rarely worse (although often it is negligible difference). The thing is wasm performance is predictable. This is really important for graphics and games since there is no JIT going on, JS (and python, ruby, etc) performance can vary widely based on how often a codepath is used 2. This is planned to change with Interface Types which will let you call any DOM method from any wasm code without without custom bindings and performance hit as well as, for example, calling a python module from golang for example (as long as both are compiled to wasm) I recommend this article about it: https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type... > If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support. the main point of wasm outside of browsers is sandboxing and compatibility, a whole set of applications become possible when you have that. A simple example are SaaS application that let users upload wasm plugins that run on the SaaS application servers > If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support. wasm is just one part of the puzzle, the other one is WASI which is poised to become a standard interface for OS interaction. With it you could conceivably have a single binary for any OS+processor architecture (as long as there is wasm runtime + the parts of WASI required by your app implemented). This is huge for embedded development, I myself spent insane amounts of time trying to get shit compiled to different OS+architecture
- RobbieGM 4y ago
  The interface types proposal seems to have been dead for a while, unfortunately.
riquito 4y ago
> If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support. - Cross-compiling is perhaps easier these days, but it's still a pain to set up and takes time to compile - WASM has compelling sandboxing abilities, I can see myself choosing a slower sandboxed client tool vs native binary, in particular to try out new stuff
maxgraey 4y ago
> If you don't do frontend stuff, you don't have to use WASM, you know? WebAssembly is excellent for: - Game's scripting engine (UE plugin example: https://www.reddit.com/r/unrealengine/comments/na6hfx/integrated_a_full_webassembly_vm_into_the_engine https://www.reddit.com/r/unrealengine/comments/na6hfx/integr...) - Rule engine for ServerLess scenarios (See Lucet) - For node.js plugins instead native plugins. Webpack uses AS for hash calculations: https://github.com/webpack/webpack/tree/main/assembly/hash https://github.com/webpack/webpack/tree/main/assembly/hash - For smart contracts of blockchain. AssemblyScript uses for Near Protocol, The Graph Protocol, Cosmos and many others

DanielHB 4y ago

1. While true, in practice what I have tested it is that the performance is very, very rarely worse (although often it is negligible difference). The thing is wasm performance is predictable. This is really important for graphics and games since there is no JIT going on, JS (and python, ruby, etc) performance can vary widely based on how often a codepath is used 2. This is planned to change with Interface Types which will let you call any DOM method from any wasm code without without custom bindings and performance hit as well as, for example, calling a python module from golang for example (as long as both are compiled to wasm) I recommend this article about it: https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type... > If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support. the main point of wasm outside of browsers is sandboxing and compatibility, a whole set of applications become possible when you have that. A simple example are SaaS application that let users upload wasm plugins that run on the SaaS application servers > If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support. wasm is just one part of the puzzle, the other one is WASI which is poised to become a standard interface for OS interaction. With it you could conceivably have a single binary for any OS+processor architecture (as long as there is wasm runtime + the parts of WASI required by your app implemented). This is huge for embedded development, I myself spent insane amounts of time trying to get shit compiled to different OS+architecture

RobbieGM 4y ago
The interface types proposal seems to have been dead for a while, unfortunately.

riquito 4y ago

> If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support. - Cross-compiling is perhaps easier these days, but it's still a pain to set up and takes time to compile - WASM has compelling sandboxing abilities, I can see myself choosing a slower sandboxed client tool vs native binary, in particular to try out new stuff

maxgraey 4y ago

> If you don't do frontend stuff, you don't have to use WASM, you know? WebAssembly is excellent for: - Game's scripting engine (UE plugin example: https://www.reddit.com/r/unrealengine/comments/na6hfx/integrated_a_full_webassembly_vm_into_the_engine https://www.reddit.com/r/unrealengine/comments/na6hfx/integr...) - Rule engine for ServerLess scenarios (See Lucet) - For node.js plugins instead native plugins. Webpack uses AS for hash calculations: https://github.com/webpack/webpack/tree/main/assembly/hash https://github.com/webpack/webpack/tree/main/assembly/hash - For smart contracts of blockchain. AssemblyScript uses for Near Protocol, The Graph Protocol, Cosmos and many others