4 ms·
Can someone explain to me what makes Wasm any better and/or different than Javascript bytecode.
by mastrsushi 7y ago
Can someone explain to me what makes Wasm any better and/or different than Javascript bytecode.
- sanxiyn 7y agoWebAssembly 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 7y 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 7y 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 7y agoAnd wasm is a compilation target for languages that aren’t JS, a pretty big advantage in my book
- sanxiyn 7y 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 7y 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 7y 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.
- fauigerzigerk 7y agoWasm exists, whereas there is no standard JavaScript bytecode specification.