4 ms·
And isn’t Wasm supposed to (some day) free us from the need to pick JS for the front end?
by biztos 4y ago
And isn’t Wasm supposed to (some day) free us from the need to pick JS for the front end?
- ggktk 4y agoUnfortunately, that doesn't seem the way WASM is going. It's been 5 years and we still can't access the DOM without going through JS.
- jpgvm 4y agoThere isn't the political will-power to make it happen and force all the browser vendors to agree and implement. Hence status-quo remains.
- afiori 4y agoWhich is ironic as the DOM interface was designed as an abstract interface (the IDL used in the spec is more interested in compatibility with Java than JS). In practice though the main reason is that to have decent DOM bindings you need to stabilize many other specs first (unless you do a ultra-specific DOM-only extension, but nobody wants that)
- marcosdumay 4y agoWASM can access the DOM by its foreign functions interface. It still needs some data conversion, but it's not through JS. Rust, for example, has a huge package with interfaces for every DOM function.
- szundi 4y agoI am waiting to be able to run the JVM and have client side swing again in WASM
- pjmlp 4y agoWhy waiting when it is already available?
- marcosdumay 4y agoI have been very successful in replacing a JS browser application with Rust. It has been great, because Rust is much easier to change, and since the application is complex, I need to change it a lot. But I wouldn't recommend it in general, because JS (and for slightly more complex things, TS) is much easier to create because of all the old Rust features that surface every time you mention it. And most GUI code is simple enough that you only have to write once, maybe fix a few details, and forget about it. Wasm would be much more compelling if it was target by higher level languages.