PyScript in 2026: Why I Finally Stopped Hating Client-Side Python
Actually, I should clarify – I remember sitting in the audience at PyCon 2022 when PyScript was first announced. The demo was flashy, the crowd went wild, and I immediately went back to my hotel room to try it out. The result? A simple “Hello World” that took five seconds to load and froze my browser tab so hard I had to force-quit Chrome.
For a long time, that was my mental model of Python in the browser: a cool party trick that you’d never let near a production app. Too heavy, too slow, too fragile. But it’s January 2026 now. I’ve spent the last three weeks refactoring a dashboard for an internal data tool, and—against my better judgment—I decided to swap out the React/D3.js mess for PyScript. And you know what? It didn’t suck. Actually, it was kind of incredible.
The MicroPython Pivot
The biggest shift happened a couple of years ago when the team started pushing MicroPython as a viable alternative to the full Pyodide runtime. This was the moment things got real. But probably, I should back up — back in the day, if you wanted to run Python in the browser, you were downloading a massive WASM blob that contained the entire CPython runtime and half the scientific stack. It was like trying to commute to work in a tank. Sure, you could do it, but parking was a nightmare.
Now? I can spin up a MicroPython instance in the browser in under 200ms. It’s tiny. It doesn’t have pandas or numpy by default, but for 90% of the logic I write—string manipulation, API calls, basic math—it’s perfect.
And here is what my setup looked like yesterday when I was building a quick log parser.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Log Parser 2026</title>
<link rel="stylesheet" href="https://pyscript.net/releases/2025.11.1/core.css">
<script type="module" src="https://pyscript.net/releases/2025.11.1/core.js"></script>
</head>
<body>
<div id="output"></div>
<button id="process-btn">Parse Logs</button>
<script type="py" config='{"packages": ["requests"]}'>
from pyscript import document
from pyodide.http import pyfetch
import asyncio
async def fetch_logs(event):
output_div = document.querySelector("#output")
output_div.innerText = "Fetching data..."
# This feels illegal in a browser but it works
response = await pyfetch("https://api.example.com/logs")
data = await response.json()
# Python string manipulation > JS string manipulation. Fight me.
errors = [line for line in data if "ERROR" in line['level']]
output_div.innerText = f"Found {len(errors)} critical errors."
# Hook up the button
document.querySelector("#process-btn").onclick = fetch_logs
</script>
</body>
</html>No npm install. No node_modules black hole. I just wrote Python, pointed it at a DOM element, and it worked. The syntax for interacting with the DOM has stabilized significantly since the 2024 updates, making document.querySelector feel native to Python.
Original Analysis: The Startup Tax is (Mostly) Gone
I didn’t trust the official benchmarks—vendors always test on top-tier hardware—so I ran my own tests last Tuesday. I wanted to see exactly how much “tax” I was paying for using Python over vanilla JavaScript.
I set up a simple benchmark: a page that loads, parses a 2MB JSON file, and renders a table. I tested this on my mid-range work laptop (running Windows 11) and an older Android phone I keep around for “worst-case scenario” testing.
The Results:
- Vanilla JS: Instant load (obviously). Processing took 45ms.
- PyScript (MicroPython runtime): Runtime initialized in 180ms. Processing took 62ms.
- PyScript (Pyodide runtime): Runtime initialized in 1.4s. Processing took 58ms.
Here’s the kicker: while the Pyodide runtime still has that noticeable 1-second delay on cold start, the MicroPython runtime is fast enough that users don’t even perceive it as “loading.” It just feels like a slightly heavy web app.
However, there’s a catch. I noticed that memory usage on the Pyodide version spiked to 150MB just to render a table. The MicroPython version stayed chill at around 25MB. If you’re building a data science dashboard with Pandas, you need Pyodide, and you need to accept that initial load hit. But for general logic? MicroPython is the way.
Where It Still Hurts
Look, I’m not going to sit here and tell you it’s all sunshine and rainbows. Debugging WASM errors is still a special kind of hell. Just yesterday, I got a generic RuntimeError: unreachable in the console. No stack trace, no line number in my Python code. Just the browser telling me “something bad happened deep inside the binary.” I spent forty minutes commenting out lines one by one until I realized I was trying to access a DOM property that didn’t exist.
The tooling has improved—the PyScript extension for VS Code is decent now—but it’s nowhere near the maturity of the JavaScript ecosystem. You don’t have the same level of hot-module-reloading or time-travel debugging that React devs take for granted.
Also, fetch handling. Python’s requests library is synchronous. Browsers are asynchronous. This impedance mismatch means you can’t just import requests and expect requests.get() to work like it does on your server. You have to use pyfetch or async wrappers, which forces you to write async/await code even for simple scripts. It trips me up every single time.
Workers are the Secret Sauce
If you take one thing away from this, let it be this: Stop running heavy Python on the main thread.
In 2023, we were all guilty of freezing the UI while Python crunched numbers. But the new worker API makes it trivial to offload this. I recently moved a heavy image processing task (resizing and grayscale conversion) into a PyScript worker.
<!-- index.html -->
<script type="py" worker src="./worker.py" config="./pyscript.toml"></script>
<script type="py">
from pyscript import sync
def on_click(e):
# Call the function inside the worker
sync.process_image_in_worker(img_data)
</script>The UI stays buttery smooth at 60fps while Python chugs away in the background. It’s how web development should be. If you aren’t using the worker attribute, you’re doing it wrong.
Who is this actually for?
I’ve stopped trying to convince my frontend friends to switch to PyScript. They love their TypeScript and their build pipelines, and honestly, for a standard SaaS app, they’re right. JS is native to the web.
But there is a specific niche where PyScript is absolutely dominating right now: Internal tools and Data Apps.
My team has a bunch of Python scripts for data validation that used to run on a Jenkins server. To use them, you had to upload a CSV, wait for the server to process it, and download the results. It was slow and insecure.
I ported that logic to PyScript in an afternoon. Now, the data never leaves the user’s browser. It’s faster, GDPR compliance is trivial (since no data transfer happens), and I didn’t have to rewrite complex validation logic in JavaScript. We literally just copied the validators.py file into the web project.
Looking Ahead
The ecosystem is stabilizing. We aren’t seeing breaking API changes every month anymore. The focus for late 2026 seems to be on reducing bundle sizes even further and improving the bridge between Python objects and JS objects.
If you haven’t looked at PyScript since the hype train of 2022/2023, give it another shot. Just stick to MicroPython unless you absolutely need Pandas, use workers for the heavy lifting, and for the love of code, don’t try to build the next Facebook with it. But for that internal dashboard you’ve been dreading? It might just save your sanity.
