PyScript is entering maintenance mode. The announcement came last month from Andrea Giammarchi, one of the project's core maintainers, in a public gist. The API is frozen. Only Pyodide updates will continue, at a slower cadence.
I'm the author of Pytml, one of the tools mentioned below. Full disclosure up front.
If you're not in this corner of the ecosystem, that might not sound like much. But PyScript has been the default answer to "how do I run Python in a browser?" since 2022.
Why it happened
The gist is unusually honest:
"Adoption, OSS contributions, and the kind of promotion that comes from people publishing articles and success stories never really grew the way we hoped."
"The honest picture is that PyScript remained a niche."
"You can still fork both projects and keep them alive. If you do, we would be genuinely happy to see where you take them."
Read the first quote twice. PyScript didn't stall because the tech was bad — it's rock-solid. It stalled because not enough people were writing about it publicly. A strange failure mode: a project dying from a lack of storytelling rather than technical debt.
The state of PyScript today
- It still works. CDN is live, docs are up, code is stable.
- The API is frozen. No new features beyond Pyodide updates.
- The team has stepped back. Andrea said plainly: "I am not dealing with PyScript anymore."
- Forks are encouraged. Apache 2.0, with the maintainers' blessing.
If you already use PyScript, nothing breaks. If you were about to adopt it, the answer has changed.
What people actually wanted
PyScript's pitch was ambitious — Python in the browser, no OS setup, for education, dashboards, and science. What landed for most users was much smaller: write Python in an HTML file, open it, see it run. That case still works. It's just not going to be maintained by the people who built it.
The landscape now
Every option has a trade-off.
PyScript (frozen) — mature, stable, two <script> tags plus a config block. Keep using it if you already do. It won't change.
Pyodide directly — the engine underneath everything. Full control, more setup. You write the glue code.
Brython — near-instant load, no WASM runtime. Great for DOM and education. No NumPy or Pandas.
Skulpt — like Brython, smaller (~200KB), incomplete standard library. Fast, focused on classrooms.
Transcrypt — pre-compiles Python to JavaScript. Fastest execution, requires a build step.
Pytml — mine. ~15KB wrapper around Pyodide. One script tag, <py> tags, print() and input() automatic. Same runtime as PyScript, lazy-loaded. No MicroPython, no filesystem APIs, no plugins — and I don't plan to add them.
None of these replaces PyScript. That's the honest picture.
Where Pytml fits
I built it because I wanted the simple case without the setup. It does one thing: <script> + <py> tags + automatic I/O.
I'm not presenting it as PyScript's successor. It isn't. If you need PyScript's full scope, fork PyScript — the maintainers invited it.
What I am saying: the "one framework to rule them all" era for Python in the browser is over. The next phase is smaller, focused tools that do one thing well.
If you're deciding today
One question: do you need the full PyScript feature set, or just the simple case?
- Full feature set → fork PyScript
- Simple case with NumPy/Pandas → Pyodide directly or Pytml
- Simple case, instant load, no scientific packages → Brython or Skulpt
- Python syntax compiled to JS for production → Transcrypt
No tool is the wrong answer. The wrong answer is adopting something frozen without knowing it.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.