|
|
|
|
|
|
by wongarsu
103 days ago
|
|
|
At least the DOM APIs are ostensibly designed to work in multiple languages, and are used by XML parsers in many languages. Some of the newer Web APIs would be difficult to port. But the majority of APIs have quite straight forward equivalents in any language with a defined struct type (which you admittedly do have to define for WASM, and whether that interface would end up being zero-copy would change depending on the language you are compiling to wasm) There is no solution without tradeoffs here, but the only reason JS-glue-code is winning out is because the complexity is moved from browsers to each language or framework that wants to work with wasm |
|
|
Correct, but this is has been one of wasm's guiding principles since the start: move complexity from browsers to toolchains.
Wasm is simple to optimize in browsers, far simpler than JavaScript. It does require a lot more toolchain work! But that avoids browser exploits.
This is the reason we don't support the wasm text format in browsers, or wasm-ld, or wasm-opt. All those things would make toolchains easier to develop.
You are right that this sometimes causes duplicate effort among toolchains, each one needing to do the same thing, and that is annoying. But we could also share that effort, and we already do in things like LLVM, wasm-ld, wasm-opt, etc.
Maybe we could share the effort of making JS bindings as well. In fact there is a JS polyfill for the component model, which does exactly that.