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 the js bridge 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.