Hacker News Reader

Comment by iwillsayit | Hacker News Reader

The real value in Wasm is in the Web use case: bring to the most popular platform software that was impossible (or very difficult) to bring before.

Just look at Ruffle (Flash Player reimplementation), V86 (x86 virtual machine), Google Earth, ...

Wasm on the Server is a fad, and sadly it's hijacking resources and design space from the real thing. WASI being a prime example: because of the "Component model", any attempt at tighter integration with the Browser API stopped in the hope for a magical solution to all computing problems.

View on HN

I have high hopes for wasm on the desktop for app plugins. Loading a whole binary DLL/SO is such a risk. VMs like Lua don't give you enough performance. VMs like Python and Java require huge effort to embed.

Once the SIMD stuff is in, it may even have enough performance for music plugins. wasm codecs would be real cool too. Nobody likes having to build and install ffmpeg. `ffmpeg-4.0.wasm`... just imagine.

> VMs like Python and Java require huge effort to embed.

As a (backend) Java dev, I couldn't let that stand. And indeed I found out java now offers a tool called jlink with first class support, that will create a system native (e.g. .dmg on my macbook) executable with the JRE embedded. The javafx example project* I found could be downloaded, built and run from its native release all within less than 5 minutes.

Mind you the Hello World example executable is 80mb and takes 6 seconds to start, but I feel like with the garbage we are used to in regards to desktop applications, this totally holds up -doesn't everything else usually bundle all of chrome? I have also read there are simple command line options to reduce the size to about 50mb.

* https://github.com/mjparme/javafx-template

Let's please not justify bad/bloaty plugin/extension runtimes with "at least it's not as bad as Electron".

A framework producing a Hello World application, even if it has a GUI, with a double- or triple-digit size in MB and memory consumption on the same order, is doing something very wrong.

With all due respect, that’s just a dumb conclusion. Optimizing for hello world is dumb - if the primary use case of a given framework is larger scale, than it is more than right with such a size.

Well, you are partially correct that the tool in question is optimized for larger projects. But the fact that there isn't an option (in the standard lib) for smaller projects is absolutely a problem. I think that is their point.

The example in question is very much a "include-more-than-you-need-by-default" problem. So, bloat.

Java lets you include only the parts of the JDK that you need for your app. These parts are called modules.

Unfortunately, all modules MUST include the base module (java.base), which is ~22MB. And if you add a GUI (java.desktop), that's another ~13MB. And since the linked example uses Java FX, there is yet another layer on top of that.

Java is doing a lot of work to bring that number down by a lot. More to come.

May I ask how do you solve the problem that almost none of the 3rd party libraries in Java ecosystem use modules?

Last time I checked, jlink tool refused to make use of those "automatic module" dependencies when creating an image.

That information is several years out of date. At best, the build tools in the ecosystem don't do a great job of supporting modules, but that's about it.

And your comment about `jlink` MIGHT be true if your application is nor modular/ does not use modules with a well-formed `module-info.java`. I haven't tried an automatic module in a long time. If your application is modular, everything happens as expected. I do this for all the builds for all of my projects. Last build from last night confirms that it still works, and works well.

But all of Chrome doesn't take 6 seconds to start

jlink is very much out of date. jpackage is the new way to do it. I use jpackage for all of my builds.

Pointing to the 2 most recent projects I have, my Microsoft Paint clone starts up ~0.25 secs, and my Checkers clone is the same.

You're right, embedding a JVM might actually be easy. It's more that I don't target JVMs

very good alternative is wails

6-10mb single binary

use any frontend js tech you want

automatically go functions exposed to the js side so you don't need to think about making endpoints, it makes and uses a websockets between the binary and the ui

uses WebView2 and not chrome

Sounds like Tauri, which is built on Rust instead of Go.

> By using the OS's native web renderer, the size of a Tauri app can be less than 600KB.

Well, it's possible that we can only create a serious application-aware OS security layer by forcing people to write an emulator for some random VM... But I'd expect it to be easier to go and write application-aware security on your OS.

Unfortunately I am having to support like 3 OSes.

4 if you count the Linux kernel of 2020 as distinct from the Linux kernel of 2024.

A userspace, in-process solution is very very appealing until everyone is on Linux of 2024+.

It's loading untrusted python different from loading untrusted dll/so? Unless your use some dedicated sandbox, I think they're equally insecure. I guess a bigger problem with native plugins is that they're not (usually) platform independent.

Running FFMPEG in the browser through WASM is a game changer for me.

But isn't it really slow (like 20x or so) than native FFMPEG?

No, not for me. I'm not transcoding 8k videos with it or anything like that. My use case is extracting thumbnails and video color info, basically transcoding to raw 100px x 100px clips and grabbing color info from that. The user would rather it takes as long as it takes than have to charge them a subscription fee to host the transcoding in the cloud.

Yup. WASM lacks the "domain specific" acceleration available to native code. So you miss out on any hardware codec support. Same is true for openSSL, there is a bunch of encryption acceleration in modern CPUs that WASM can't access at the moment.

I'd be very surprised. I haven't tried ffmpeg in WASM myself, but I do know that for Stockfish, a popular and very CPU-hungry chess engine, the difference is within 20-30% or so vs. an optimized native build.

> Wasm on the Server is a fad

Why? Or rather, what's the alternative?

Regular… servers?

Wasm is currently an alternative nobody asked for.

Seems like you’re jumping from “I didn’t ask for it” to “nobody asked for it”.

What if you want to run your unmodified executable on various architectures?

The JVM kind of does that, but not nearly every language can compile to that as a target, and if you want WASM-like sandboxing you need to deal with security managers, which is no fun at all (and I’ve never seen it done successfully for any non-Java software).

When I’ve tried writing programs targeting wasm (in assemblyscript and rust) and platforms for them to run on, special care had to be taken to treat each language differently (how they encode strings differently for example.)

This means that not only do I need to take special care that my code can compile to wasm, but the platform devs (also me, in this case) needs to take special care to support a variety of different design choices in various wasm toolchains.

I’d rather just use SELinux containers and let the OS handle security.

Maybe Firecracker VMs like AWS lambda does.

That's of course an option if you're fine with your deployables being architecture- and OS-dependent, and very often that's the case.

But for when it's not, I think a platform-independent and language-agnostic bytecode standard is a valuable thing to have.

In the extreme scenario where you want to run arbitrary untrusted code on arbitrary machines, that would be useful, but wasm isn’t a solution for that.

If I need to specifically support how certain languages compile to wasm (meaning I don’t support arbitrary wasm) then what’s the point?

It’s just Java applets again.

Reply on news.ycombinator.com