4 ms·
WebAssembly has 64-bit integers and 32-bit floating points, which is difficult to do fast in JavaScript because everything is 64-bit floating points there. (32-
by sanxiyn 8y ago
WebAssembly has 64-bit integers and 32-bit floating points, which is difficult to do fast in JavaScript because everything is 64-bit floating points there. (32-bit integers are exact in 64-bit floating points, so that works.) This is the main advantage.
WebAssembly is also easier and faster to parse for now, but won't be for long, because JavaScript binary AST work is in progress: https://github.com/binast https://github.com/binast
JavaScript has better access to DOM and is superior otherwise.
- mastrsushi 8y agoWouldn't fixed 64-bit integers be more of a memory usage issue than performance? I'd argue that having to decide between 32 and 64 would unavoidably add some slow down.
- sanxiyn 8y agoWebAssembly 64-bit integer arithmetics compile to machine instructions on 64-bit architectures. To do that in JavaScript, you need to pattern match on long multiplication emulated with 32-bit integers.
- MiroF 8y agoAnd wasm is a compilation target for languages that aren’t JS, a pretty big advantage in my book
- sanxiyn 8y agoJS also is a compilation target for languages that aren't JS, so that is no advantage. What advantage there is boils down to 64-bit integers and 32-bit floating points.
- MiroF 8y agoJS is not a real compilation target for compilers like LLVM and to suggest to the contrary is silly. JS is a transpilation target and not really for many low level languages.
- dragonwriter 8y ago> JS is not a real compilation target for compilers like LLVM [...]. > JS is a transpilation target Transpilation is a subset of compilation, so if it is a transpilation target it is, by definition, a compilation target.