wasm-compatibility

Run marimo check with the MW lint rules (marimo check notebook.py --select MW --format json) to catch incompatible imports, unsafe system calls, and packages without WASM wheels. Then manually review PEP 723 metadata, environment variable usage, and concurrency patterns that static linting misses.

Exclude the package with a sys_platform != 'emscripten' marker, enable cache_cells = true, and export with marimo export html-wasm --execute so results are precomputed server-side. For continuous input spaces, use a browser-native layer like moutils.onnx.OnnxRuntime instead.

No, torch, tensorflow, and jax have C++ extensions with no Pyodide builds. You can still use them indirectly by caching execution server-side and exporting with --execute, so the browser only reads cached results.

Lint rules miss runtime-only patterns like os.environ reads, hard-coded absolute paths, and attribute-access imports such as multiprocessing.Lock() after a bare import. Packages excluded by sys_platform markers also skip MW003 checks but still fail at runtime without cached execution.

Process, Queue, Pool, and ProcessPoolExecutor run on cooperative adapters, but there are no OS threads, shared memory, or true parallelism. Code relying on actual concurrent speedup runs correctly but sequentially in the single Pyodide interpreter.

WASM notebooks are capped at 2GB of memory. Large in-memory datasets that exceed this limit will fail in the browser, so reduce dataset size or precompute results server-side before export.