Wren 0.6.20

Wren 0.6.20 runs a page's own WebAssembly: Blazor, Rust and Emscripten applications now start.

This is still a beta, under development, and Windows-only.

The WebAssembly JavaScript API. WebAssembly.compile, instantiate, the streaming forms, Module, Instance, Memory, Table, Global, Tag and Exception, in windows and workers. A .NET 10 Blazor application that said "This browser does not support WebAssembly" now works, first through its server circuit, then with .NET itself in WebAssembly; a Yew (Rust) application and SQLite Fiddle (Emscripten) start too. On web-platform-tests wasm/jsapi, 82 % of the subtests pass.
A large module does not stop the page. WebAssembly.compile works on another thread: for a 34 MB module, the page's timers keep running (worst gap 25 ms) where a synchronous compile blocks for 440 ms.
A page that does not touch WebAssembly pays nothing: its objects are made on first use. The page's Content Security Policy applies ('wasm-unsafe-eval').

A script reading a module's memory element by element is slow (186 ns per read, against 15 ns for an ordinary array): the memory is reached through the browser. The module itself runs at Wasmtime's speed, and bulk operations (set, slice, TextDecoder) are one call.
No shared memory, so no WebAssembly threads. Modules using the old form of exceptions (older Emscripten and .NET builds) do not compile; a Blazor Web App in Auto mode then stays on its server circuit.
javascript.webassembly.enabled turns the API off. Details: docs/js/webassembly-api.md.

#Wren 0.6.20