4 ms·
Are you compiling C or Rust to WASM? In my experience their LLVM backend is the best developed. WASM shines for numeric computation like encoding, decoding, en
by throwaway189262 6y ago
Are you compiling C or Rust to WASM? In my experience their LLVM backend is the best developed.
WASM shines for numeric computation like encoding, decoding, encryption.
In the benchmarks I've seen, image encoding is 10-20X faster in WASM. Crypto is about the same speed as WebCrypto which isn't available in all browsers and runs native code.
There's an unmistakable performance advantage for compute heavy workloads.
- vanderZwan 6y agoI know in which niches WASM already shines, my point is that I have a different one and wish I could effectively use WASM there as well.
- throwaway189262 6y agoYou could, but you would have to move most of the app into WASM. I think it's inevitable for WASM to replace JS eventually. We're just in the early days. WASM has 2-5X performance advantage for "most" workloads. It also parses much faster and is more compact than minified JS. Eventually the performance advantages will be too large to ignore
- pansa2 6y ago> I think it's inevitable for WASM to replace JS eventually. Do you think front-end developers will start writing C/C++/Rust instead of JavaScript? Or do we need other languages that can compile to WASM before it can replace JS?
- throwaway189262 6y agoI think it will be like back end, a mix of Java/C#/C++. JS isn't a great language, it's only popular because you can't use anything else on the web. The massive popularity of Typescript, even though it's only syntax sugar on top of JS, shows that the language leaves a lot to be desired. It doesn't support threading, doesn't compile, has garbage standard library. And it's slower and more memory hungry than languages with these features like C# and Java. There's talk of adding a "universal" GC to WASM. When this happens you'll see "traditional" enterprise languages invade enmasse
- cestith 6y agoI'm not the parent poster, but I think it's quite possible we see JavaScript, TypeScript, and maybe even CoffeeScript and ActionScript frontends that target WASM backends. Right now it's possible to support subsets of the languages. As WASM is fleshed out and tools like Nectar/NectarJS and wasm-bindgen improve the workflow might change more than the source language. Mostly unrelated to JavaScript, there's also an effort called JWebAssembly which strives to translate JVM bytecode to WASM's binary (.wasm) or textual (.wat) format. So WASM apps could be written fine in Scala, Clojure, Kotlin, JRuby, or any other JVM language. I think where WASM definitely replaces JavaScript is distribution over the net to browsers for heavy web applications and in Node apps. It's just way more efficient. JS might still have a place for a little bit or bauble on some sites that are mostly static HTML, but things that use huge stacks of JS libraries will have those precompiled to WASM for distribution.