PyScript: An open source platform for Python in the browser
What PyScript Is
- Runs Python in the browser via WebAssembly, using either CPython (through Pyodide) or MicroPython, not a Python→JS transpiler.
- Core usage: include a JS module and write
<script type="py">blocks that can access the DOM via thejsbridge from Pyodide. - Positioned as a “platform” / framework for building browser apps with Python, with terminals, UI helpers, and integration layers.
Relation to Pyodide, MicroPython, Brython, JupyterLite
- Pyodide is the CPython-to-WASM runtime; PyScript is a wrapper/framework around it, adding browser APIs and QoL features.
- PyScript can also run on MicroPython, which is much smaller and now powers the main site.
- Brython is described as a Python→JS translator with limited library support; PyScript/Pyodide can use many native Python packages.
- JupyterLite is highlighted as an alternative for notebook-style, in-browser Python with precomputed outputs.
Examples and Use Cases
- Simple DOM tweaks (“Hello World” via Python) show how Python can directly manipulate the page.
- Real examples include a Markdown previewer, crime-statistics dashboards, CLI tools in the browser, spreadsheets (PySheets), and an Excel add-in (Anaconda Code).
- Some experiment with Firefox extensions and reactive front-end frameworks built on PyScript.
Performance, Footprint, and UX
- Many note heavy startup costs: multi‑second to ~minute load times, large downloads (Pyodide ~10MB), and high memory usage (hundreds of MB in one dashboard).
- Debate over whether this is acceptable: fine for data-heavy dashboards and offline-style apps, but not for everyday content sites.
- Suggestions include snapshotting initialized runtimes; no clear built‑in solution mentioned.
- Execution speed is expected to be slower than JIT-compiled JS; MicroPython may help size, not speed.
Ecosystem, Alternatives, and Skepticism
- Some see PyScript as a way to avoid JS/TS and reuse Python + PyData stack in the browser.
- Others argue TS/React ecosystems, build steps, and compile-time types remain superior for mainstream front-end work.
- Concerns include unclear documentation/marketing (“platform”), required sign-in for hosted examples, CORS/network limits in WASM, and fears of hard‑to‑maintain DS-written frontends.
- Overall tone: intrigued by the possibilities and demos, but divided on practicality, performance, and long‑term fit.