WebAssembly initial steps tutorial | Hacker News Reader

WebAssembly initial steps tutorial

tutorials.technology

125 pointsllazzaro25 comments

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/

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).

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.

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.

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.

DOM has some serious advantages, to name a few:

- Machine readability. Graphics scraping is gross, but DOM is by default a machine parseable format.

- For web pages which are actual documents, it makes total sense and is in fact a pretty clean implementation of a document and styling system. Especially in comparison to stuff like Microsoft word's doc format. If you would like to dispute the point, I challenge you to design something better. You don't even need to implement it, just make a compelling design. Or link to somebody else who has.

The second point is the only valid defense of the DOM, in my opinion. It's just a static document formatting language. And it should have stayed that way. Webpages like the one we're on right now should have been the furthest it went.

And we'd then probably be complaining about the other thing that got invented to do the rest of the work that the DOM currently does.

Something would have appeared to handle the interactive aspects of the web. What makes you think it would have turned out better?

The problem with the DOM is that it tries to solve two problems at once: encoding of semantics, and encoding of layout.

I'd say we should forget about the former, because ML techniques can extract semantics to a great extent. IMO, the DOM should be considered purely a layout tool.

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.

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".

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/). If I'm asked to choose between running one of the two, my vote is with the web app, no question.

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

I wonder could all WebAssembly code be shipped in secure containers and make it run similarly to how Google sandboxed the whole Android framework inside of Chrome OS?

Is the security of WebAssembly worse than that currently? Or is it somewhat similar?

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

It is both.

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

Yup. As someone who can't tell an angular from an angle grinder but has read the ABI specs for every platform I use... the web does a lot of things right, and native code and assembly is where we see ourselves tethered to the bad design decisions of over four decades ago.

native code is not the problem... there are many libraries that abstract over platforms just like the web does.... the problem is people who make software that does not abstract away platform specifics

This is a very misinformed opinion.

I don't see the DOM going away under wasm. It's a useful convention, and works just fine for the majority of webpage development.

Canvas is always there if you need it.

I don't like DOM, either. But whenever I see comments like this I want to ask: what do you propose as an alternative? WASM is more of a replacement for JS, DOM still requires a replacement if we hate it so much that we want to ditch it.

A framebuffer?

At that point why build a web app at all? It's just a deployment platform.

We have canvas for like ages. Nobody wants to implement a "better" GUI than the DOM because it's an immensely difficult task with little to no benefit.

WebAssembly will eventually have a DOM API and then JS will not die its growth will just slow down and plateau.

Depends on your definition of 'sane' ;) The web platform now is not much different from normal desktop or mobile operating systems (with one big advantage: hassle-free software distribution, just click on a link).

They all have terrible and outdated APIs, but cannot leave them behind without breaking backward compatibility. And you can either use the OS's standard UI framework (they are also all terrible without exception, just like HTML/CSS), or you can use a 3rd-party-framework like Qt (== JS frameworks), or you can whip up a bare GL window and do all the rendering yourself (== using WebGL). Or you can use a combination of those.

Some HTML5 APIs are pretty bad (everything except WebGL basically), but so are most 'native' operating system APIs.

For asm.js/WebAssembly created from C++ code, you'll have to be very careful and disciplined to create small 'executables' fitting for the web, since avoiding code bloat is not something many C++ programmers care about.

In conclusion, just like every other runtime environment, the web is a terrible platform but you can still do amazing things. The main advantage over all other platforms (IMHO) is extremely simple software distribution both for the developer and user, and it is one of the last truly open platforms (the other one being Linux).

PS: replicating the DOM inside a WebGL context is a dumb idea though (except for research purposes), because this will be a lot of redundant code that needs to be downloaded to the client.

Reply on news.ycombinator.com