3 ms·
And LLVM can do better than those in turn, would I prefer if we were using LLVM as the underlying target for machine code? Hell yeah I would, but we’re not quit
by FridgeSeal 8y ago
And LLVM can do better than those in turn, would I prefer if we were using LLVM as the underlying target for machine code? Hell yeah I would, but we’re not quite there yet, and if it’s a toss up between the JS powered 3MB+ websites and endless shitty electron apps or WASM, I’m going to elect for WASM.
At least with WASM if it takes off, it can at least path the way for a more better and more appropriate (LLVM, AoT CLR, etc) universal machine code later down the line. That’ll never happen if we’re chained to JS though.
- deleted 8y ago[deleted]
- pjmlp 8y agoI rather have the AOT compile times from Java and CLR based toolchains. As for LLVM as the underlying target for machine code, it is already a thing, nothing new here. https://www.imsystech.com/high-level-languages/ https://www.imsystech.com/high-level-languages/ https://www.infoq.com/articles/ios-9-bitcode https://www.infoq.com/articles/ios-9-bitcode
- jashmatthews 8y agoLLVM _is_ the backend for Mono. It's easier for LLVM to produce better code if it doesn't have to go via a register based bytecode VM like WebAssembly. Was discussed here not so long ago: http://troubles.md/posts/wasm-is-not-a-stack-machine/ http://troubles.md/posts/wasm-is-not-a-stack-machine/
- Volt 8y ago>and if it’s a toss up between the JS powered 3MB+ websites and endless shitty electron apps or WASM, I’m going to elect for WASM. I don't know why you think the situation would improve with WASM.