Python in the Browser & WebAssembly (Pyodide, PyScript, WASI/CPython)

Parent: Programming Languages · researched 2026-06-01T05:33:13.085Z· 15 sources · 9 concepts · skill python-in-browser-wasm

"Python in the browser" means compiling a Python interpreter to WebAssembly (WASM) so it runs inside the browser's WASM VM (or a server-side WASM runtime) instead of a native OS process. There is no n

Overview

1. The CPython → WASM compile pipeline (shared foundation)

2. Pyodide — the browser CPython distribution

3. The foreign function interface (FFI) and PyProxy/JsProxy

4. PyScript — the framework layer

5. MicroPython vs Pyodide (the size/capability tradeoff)

6. Packaging for WASM Python (PEP 783 / PyEmscripten ABI)

7. The WASI/CPython target (server-side & sandboxed)

Methodology — choosing & wiring an approach

Practical Patterns

Anti-Patterns

References

Children

Frontier under this node: CPython→WASM compile pipeline (wasm32-emscripten tier 3 / wasm32-wasi tier 2, PEP 11 tiers, PEP 776/816, single-threaded WASM model), Cloudflare Python Workers (embedded Pyodide at the edge), JS⟺Python FFI (PyProxy/JsProxy, toJs/to_js, create_proxy, destroy lifetime management, PEP 818 upstreaming), PyScript framework (polyscript core, <script type=py>/<script type=mpy>, py-config/pyscript.toml, PyWorker, py-editor), Pyodide vs MicroPython runtime tradeoff (~11-15 MB CPython+SciPy stack vs ~300 KB <100ms MicroPython), Pyodide — CPython on Emscripten distribution (loadPyodide, runPython/runPythonAsync, loadPackage, micropip), WASI/CPython server-side target (wasmtime, capability-gated FS/net, sandboxed plugins, host functions), WASM constraints & troubleshooting (no threads/multiprocessing, no raw sockets, web-worker offloading, cold-start size, in-memory virtual FS), WASM packaging — PEP 783 pyodide_* wheel tags + PyEmscripten ABI (pyodide build/cibuildwheel, one ABI per Python version)

← the whole tree · 3D view· how to read this page