Miguel de Icaza Talks Up WebAssembly Greatness

[uid313]

The problem is these languages need a runtime and that will make your WASM code quite big (e.g. ~5MB for a simple "hello world" written in Go). That'll wreak havoc with download speeds and data caps. The only language I know of that is up to the task is Rust. And I'm assuming C/C++, but I haven't checked.
But the spec and tooling are coming along nicely, it's no longer super-tedious to pass around things more complex than an int, we got support for multi-threading...

Maybe web browsers could implement a shared cache for runtimes.

[c117152]

WASM is no worse. It can be decompiled and read about the same as obfuscated Javascript. At least it can't do x86 assembly tricks like computing a jump into unaligned code at a +1 byte offset or using Windows SEH to execute the real code during division by zero.

wasm-decompile produces fairly readable code compared to obfuscated javascript.

[kpedersen]

wasm-decompile produces fairly readable code compared to obfuscated javascript.

wasm-decompile probably produces a more readable output than plain Javascript

Maybe web browsers could implement a shared cache for runtimes.

Yes, or at the very least we can try to agree on versions so that parts of the runtime can be friendly to caching proxies.

At the moment in Emscripten it gets bundled into a single .wasm or .js file by default but there is no reason why it cannot be separated.

[bug77]

Maybe web browsers could implement a shared cache for runtimes.

This adds complications of its own. You no longer have a single WASM file, you now have to manage the runtime and your code separately. And then what do you do if the compiler smartens up and doesn't include the whole runtime, but just the parts you actually use? How many runtimes do you keep around (I'm looking at you, Windows with a bazillion MSVC runtimes that no one dares touch).

[pabloski]

This adds complications of its own. You no longer have a single WASM file, you now have to manage the runtime and your code separately. And then what do you do if the compiler smartens up and doesn't include the whole runtime, but just the parts you actually use? How many runtimes do you keep around (I'm looking at you, Windows with a bazillion MSVC runtimes that no one dares touch).

Yes and no. What they are trying to do, is to make wasm a sort of default cross-platform bytecode, available everywhere. This means that we will see operating systems shipping with integrated wasm virtual machines. Wasm VMs will be updated by the OS vendor and, I suppose, will be strictly retrocompatible. This way it is simple to remove the dll hell and the infamous winsxs directory.

It would be a stupid thing to charge browsers for handling the Wasm VM. It is better to let the OS do it.

[cjcox]

As a FOSS developer, I guess I'm ok with WebAssembly if and only if the source code is provided so we aren't just randomly downloading and executing binary blobs from the Internet (which we all know is an incredibly safe place of noble do gooders).

Edit: Maybe what is needed is a way of downloading the blob and executable with source in a way that they are signed and associated so that in a browser debugger you could trace through the program and know what it's doing, etc...

In short, the obvious goals of WebAssembly seem nefarious. Need a way to fix that.

Edit 2: I'd turn off wasm in your browser. Just saying. And I'd recommend running one of the many Javascript blockers so that you're not just willy nilly running untrusted code on your machine.

[tildearrow]

There is a typo but this time I am not going to say it.
MastaG please find it.

[NotMine999]

The problem is these languages need a runtime and that will make your WASM code quite big (e.g. ~5MB for a simple "hello world" written in Go). That'll wreak havoc with download speeds and data caps. The only language I know of that is up to the task is Rust. And I'm assuming C/C++, but I haven't checked.
But the spec and tooling are coming along nicely, it's no longer super-tedious to pass around things more complex than an int, we got support for multi-threading...

I wonder how large a simple "hello world" might be if it was written in pure x86 assembly language and output to a simple Console window?

Even in the days of "Turbo Basic" and "Turbo C" a simple program like "hello world" attached a standard library that weighed in at 2 to 5KB. Now we have this bloat called WASM.

I once wrote a simple "formfeed" command for DOS in pure x86 assembly language. It compiled to a ".COM" file and required less than 100 BYTES.

Once again, programmers and language developers reprove the old adage, "Programs grow to consume the space available in the system."

[Archprogrammer]

I wonder how large a simple "hello world" might be if it was written in pure x86 assembly language and output to a simple Console window?

Even in the days of "Turbo Basic" and "Turbo C" a simple program like "hello world" attached a standard library that weighed in at 2 to 5KB. Now we have this bloat called WASM.

I once wrote a simple "formfeed" command for DOS in pure x86 assembly language. It compiled to a ".COM" file and required less than 100 BYTES.

Once again, programmers and language developers reprove the old adage, "Programs grow to consume the space available in the system."

Well, since a WASM binary is quite bare, a minimal hello world would consist of :

1) The wasm file with the "Hello World!" string and a function call out to a print function.
2) A print function (e.g. using the console log in the browser)
3) Some setup code.

At a guess from a couple of WASM tests I did, about 250 bytes for the WASM binary and around 1kB for the surrounding webpage and initialization+support code in javascript.

So, no. Web Assembly isn't all that bloated.

[Michael_S]

Once again, programmers and language developers reprove the old adage, "Programs grow to consume the space available in the system."

"Hello World" in Rust WASM is 285 bytes of WASM plus some glue Javascript and a tiny HTML file. Not quite as lightweight as your .COM file from assembly, but not even as big as a compiled Turbo Basic or Turbo C "Hello World".

Granted, a WASM program needs a WebAssembly runtime to actually run. That can be a huge beast like a browser or NodeJS, or the 24MB wasmtime executable, or Wasmer that (as far as I can tell) includes the runtime.

But to be fair, WASM is the closest and most light weight solution so far to the "cross platform assembly code" problem. It's got a performance overhead, but the overhead provides that cross-platform compatibility and also protects against buffer overruns and stack smashing (but not use-after-free and race conditions). It has far less runtime overhead than, say, the JVM.