Wasm has a little bit of unfounded hype. But I think it’s a good thing because there is plenty of unfounded skepticism about it and it helps to balance things out.
-
-
-
Replying to @oleg008
I’m not trying to knock wasm. I want a wasm future. But what surprises me is that the wasm hype seems to be coming from JS fans. Wasm isn’t for JS authors. It’s the thing that replaces JS authors.
8 replies 7 retweets 14 likes -
Replying to @jordwalke @oleg008
As a web developer, WASM is interesting because it allows me to use libraries in other languages to solve my browser-based problems. The fact that I do that in JS right now is a historical accident, so I am a JS author, but I'm a web developer first.
3 replies 0 retweets 24 likes -
A couple of observations: Many enjoy building node apps just as much as building web apps. When both environments have the ability to use otherwise native libraries, it puts the whole question of JS-the-language into question. Previously, JS's advantage was running in both places
1 reply 1 retweet 7 likes -
Now, with wasm, not only can you run in both places, but when running outside of the browser, you can run even faster.
2 replies 0 retweets 1 like -
Just a guess, but I'd predict >80% of WASM usage will be deploying non-web code to browser/VMs. Specialising native build targets to gain a few extra percentage point of performance seems like the rare case.
1 reply 0 retweets 3 likes -
The v8 team tells me that WASM is very, very seldom faster than writing well-optimized JS. Bringing the entire universe of existing libraries in other code in JS world is the real attraction of WASM for me. It takes npm from 840,000 packages to millions.
4 replies 2 retweets 29 likes -
Replying to @seldo @robpalmer2 and
To expand on that a little, peak performance of JavaScript and Wasm are roughly the same. What Wasm offers is *predictable* performance — with JavaScript it’s much easier to fall off the fast path.
3 replies 13 retweets 76 likes -
Replying to @mathias @robpalmer2 and
Nice of you to drop in on this thread :-) Would love to hear the latest on how WASM-world expects to tackle A - interacting efficiently with DOM elements from inside WASM B - separate WASM modules interacting efficiently without crossing into JS-land
2 replies 0 retweets 8 likes
A) this is the host bindings proposal https://github.com/WebAssembly/host-bindings … (current status: still being hashed out) B) not sure what you mean exactly; at some point you’d want to go back into JS land and do something with the computed result, right?
-
-
Replying to @mathias @robpalmer2 and
For B I mean: library 1 is written in (say) rust compiled to WASM, library 2 is also rust in WASM, can they pass data efficiently between each other before passing it back to JS? Last I heard this was hard.
1 reply 0 retweets 1 like -
Replying to @seldo @robpalmer2 and
Ah, I see what you mean. Looping in
@binjimint who actually works on Wasm (as opposed to JS) in V8
1 reply 0 retweets 5 likes - 11 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.