Compile WebAssembly on Linux to native Windows using Wasmer & Zig

[@darkfire2703]

Pretty cool technology and nice video! The size difference between the windows and linux binaries is almost certainly caused by the linux binary not being stripped and containing a bunch of debug symbols. When trying this out myself, I got a ~10MB size reduction on the linux executable after using strip -s on it. That is roughly the difference you have between the windows and linux version in the video.

[@akkesm]

Zig itself is using a wasm binary as part of their self-hosted compiler since version 0.10.0. I absolutely love what Zig is doing.

[@contextfree]

My understanding is that they have their own tailored wasm-to-c translator that works as part of the bootstrap process. And I presume a different (more general purpose) wasm-to-c is part of what wasmer is using for native compilation in my demo above, but I haven't dug into it.

[@Dorumin]

I never thought about wasm being a native platform for running code making cross compilation way easier between OSes. This has always been a pain but this might make it way nicer

[@contextfree]

To the extent a compiler makes self-contained wasm bundles (say in this case that depend only on wasi), yeah, it might be really convenient. And I imagine the binaries can get way smaller than what's in the demo here if they work at it.

[@alexander3293]

windows does some malware scanning on the first run ;^)

[@keyboard_g]

We’ve invented Silverlight.

[@j.trades9691]

More like, we've reinvented the JVM! Not a bad thing, though.

[@master74200]

@@j.trades9691 with the exception that native code compilation can target the JVM (or WASM, as is the case), and vice versa. I'm not certain, but I don't know of any cross native compilation tools for JVM archives, although I'm sure they do exist somewhere.

[@scosminv]

The reason why Flash, Silverlight, JVM (Java Applets) failed was because they were proprietary and reqiured a plug-in installed in the browser. The fact webassembly is an open standard and implemented by all browsers and many runtimes, it's a big difference. Nothing it's reinvented, but it's optimized and re-optimized. After all, you can compile your go / java / c# workloads to target webassembly. (In truth, C# is best positioned from a tooling perspective atm) With the wasm-gc proposal (assuming it will be implemented also for server workloads) , those wasm binaries will get smaller.

[@mgord9518]

This is pretty cool, is there any easy(ish) way to do this with GUI applications? I'd also be interested to see the performance difference between language -> wasm -> native and language -> native for the languages that support native compilation anyway

[@contextfree]

Both are good questions. For GUI, maybe just keeping it Wasm and using Tauri or something is easiest for now. I don't know how hard it is to link in other native libraries with Wasmer or others, but access to WebGPU and such in a lightweight runtime could be fun. I haven't looked up speed metrics. Maybe compiling Zig's bootstrap Wasm through this and then comparing how fast that compiles Zig vs final Zig compiles Zig could be interesting.