[gregsadetsky]

I was just asking about this in a thread about a driver for an old webcam here yesterday! [0]

Absolutely agreed, it really seems like a fascinating possibility.

What’s your take on how WASM drivers (meant to run in a web browser) could integrate at the OS level? For instance, if you wanted all installed desktop softwares to be able to print via the WASM printer driver?

[0] https://news.ycombinator.com/item?id=35745652

[Brian_K_White]

I don't see any reason why wasm can't just become another native format.

wasm spec is fully defined and public, and we even already have source for browsers.

What prevents developing a wrapper or shim that runs any wasm as if it were any other native executable?

You might be legally prevented from redistributing the wasm, so maybe you can't bundle it right into a .deb or.rpm, but it's trivial in that case to just download on the fly if not exist and re-use after that. You may want it to check for updates all the time anyway.

[PaulDavisThe1st]

It's typically called a VM. Go up and read about Java, which was fundamentally premised on precisely the same idea, and then see if you can come with some clear reasons why wasm should/will be more successful.

[Brian_K_White]

I don't think java has much equivalence or bearing here.

[PaulDavisThe1st]

It is a VM like wasm. It runs on every platform. It offers the seduction of "write once, run anywhere" (literally, in the Java marketing, and now increasingly, in discussions about wasm. The more wasm expands its capabilities due to browser extensions the more and more it looks like Java as a platform.

[Brian_K_White]

neither java code nor binaries are very portable, despite the original marketing. wasm is essentially a binary format. You can certainly make a non-portable wasm just the same way you can make a non-portable elf binary. But you don't have to. You can make a wasm that is even more portable than any elf binary since it's independent of any platform. java byte code may have been theoretically able to do the same, but the jvm ended up being too varied and there is no universal jvm environment the way there is a universal wasm environment. Browser extensions don't remove or modify the base, only add.

java isn't relevant, not because it couldn't be in theory, but because in reality, it's just not. Browsers never baked it in, it never became an open standard, etc, it's essentially no better than every other interpreted or compiled language. We could have a universal standard that's essentially bash, but we don't. We have bash, but it will never be a universal format the way wasm already is. Being baked into everyone's browser makes all the difference. When you want to publish a picture, tiff is a very versatile container and is better than most other formats, but the format you will actually use will be png or jpg etc, because even though many tiff viewers are available, they aren't built in to all browsers. It doesn't matter that tiff already existed and could do the same job. java is tiff.

[RReverser]

> What prevents developing a wrapper or shim that runs any wasm as if it were any other native executable?

That definitely exists and is used on server-side - Wasmtime, Wasmer and others.

[jmillikin]

Application software would still go through the OS native printing APIs. Office or Chrome don't directly interact with the vendor's driver.

As for browser API compatibility, I don't see much point to it since they're mostly designed with the assumption of a JS host. Ideally a WASM driver would export low-level functions to translate from (for example) PostScript to USB packets. Then the underlying native driver (Linux kernel module, Windows dll, etc) runs the WASM and handles all the IO, calling exported WASM functions as needed.

[RReverser]

Browser ports can't integrate at OS level, they're intentionally separated today, but given that e.g. Node.js has WebUSB support (https://github.com/node-usb/node-usb), I guess you could make a layer that exposes such Wasm drivers as native to the OS. Could be a fun experiment.