Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly initial steps tutorial

tutorials.technology

Post reply on HN
Print view View original

21–29 of 29 posts

Re: WebAssembly initial steps tutorial

#21

Post by kLeeIsDead »

unimpressive wrote: post #3
kLeeIsDead wrote: post #2

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…

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.

Re: WebAssembly initial steps tutorial

#22

Post by callahad »

azakai wrote: post #7

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.

Re: WebAssembly initial steps tutorial

#23

Post by azakai »

callahad wrote: post #22
azakai wrote: post #7

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…

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.

Re: WebAssembly initial steps tutorial

#24

Post by kLeeIsDead »

madeofpalk wrote: post #4
kLeeIsDead wrote: post #2

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.

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.

This is a very misinformed opinion.

Re: WebAssembly initial steps tutorial

#25

Post by amelius »

unimpressive wrote: post #3
kLeeIsDead wrote: post #2

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…

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.

Re: WebAssembly initial steps tutorial

#26

Post by flohofwoe »

kLeeIsDead wrote: post #2

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.

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.

Re: WebAssembly initial steps tutorial

#27

Post by andybak »

kLeeIsDead wrote: post #21
unimpressive wrote: post #3

Earlier quoted context omitted.

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…

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?

Re: WebAssembly initial steps tutorial

#29

Post by madeofpalk »

bobajeff wrote: post #16
dispose13432 wrote: post #11

Earlier quoted context omitted.

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

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

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