JavaScript code is much more expensive, byte for byte, than an image, because of the time spent parsing and compiling it. It's possible to parse and compile wasm as fast as it comes over the network, which makes it much more like an image than JavaScript code. Game changer!
-
-
Replying to @wycats
This is indeed very cool, but in my experience so far WASM programs tend to be much bigger than equivalent JS programs, which undercuts the advantage, in some cases quite significantly.
4 replies 0 retweets 15 likes -
interesting! This doesn't align with my experience so I'm legit curious, is this asm.js vs wasm or handwritten JS vs wasm? What source language and compiler?
1 reply 0 retweets 9 likes -
Replying to @_jayphelps @wycats
handwritten JS vs Rust wasm with native Rust compiler. asm.js is always bigger than equivalent wasm in my (very limited) experience, and Emscripten programs are enormous. What have you seen?
#inquiringmindswanttoknow2 replies 0 retweets 7 likes -
Replying to @xander76 @_jayphelps
Are you running wasm-gc against the final program? Important to keep in mind: JS is not a little more expensive than an image, it's massively more expensive. So even a 3-5x larger wasm might pay off from reduced parse and compile times. This was my point.
3 replies 0 retweets 13 likes -
Replying to @wycats @_jayphelps
I am using wasm-gc; it’s very cool! Even so, there are cases in my microbenchmarks where wasm ends up wayyyy bigger (like 300x) because of stdlib. But as
@_jayphelps points out, in a large the stdlib probably gets amortized. And I do wonder how binary-ast will change things.1 reply 0 retweets 1 like
Another factor: rust hasn't quite gotten its wasm ecosystem revved up. It already has a decent no_std ecosystem but we need a lot more to make things nice and small for wasm. High priority for early 2018 for us.
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.