Hacker News Reader

Comment by zach43 | Hacker News Reader

I am also very interested in learning more about using WebAssembly as a primary deployment target for desktop applications. Recently when I was working on a cross-platform C++ application using Qt and boost, a major pain point was in understanding the different packaging conventions of the operating systems.

If WebAssembly takes off, and is available on Windows, macOS, and Linux, would it be possible for me to build just a single binary from a C++ compiler which could work natively on all three operating systems? Would the WebAssembly project build the necessary infrastructure (linkers, dynamic loader, etc) for this to work?

View on HN

In theory, yes, but WebAssembly current has put little effort on standardizing packaging and ABIs. That work is in progress here: https://github.com/WebAssembly/tool-conventions but is still very early. You'd then need each of these platform exposing a standard set of imports to WebAssembly binaries because from the compiler's perspective WebAssembly looks like an OS with a virtual ISA, so these embedder imports are kind of like an OS' syscalls. That's a lot of work, isn't very advanced yet, but in theory is all possible and WebAssembly was explicitly designed to make it possible.

I'm actually working on an effort in this space. Specifically we're at the point where it's time to stand up a libc in a non web embedding.

If anyone is interested in the effort they should let me know.

I'd honestly just start with musl libc. The one Emscripten supports mostly just imports the same syscalls as Linux, with some ugliness to be able to do some DCE. If you clean that up your embedder will only need to implement those syscalls.

I am working with musl, however not the one with emscripten. That one is heavily modified farming out significant parts to the javascript runtime. It is a goal to provide a minimal surface area for embeddors and part of that is not requiring a JS runtime.

Please contact me privately. My email is in my profile. Thanks!

WebAssembly itself is just (more or less) an instruction set, not a complete runtime platform. It doesn't define APIs for rendering, audio, input, filesystem access, networking, etc...

Electron provides all that, but at the very high cost of shipping a complete browser runtime with your app.

Yup, we need an stdlib (and not libc)

Oh don't you worry, that will come and we'll be free of that ugly JavaScript thing.

You are lucky, Java 9 was just released.

Now you can ahead-of-time compile any JVM project into a single executable, it will run on all platforms, and it will have nice UI toolkits (JavaFX is quite awesome).

Even better, with Truffle + Graal in Java 10 also native interoperability with basically every other language is coming, so you can basically combine this with every language.

Write once, run everywhere always has various tradeoffs. The closer you get to fundamental differences in operating systems, the more platform-specific code you need.

UI, for example, is hard to make platform independent if your application needs to look and feel native; or needs to plug into platform-specific features.

What would be useful is a way to easily call WebAssembly libraries from native applications. This way common business logic can be written cross-platform; but the parts of an application that need to remain native are left native.

No, because at the least all three have different executable formats (PE, Mach-O and ELF respectively). I suppose it might end up being possible to ship some sort of HTML + WASM bundle that they all know how to interpret if it became common enough.

If you google around, you'll find that POCs exist - qt apps on the browser in canvas tags. Accessibility nightmare but otherwise a dream come true in the so called enterprise. Can't wait for this tech to mature a bit more.

Reply on news.ycombinator.com