This all misses the bigger point: WASM isn't actually an assembly for the web; it's more of a math co-processor. Limited applications for forseeable future = \https://twitter.com/callahad/status/937728124451786752 …
-
-
Replying to @slightlylate
I don’t agree. Runtime performance gains of wasm are marginal. I think a more significant improvement is the compact binary, short parse time and the removed need for optimisation / reoptimisation. On mobile this could mean apps load much faster.
2 replies 0 retweets 3 likes -
Replying to @ColinEberhardt
It's possible! Haven't seen evidence, but perhaps usual, that'd sway my view. Naively, tho, WASM binaries are larger on the wire than JS & massive challenge today is binary size.
3 replies 0 retweets 1 like -
Replying to @slightlylate
Just FYI, I compared a minified JS mandlebrot algorithm, 805 byte, with the same in WebAssembly (C compiled via a simple LLVM toolchain), which resulted in a 596 byte WASM file -https://github.com/ColinEberhardt/wasm-mandelbrot …
1 reply 1 retweet 0 likes -
Replying to @ColinEberhardt
How much code are you adding to thunk in/out?
1 reply 0 retweets 0 likes -
Replying to @slightlylate
for mandelbrot, not much - but that plays to the current strengths of WASM. To your earlier point, the JS / WASM interface needs a lot of work. No support for simple stuff like strings, let alone objects and more complex types
1 reply 0 retweets 0 likes
There is no string type which is actually "simple".
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.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.