Post claims Rust-to-WebAssembly hits 95% of native speed, though basis for the figure is unspecified

In the post's reference architecture, JavaScript writes raw binary buffer data into shared memory and passes a pointer through to the module ^[6]. The 95 percent of native the post cites for Rust compiled to Wasm is execution speed inside that module ^[5]. A job that takes 10 seconds compiled natively takes about 10.5 seconds at that ratio ^[15]. For one video filter over a whole frame buffer, or one inference pass over a tokenized prompt, half a second on ten is not what decides anything. For work that touches the DOM once per unit, the crossing is the cost, and the DOM stays on the JavaScript side of the diagram ^[6].

The three features the post credits to WebAssembly 3.0 serve three different teams ^[2]. WasmGC is garbage collection for managed languages ^[2], and a Rust module does not use it, so the post's Rust performance argument does not rest on it ^[4]. Memory64 matters when your working set does not fit a 32-bit address space ^[2]. Sixteen gigabytes of linear memory is a generous allowance for a tab someone opened by accident.

The post does not report a browser version, a device class, or the workload behind the 95 percent figure ^[14]. For a number like that to transfer to your build, the job has to be compute-bound inside the module, the compiler has to vectorize it the way the post assumes it does ^[4], and the browser your users are running has to enable the features you compiled against.

The jank argument is better engineering than the speed one. The post says a garbage collection sweep can block the main execution thread for tens of milliseconds, and that 60 FPS canvas rendering and 44.1 kHz audio synthesis need predictable, low-latency execution ^[7]. At 60 FPS the frame budget is 16.7 ms ^[16]. A 30 ms pause spans about two frames ^[17]. A workload with comfortable average headroom still drops frames when the collector runs. Deterministic allocation in a linear-memory module removes that failure mode, and WasmGC puts a collector back in the engine for the languages that need one ^[2].

On cost, the post argues that backend processing scales linearly with active user count and bills you for cloud compute and egress, while client-side execution shifts the processing burden to the user's local silicon ^[10][13]. That is a real saving for per-user work such as high-resolution image processing or local model inference ^[10]. It also moves the compute onto hardware you do not own. You cannot profile it in advance, and you cannot upgrade it. The post also argues the privacy direction: keeping medical data, biometric feeds and financial transaction logs off the backend reduces breach surface and data residency complications ^[12].

The spec date tells you the features exist ^[1]. In my view the measurement that settles a client-side build is the job's wall-clock time on the oldest device in your support matrix, on a shipping browser build, with the buffer copy included in the timing.