Wasmer 0.16 Released For Running WebAssembly Programs Anywhere

[Raka555]

Here we go again ...
Another Virtual machine to abstract the hardware.
Been done several times in the past of which the JVM (and browsers) are the most successful.

[ssokolow]

Here we go again ...
Another Virtual machine to abstract the hardware.
Been done several times in the past of which the JVM is the most successful.

Except that none of those VMs are implementing a standard with the combination of factors WebAssembly has:

• The bytecode is standardized, with multiple implementations of the standard already popping up
• The bytecode is designed from scratch to support ahead-of-time compilation to machine code
• The plan's got buy-in from all major browser vendors as a way to write compiled extensions for browser-side JavaScript applications
• You can compile languages like C and C++ to it
• Emscripten supports it, so you can use an API abstraction to compile existing Linux applications to it. (Same abstraction layer used to produce things like eSpeak.js)
• WebAssembly is designed to be lightweight, flexible, and performant enough that they feel confident marketing it as an avenue for separately sandboxing each package in a tree of dependencies within a native application.

...and, technically, it abstracts the hardware about as much as using GCC or Clang to target Linux, rather than using a compiler without an intermediate representation to target a bare-metal platform. Every language except assembly language is an abstraction, as are compilers that allow you to target multiple CPU architectures. Likewise, an OS is an abstraction. It's necessary to have multiple applications share limited hardware resources. It's just a question of whether you choose your abstractions wisely.

VMs like the JVM and the .NET CLR chose abstraction built around a garbage collector and lending itself best to JIT compilation. WebAssembly chose an abstraction built around the same flat, un-GCed memory model as malloc and free and designed from the start to support the kind of AOT compilation we expect from things like GCC and LLVM... it just defers the arch-specific stuff until after the binary arrives on the destination computer.

[ermo]

ssokolow :

You seem very enthustiastic about this. What's your stake in WASM? =)

[ssokolow]

ssokolow :

You seem very enthustiastic about this. What's your stake in WASM? =)

Aside from wanting to use it as a typesafe way to have loadable plugins in Rust programs once WebAssembly Interface Types is sufficiently far along to replace the use of YAPSY plus Python? I just don't like it when people are wrong on the Internet.

[Jabberwocky]

ssokolow :

You seem very enthustiastic about this. What's your stake in WASM? =)

Regrettably there are some users in this thread does not seem to understand WebAssembly. I don't have time to explain. I share a lot of enthusiasm with ssokolow because I have an understanding of the need for it. ssokolow Thanks for taking the time to explain in a diplomatic manner.

My two cents: Saying WebAssembly won't work because we tried Bytecode is similar to saying Vulkan won't work because we tried OpenGL.

I have not looked at wasmer specifically, on my TODO list.

[Michael_S]

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.

When most people criticize Electron they're speaking of bloat in terms of application size and memory requirements, not poor integration or focus on social networking. Obviously WebAssembly isn't as memory-efficient as (well written) C but it's not far off either, certainly much better than Electron. So I think ssokolow's response to you took the logical angle.

Your point that it won't integrate well to the desktop stands. Good integration is certainly possible, but I don't think anyone is working on it.

