Miguel de Icaza Talks Up WebAssembly Greatness

[awesz]

javascript.options.wasm [B]false[/B]

[Luke_Wolf]

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.

Saying that something has far less runtime overhead than the JVM is like saying in a world of elephants that at least the elephants are much smaller than the one whale on the planet. It's true, but it doesn't give an accurate depiction of the ecosystem. Even .NET which is the JVM's main competitor is an elephant compared to that whale, because Sun Microsystems were dumbasses with the original design. A real world.NET program has about the same memory overhead as a similar real world C++ program. Which mostly boils down to two things. .NET lets you allocate on the stack, and .NET doesn't have an ass backwards generics system that can't handle primitive types and requires heap allocations to work around. I would presume though I haven't taken the time to look, that most other runtimes didn't follow the JVM down it's particular hole of stupid.

[cjcox]

Well then you haven't been paying attention. WASM is something like ASN1 or protobuf. It's a representation of data and functions. It doesn't care if you put data into the format using Rust, Java, Swift or Python, thus it has no business dictating what's supposed to happen to the source code. That's up to the developer.
Though, as pointed above, "decompiled" WASM is rather readable, so auditing the code shouldn't be a problem. It's just that there will be no pop-up with the source asking for your permission to download the code. Never.

It's just so weird how we've gone from "allow everything" to "allow nothing" (user controlled) back to "allow everything" again.

[bug77]

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

Well then you haven't been paying attention. WASM is something like ASN1 or protobuf. It's a representation of data and functions. It doesn't care if you put data into the format using Rust, Java, Swift or Python, thus it has no business dictating what's supposed to happen to the source code. That's up to the developer.
Though, as pointed above, "decompiled" WASM is rather readable, so auditing the code shouldn't be a problem. It's just that there will be no pop-up with the source asking for your permission to download the code. Never.

[duby229]

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.

The goals of webassembly are definitely nefarious for damn sure. Literally the -only- use for it is in malware.... Or at the very minimum it's the only use for it so far, even all these -years- later. Somehow I doubt very much use cases for it will suddenly and magically change...

[duby229]

Another crap like mono from Icaza?

Yup, definitely in the top 3 worst sell outs in OSS history fo sho.... No doubt...

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

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

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

[tildearrow]

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