3 ms·
As we nowadays compile TS to JS anyways, it would be a small step to go full WASM and have language agnosticism mostly. A bit related: I still do not really un
by weinzierl 3y ago
As we nowadays compile TS to JS anyways, it would be a small step to go full WASM and have language agnosticism mostly.
A bit related:
I still do not really understand why WASM has no direct DOM access.
Answers to this question seem to fall into two categories:
- We don't need it, because you can do everything via a Javascript detour easily
- We don't want it for reason X
To me both feel a bit like excuses. I've yet to see a hard technical reason why it is not done. So, why not make WASM a first class citizen and do away with Javascript for good?
- K0nserv 3y agoMy understanding is that the main limitation is technical. WASM doens't do GC or the host system calling conventions and cannot interact directly with object from Javascript because of this. However, this is being worked[0] on and will be solved eventually. Even without this, the performance overhead of bridging to JS is low enough that WASM frameworks can beat out React. 0: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
- davexunit 3y agoIn addition to GC, the stringref extension is another crucial one for enabling easy interop with JS. Fingers crossed that both make it past the finish line. GC seems pretty much certain, but not sure about stringref.
- echeese 3y agoBecause DOM access would have bloated the MVP, and you _can_ access the DOM through JS.
- bartimus 3y agoI would imagine it a security risk to allow attackers accessing the DOM through WASM. Adding complexity to the sandbox environment.