Using DEBUG compilation slows down the compilation by nearly ~40 times.

Why ?
LLVM represents variable locations through DBG_VALUE records. Heavy function inlining can create hundreds of thousands of these records in a single function.

WebAssembly’s Register Stackify pass moves values from virtual registers onto the operand stack to produce compact, efficient wasm. While moving instructions, it repeatedly scans basic blocks to find and update debug records. Those linear scans are repeated for many definitions, while the pass also leaves invalidated records behind and creates new records for duplicated cheap computations. The result is quadratic work on increasingly large instruction lists.

As example:
Module: repro total codegen
Current Rust: 52.58s
LLM fix:7.12s
Author fix: 1.99s

There are frictions to use it and its usage on the web always rely on Javascript.

TempleOS running in the browser

RustPython is a Python interpreter written in Rust. RustPython can be embedded into Rust programs to use Python as a scripting language for your application, or it can be compiled to WebAssembly in order to run Python in the browser. RustPython is free and open-source under the MIT license.

It would be to go to to use Python in the browser because RustPython can compile in WebAssembly.

The playground: https://rustpython.github.io/demo/

The author uses a service worker in wasm to render HTML. The service worker syncs the data with the server.

Note fetch requests can be intercepted with the ... fetch event in service workers

The service worker used here is written in Go. Note the "localfirst" approach runs only after the service worker is loaded. The initial page is loaded as simple HTML because of SSR. That's the advantage of WASM: the code runs on the client and the server.

(following https://shaarli.lyokolux.space/shaare/CosnyQ)

this is the key idea of Local First HTMX - you don’t have to render the HTML on the backend. You can build a “server” and compile it to WASM and run it in the browser. This would give you all the snappiness of a first class Javascript Local First SPA with none of the JS — well less of the JS.

A toolkit to bootstrap an application

• 64-bit address space (not limited to 4GB anymore)
• multiple memories
• garbage collection
• typed references
• tail calls (optimisation)
• exception handling
• relaxed vector instructions (?)
• deterministic profile (?)
• custom annotation syntax (?)

Scramjet is an experimental interception based web proxy designed to evade internet censorship, bypass arbitrary web browser restrictions and innovate web proxy technologies. This project strives to maintain security, developer friendliness and performance unlike many other web proxies regardless of its open source nature.

It's more than a proxy

Help to build microservices as WASM components in Rust.

It can be used to handle HTTP requests for example.

There is a demonstration: https://www.youtube.com/watch?v=UoRfr3Q2R8A

• 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.