Wasmer 0.16 Released For Running WebAssembly Programs Anywhere

[phoronix]

Phoronix: Wasmer 0.16 Released For Running WebAssembly Programs Anywhere

Wasmer 0.16 is released as the newest version of this "universal WebAssembly runtime" for running WebAssembly programs on the desktop that could in turn be written in a number of different programming languages...

http://www.phoronix.com/scan.php?page=news_item&px=Wasmer-0.16-Released

[jacob]

Just when I thought we've seen the worst with Electron...

[CommunityMember]

WebAssembly. Write once, run anywhere. "It's like déjà vu all over again."

[jacob]

WebAssembly. Write once, run anywhere. "It's like déjà vu all over again."

Write once, debug everywhere, run (badly) somewhere - but usually not where you expected.

[tildearrow]

Typo:

Wax aims to make it easy to deploiy new WebAssembly tools without the need to install them globally,

[ssokolow]

Just when I thought we've seen the worst with Electron...

You seem to be misinterpreting the name "WebAssembly":

It's not "A faster way to write things for the web". It's "a 21st-century alternative to compiling direct to machine code which allows sandboxing and cross-architecture support suitable for the web era".

The whole idea was that:

1. The developer's compiler does all the optimizations that are CPU-agnostic, then writes WebAssembly bytecode.
2. Like with JavaScript in a browser, the IR and APIs in use "lack the words to describe" accessing resources outside of what the sandbox hands to them, so, if you grant full system access, it's accomplished by having the runtime environment hand in an equivalent to Python's import as part of initialization.
3. The runtime does any CPU-specific optimizations and then compiles the bytecode to machine code and writes it to a cache. (Similar to the ahead-of-time compilation Android does these days, but not tied to a language like Java that needs a heavy runtime and has semantics that make it difficult to optimize things to use the hardware efficiently.)

It's what Sun intended the Java JVM to accomplish, but designed to work with existing languages and perform comparably to ordinary machine code.

As this article explains, one of the intended uses is as a way to do extremely fine-grained sandboxing within existing applications, such that you have each dependency in your address space constrained to a manifest of auditable permissions at compile time. (The example they give is that, with this kind of sandboxing, it wouldn't have been possible to update electron-native-notify to contain a malicious payload which steals passwords because it would be possible to lock individual dependencies down to an auditable, machine-enforced set of permissions and they'd be sandboxed from each other outside of the explicitly created communication channels.)

Electron is heavy and slow because it has a big, heavy runtime and semantics that don't align well with the hardware. WebAssembly is basically just splitting things like GCC or llvm-clang in half and carefully standardizing the language the two halves to speak to each other so you can compile to something that has already done everything not specific to a given CPU arch, then send it off to someone who will finish the process as needed for their specific CPU.

It actually has the potential to be faster than direct-to-machine-code compilation in some cases, since the developer of a traditional direct-to-machine-code binary has to pick a set of optimizations and CPU instructions that'll work on all target processors, while WebAssembly's "compile bytecode to machine code, then cache" step can optimize for your specific CPU.

[jacob]

You seem to be misinterpreting the name "WebAssembly":

[...]

I know what WebAssembly is and of course I'm not against JIT compilation in principle. But I always thought that trying to develop software primarily as web apps that will somehow run on the desktop is a terminally moronic idea. WebAssembly used this way will suffer from all the endemic issues that are typical of Electron apps, including poor or non-existent integration into the desktop, addiction to the cloud, UI design that aims to impress other "cool" kids rather than to be streamlined, usable and efficient and pervasive integration of social media. That's what I mean when I say that WebAssembly is the new Electron, it has nothing to do with how fast it is.

[kpedersen]

I generally like the idea. This has the potential to achieve everything Java could for desktop software but potentially better because C and C++ developers can now join in the bytecode fun.

No reason why games cannot be distributed as wasm binaries *and* x86*. The performance hit is better than not being able to play the game on your platform of choice at all.

That said, I have not looked at the code quality of wasmer itself. It could be unportable junk.

It is run by a company ((C) 2019 Wasmer, Inc.) which in my experience does not help quality software because they always aim to monetize and cut costs.

They also have also included a package manager into their system which also raises some red flags for me. Good quality native desktop software is often more complex than these naive attempts at software management can provide.

[ssokolow]

I know what WebAssembly is and of course I'm not against JIT compilation in principle. But I always thought that trying to develop software primarily as web apps that will somehow run on the desktop is a terminally moronic idea. WebAssembly used this way will suffer from all the endemic issues that are typical of Electron apps, including poor or non-existent integration into the desktop, addiction to the cloud, UI design that aims to impress other "cool" kids rather than to be streamlined, usable and efficient and pervasive integration of social media. That's what I mean when I say that WebAssembly is the new Electron, it has nothing to do with how fast it is.

Except that WebAssembly is no more JIT-compiled than C is. Does having GCC and LLVM use an internal representation before compiling to machine code make C JIT-compiled? Likewise, it's and not in any way tied to developing things as web apps.

Even Wasmer (the implementation that just saw a release) isn't JIT-focused (that's what Wasmtime is for) and is harder to use for Electron-style development than, for example, Rust, because Rust has a more mature story for doing FFI calling between Rust and C or Node.js-API'd JavaScript or whatever other language your Electron runtime accepts plugins written in.

Wasmer implements WASI, which is to WebAssembly as POSIX is to UNIX. Currently, the main thing it's useful for when not embedded in a larger program is writing the kinds of command-line tools you'd get through things like npm install -g svgo or cargo install ripgrep but in a language-agnostic way that supports CPU-agnostic precompiled packages.

[ssokolow]

It is run by a company ((C) 2019 Wasmer, Inc.) which in my experience does not help quality software because they always aim to monetize and cut costs.

True, but so is NPM, and I'd argue that the NPM ecosystem's problems are unrelated to that.

They also have also included a package manager into their system which also raises some red flags for me. Good quality native desktop software is often more complex than these naive attempts at software management can provide.

The package manager is for stuff that's entirely compiled to WASM and built against either the WASI API or an abstraction over it, like the Emscripten libc abstraction, while Wasmer is also designed to be embeddable (eg. so you can build a plugin loader that doesn't dictate a specific language for plugins to be written in.)

It's more like how Rust supports cargo install as an easy way to install developer tools but they specifically don't want it used for everything.

In fact, the manual says "The wapm tool comes bundled with Wasmer: the WebAssembly runtime, but it works great with the other server-side runtimes and the web!"