Show HN: Create Native Desktop Apps from WebAssembly
wasmer.io
wasmer.io
This, however, feels like a newer, inefficient, more limited version of Java JARs or dotnet DLLs. Why not compile into a more optimized bytecode format instead? Pretty sure you can generate a C# binary that compiles into a single platform native executable that includes the framework (and all of your dependencies, I believe?).
Want a cross platform native app that's even faster? Compile for Windows, bundle Wine! Want the limitations of the Javascript framework? Run the Windows executable in a browser through Boxedwine!
There is a lot of value in a wasm target, especially for universal apps. You can use any language desired and end up with a near native binary that can run anywhere, even the browser.
That is powerful, and new.
Couple that with a crossplatform GUI and you have an app that can run anywhere with a single codebase. The same app can be extended with any language and another wasm module.
If done right, this allows for a maintainable, high-perf, low-friction, universal experience. It is a very desirable, low-compromise tradeoff of near native performance without sacrificing mobility or flexibility.
For me personally, using rust targeting wasm is the only way I’m building apps right now. Nothing else comes close and I’ve used almost everything. I’ve waited a long time for this tech stack, and I am very grateful to all the players who made it happen.
WASM runtimes are just the JVM reimagined, but slightly less capable because of WASM compatibility restrictions. Yes, we have tons of compilers that target WASM now, but there's no technical reason why they can't target the JVM or dotnet runtime instead.
GraalVM is proof of this, it has an LLVM runtime that can take LLVM bitcode and run it within the same context as a great many other languages.
WASM may have more existing tooling because of people plumbing it directly into browsers but the "write once, run anywhere" concept has been around for decades now.
I'm curious what tech stack you're using for cross platform applications, because I honestly haven't seen what the big deal about WASM is other than "Javascript but starting to get fast".
See, I can make your statement about anything.
Wasm in browser with proper bindings has access to the entire browser stack. Projects like wasmer give wasm a runtime environment absent a browser with a significant amount of capability that grows every day. All without being locked in to any particular language or ecosystem. This is very very powerful.
With things like WebGPU down the pipe and the prospect of GPU access directly via wasm, a whole new generation of performant & automatically cross-platform apps is nearly here.
I don’t have the resources to maintain countless platform specific codebases. I also cannot afford to have low performance that comes with something like an electron app. But I need the universality of a web app without the lockin to a browser. A wasm target gives me the best of everything.
As an example, I converted a ring signature lib to Typescript / js. Then I made a build of it via C to a wasm target and built typescript bindings. The wasm target was between 10 - 100x more performant for this particular implementation.
The tooling around wasm doesn’t have a vendor or a code lockin. There is a whole lot more there than “fast javascript” so I would really just suggest keeping an open mind and doing more research. If nothing else, it is another valuable tool to have.
At Wasmer we have been working to enable more use cases for the WebAssembly ecosystem. We believe that Wasm can become the lingua franca for software, and we have started to work towards enabling that: starting with standalone native executables generation from Wasm WASI packages.
Looking forward hearing your thoughts!
We had a thing for that a while ago, we called it Java. It had a similarly compelling story.
The gist is, use `wasmer create-exe --target other-target-triple` to cross-compile with zig (if available) to the targets wasmer compiler backends (llvm, cranelift, and our custom "singlepass" backend) support.
Disclaimer: I am the author of those features/git commits.
(Edit: 7 years now apparently, never seen it before...)