
WebAssembly initial steps tutorial - llazzaro
https://tutorials.technology/tutorials/11-webassembly-initial-steps-tutorial.html
======
azakai
Note that the instructions provided here are not the recommended path, which
is described on the main site:

[http://webassembly.org/getting-started/developers-
guide/](http://webassembly.org/getting-started/developers-guide/)

The link here uses a nonstandard approach, which happens to work on a tiny
program as in the example, but won't work on other things (for example, malloc
or printf won't work). It also requires more steps to perform (4 vs 1 in the
main site).

~~~
callahad
What's the expected final toolchain for C -> Wasm? If I understand correctly,
there are at least two competing backends (upstream llvm, emscripten-
fastcomp), as well as several paths through binaryen (s2wasm, asm2wasm)... and
Binaryen seems to have forked the textual format when 0xc landed, and in a way
that won't necessarily round-trip. Which puts me in a place of grokking the
binary format and the WebAssembly.* DOM APIs, but not the toolchain to
actually get there.

~~~
azakai
Not sure. The main issues are that

1\. The llvm wasm backend is upstream, which is good.

2\. asm2wasm will likely stay better at compile times, especially for non-
separate compilation (which is important for code size, which matters a lot on
the web).

3\. We don't know which of the two will produce better/smaller code. The wasm
backend isn't ready for a fair comparison yet. And there are reasons to guess
both ways here.

So we might not end up with a single "final" toolchain. Different people in
the toolchain space have different ideas of what will work best, so I guess
we'll just see how things turn out. And it's possible everyone will be right
in the sense that different toolchains will be better at a different use
cases.

------
kLeeIsDead
As someone who has stayed far away from the perils of web development, will
this be the step that finally makes it sane again? I figure the sooner the DOM
+ JavaScript/EMCAScript die the better; and with asm.js and WebGL I thought
that day finally came... but nope. 3 years later we're still scuttling around
bad design decisions of over two decades ago.

~~~
madeofpalk
I find it very strange that you see 'web development' as something that's bad,
and the answer to it is to write C and ship assembly code to clients.

~~~
StavrosK
I find it very strange that you see minified, basically completely unreadable
JS as better than C (straw man, it's actually "any programming language") and
assembly.

If we aren't being disingenuous, it's "any language you want versus JS" and
"minified, obfuscated JS versus assembly".

~~~
geofft
The web has a free software problem (either that, or native code has a free
software anti-problem because distributing portable precompiled code is so
hard), but I find minified JS no more or less acceptable, as a language to
read, than assembly generated from an optimizing compiler.

That said, minified JS on the web runs in a sandbox with a sane security model
(yes, browsers don't implement it 100% right, but at least there's a model
there). Optimized native code without source does whatever it likes to any
file on my single-user machine, and we're expected to be okay with that (cf.
[https://xkcd.com/1200/](https://xkcd.com/1200/)). If I'm asked to choose
between _running_ one of the two, my vote is with the web app, no question.

~~~
dispose13432
The point of WebAssembly is to use the sandbox as a means of shipping compiled
binaries in a secure manner.

~~~
bobajeff
I was under the impression the point of WebAssembly is to do asm.js better.

~~~
madeofpalk
I think these are both, more or less, the same thing. Better asm.js is a
binary.

