• the engine of application state (instead of deferring it to the server), when possible
• web apps AND desktop apps: all in one
• a universal binary format
• reuse other tools in the browser such as @ffmpeg/ffmpeg

Tauri reuses the system web view instaed of shipping the entirety of Chromium.

[...] If that scares you, remember that Figma, a ui design tool, took over the market with an app built on web technologies. Same for Visual Studio Code, Slack, Discord, Microsoft Teams, and an increasing number of apps nowadays. Always bet on the web!

This is how they build https://nemastudio.app/

WTF.

An app running in wasm in the browser, which emulates a 32 bits processor, in which runs Linux, on top runs wine in order to get games and windows app running.

(via https://sebsauvage.net/links/?LCE2QQ)

Wikifunctions will use wasm and rust

A incredible performance optimisation for WebAssembly in Firefox!

(via https://korben.info/firefox-accelere-execution-webassembly-75-fois.html)

For example, the compilation time of the WebAssembly module used by Adobe Photoshop online was reduced from 4 minutes to just 14 seconds. Similarly, a test module for the JetStream 2 benchmark saw its compilation time reduced from 2.8 seconds to 0.2 seconds.

With containers, virtualized processes run natively in the host kernel, like any other. Except that their I/Os are carefully kept segregated from others in the host system.

Thought: containers are often too heavy for the job.

The root cause behind the heavy weight of containers is that they have been built for too many usecases.

WASI is a standard API to give WASM code the ability to do system-level I/O.

Solution?

To try to address this, we wanted to move all these heavy dependencies to a common runtime across services. So your tokio, hyper, sqlx and co (in the case of Rust), now all belong to a long-lived containerized process running persistently in the cloud. Whereas all your service logic, database and endpoint code build into lightweight WASM modules that are dynamically loaded in-place by this global persistent process.

I have a different preferred starting point which is less descriptive but more operational: WebAssembly is a new fundamental abstraction boundary.

But WebAssembly is a new point in this space. Unlike the Linux ABI, there is no fixed set of syscalls: WebAssembly imports are named, typed, and without pre-defined meaning, more like the C ABI. Unlike the C ABI, WebAssembly modules have only the shared state that they are given; neither side has a license to access all of the memory in the “process”. And unlike HTTP, WebAssembly modules are “in the room” with their hosts: close enough that hosts can allow themselves the luxury of synchronous function calls, and to allow WebAssembly modules to synchronously call back into their hosts.

Integrate a rust game compiled in wasm into sveltkit

A list of resources on Rust and Wasm :D