In terms of 'addiction to the cloud', wasmtime and Wasmer are built so that you can run WebAssembly applications as native applications, still sandboxed but outside the browser. So this is the way to break cloud addiction - build a WebAssembly application that users on a Windows desktop, Macbook, Chromebook, or Android phone can use from their browser, and then give them an easy way to run it native on Windows/Max/Linux/*BSD. It allows the cloud-to-native transition to be easier.

[ssokolow]

Good integration is certainly possible, but I don't think anyone is working on it.

Depending on how you look at things, either it's got good integration or it's a little early to be working on integration at that level yet. They're still working out the extensions to the initial standard which integrations with desktop-level features would be built on.

On the "got good integration" side, Wasmer's README lists actively-developed support for embedding into Rust, C, C++, Python, Go, PHP, Ruby, Postgres, JavaScript, C#, R, and Elixir which would allow you to use it inside an application which makes use of existing platform toolkits.

On the "a little early" side, it's pretty important to get WebAssembly Interface Types rolled out first. Without them, communication with WebAssembly requires both sides to manually serialize and deserialize to arrays of 16-, 32-, or 64-bit integer or floating-point values (eg. [u8] bytestreams) for exchanging information. Likewise, access to a framebuffer from inside a WASI application is still an experimental feature in Wasmer.)

This post from 2018 is the best explanation I've seen of the "release a Minimum Viable Product quickly, then extend the spec feature-by-feature to broaden the range of use cases" approach they're taking.

[illwieckz]

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.

You do seem to be misinterpreting the name “WebAssembly” (I know, the name is not helpful).

WebAssembly is not trying to develop software primarily as web apps, it's to develop software as machine apps in a more secure way. You may also say: WebAssembly is to develop web apps as machine apps (but not only).

While WebAssembly aims to performs better than Java but let's compare a bit those two technologies that both want/wanted to be cross platform and have usage on the web. You may remember java web applets are long dead and web browsers deleted support for them long time ago while Java is still widely used on billions of machine out of browsers. Wasm is thought to be better than Java, so you may expect Wasm anywhere there is Java and where there is not Java.

WebAssembly has Web in its name because the biggest urge for it is Web, but that's all.

As a real example the Dæemon game engine developed for Unvanquished game is using NaCl. You can see NaCl as a close parent to Wasm: it's another technology to run cross platform binaries in web browsers or outside of browsers, primarily developed for the web market. So the Dæmon engine uses NaCL to run game code, to run mods that can be downloaded by players while joining random servers. Using NaCl has three benefits:

1. it performs like machine code, it's like machine code,
2. it runs in a sandbox so it gives an useful layer of security,
3. anyone can compile a modded game code on its own system and get Linux, Windows and macOS players able to run it with one binary.

At Unvanquished we are looking for a port on Wasm because Wasm killed NaCl by being better.

So the idea is to have the engine being native, and the game code being cross-platform: no one would have to recompile the engine to make a game on it and to ship on every platform the engine is already built for.

I say that again: NaCl is great, performs well, fulfill the security, performance and portability needs, and we are happy with it. But even with that in hand, NaCl lost the war against Wasm by being less good than Wasm.

So, currently Wasm out of Browsers is still wet and this territory is still rough and hostile like an unknown world, but it is meant to be a land of plenty you can't imagine.

We really don't know when Dæmon will support Wasm, but we want it to!

[ssokolow]

You do seem to be misinterpreting the name “WebAssembly” (I know, the name is not helpful).

WebAssembly is not trying to develop software primarily as web apps, it's to develop software as machine apps in a more secure way. You may also say: WebAssembly is to develop web apps as machine apps (but it does not cover all use cases).

I'm assuming they envisioned it as "WebAssembly = Assembly language for the Web era", but that doesn't really make it clear that they envision it eventually becoming suitable for replacing assembly language in all cases where Microsoft Visual C++'s "64-bit code must use compiler intrinsics and inline assembly is forbidden" policy is proving viable.

[Michael_S]

Depending on how you look at things, either it's got good integration or it's a little early to be working on integration at that level yet. They're still working out the extensions to the initial standard which integrations with desktop-level features would be built on.

Thanks for all of that. I knew some of it, but not all.

I was actually thinking in terms of UI theming. Since WebAssembly is sandboxed, as far as I understand it a WebAssembly application has no way to detect that it's running inside Chrome or inside Safari or in wasmtime or Wasmer on Windows, Linux, iOS, or whatever. And within a Linux deployment there's no way to detect if you're running on KDE, Xfce, or similar too. So your graphical interface might look odd compared to the native UI for the host operating system or browser.

If you're building something really fancy in WebAssembly, you could just offer themed versions of the application itself or even one larger version that has theme changes in the preferences system. But I'm guessing that if WebAssembly really takes off in a big way then the WebAssembly System Interface (WASI) could have extensions, maybe optional ones, to facilitate that kind of integration more easily.