It's important to note that WASM doesn't immediately deliver the speed benefits you'd think in all cases right now. Especially when you have to cross the boundary of the module it's in (tested this a while back, browser vendors may have improved this since then). In my tests, it "sometimes does, sometimes doesn't" end up being faster than JS, and it's hard to build intuition around when that will happen consistently. Early days, so that may change, that's just what I see atm.
It's also interesting to note projects like AssemblyScript which open WASM to a Typescript subset. Very cool work they are doing.
When WASM first appeared, I had deep misgivings. I was picturing a dystopia of unmaintainable bytecode springing up everywhere and the WAT format as a hand-wavy dismissal of those concerns. Credit where credit is due, though, the W3C groups working on this are doing a great job and WAT is actually not terrible to read (or even write, if you have an afternoon to burn and want to take it on just to learn a thing or two about WASM - look for the wabt compiler).
Too bad Java was never properly integrated into Web browsers and ended up dying. This is basically what the promise of Java was, way back in 1999 or so.
I think this was useful as a "learn what WebAssembly is" guide. It shows you how to build a wasm module from c++ source code, and how to use your module in a browser.
As a relative web novice, WebAssembly continues to be an incredibly promising tool that has a lot of potential, but remains obtuse on how to actually get a compiled .wasm binary to run properly in the browser. Most of the examples I've seen either are trivial programs like the one here, where they I still feel they pulled things like '_Z3addii' out of a hat. Alternatively, there are some articles that require you to delve into a pile of Node dependencies just to print out 'Hello World'.
I'm pleased to say I've finally uncovered the incantations to interface with a .wasm binary easily, but I was surprised how much digging it required, even with something as hyped as this. Perhaps I should write my own article on my findings.
_Z3addii looks like C++ name mangling - embedding parameter/return type information in the symbol (function) name, required to support C++ features on top of the linkers C++ grew up with.
Declaring the function as `extern "C"` would turn the symbol name into "add", or maybe "_add". I suspect the author extracted the name from compiler-generated assembly or from a tool to list the symbols a .wasm exports.
WebAssembly is not for the faint of heart. Although you can easily output Rust using cargo target, the memory model that interfaces with the browser is completely manual.
Of course you should be able to create really complex algorithms and do really advanced inlining to achieve near native performance. While also working across all platforms that run Chrome/Edge/Safari/Firefox.
I think the question I have is, Figma is one product I know that really takes full advantage of WebAssembly as a full experience. 1Password does another that uses the Chrome extension for it. Would Figma's success have been the same if they had just foregone the hassle of building in WASM and went pure native desktop?
> Would Figma's success have been the same if they had just foregone the hassle of building in WASM and went pure native desktop?
I think Figma’s success can be at least partially attributed to being a web app with good performance. Sharing designs with a URL is a lot quicker than sharing files and importing them into a native desktop app which all users would first need to install. Figma made collaborating on design easier and more accessible than ever.
[+] [-] dccoolgai|5 years ago|reply
It's also interesting to note projects like AssemblyScript which open WASM to a Typescript subset. Very cool work they are doing.
When WASM first appeared, I had deep misgivings. I was picturing a dystopia of unmaintainable bytecode springing up everywhere and the WAT format as a hand-wavy dismissal of those concerns. Credit where credit is due, though, the W3C groups working on this are doing a great job and WAT is actually not terrible to read (or even write, if you have an afternoon to burn and want to take it on just to learn a thing or two about WASM - look for the wabt compiler).
[+] [-] csense|5 years ago|reply
[+] [-] discardable_dan|5 years ago|reply
[+] [-] Sodman|5 years ago|reply
[+] [-] aquova|5 years ago|reply
I'm pleased to say I've finally uncovered the incantations to interface with a .wasm binary easily, but I was surprised how much digging it required, even with something as hyped as this. Perhaps I should write my own article on my findings.
[+] [-] andrewf|5 years ago|reply
Declaring the function as `extern "C"` would turn the symbol name into "add", or maybe "_add". I suspect the author extracted the name from compiler-generated assembly or from a tool to list the symbols a .wasm exports.
[+] [-] jarjoura|5 years ago|reply
Of course you should be able to create really complex algorithms and do really advanced inlining to achieve near native performance. While also working across all platforms that run Chrome/Edge/Safari/Firefox.
I think the question I have is, Figma is one product I know that really takes full advantage of WebAssembly as a full experience. 1Password does another that uses the Chrome extension for it. Would Figma's success have been the same if they had just foregone the hassle of building in WASM and went pure native desktop?
[+] [-] konaraddi|5 years ago|reply
I think Figma’s success can be at least partially attributed to being a web app with good performance. Sharing designs with a URL is a lot quicker than sharing files and importing them into a native desktop app which all users would first need to install. Figma made collaborating on design easier and more accessible than ever.
[+] [-] ishcheklein|5 years ago|reply