Simon Willison Uses Claude to Run Python ASGI Apps in the Browser with Service Workers

Datasette Lite has been running Python entirely in the browser for four years thanks to Pyodide on WebAssembly. It worked, but with a known limitation from the start: any `<script>` tags in generated HTML were silenced. This broke Datasette's native features and, crucially, many of its plugins.

On May 30, Simon Willison published on his blog that he had asked Claude Opus 4.8, via Claude Code for web, to investigate how to replace Web Workers with Service Workers to intercept HTTP requests natively. The result, according to him, "appears to work".

The Technical Problem That Was Solved

Datasette Lite's original architecture used Web Workers to execute Python code (via Pyodide) and intercept page navigations, returning generated HTML to the main thread. The drawback is structural: Web Workers have no access to the DOM or the document's execution stack, so scripts embedded in response HTML never executed.

Service Workers work differently: they sit between the browser and the network, intercepting real `fetch` requests and returning legitimate `Response` objects. From the browser's perspective, the response comes from the server, meaning scripts on pages execute normally. It's a subtle distinction in the abstraction model, but with major practical consequences for any complex ASGI application.

How Claude Code Entered the Workflow

What's relevant here isn't just the technical outcome, but the method. Willison didn't write the solution manually; he opened a pull request in his research repository and assigned the task to Claude Opus 4.8 from Claude Code's web interface. The agent explored the problem, proposed the Service Workers architecture, and generated the necessary code.

This kind of usage—delegating an open-ended technical investigation, not a well-defined task—is a use case gaining traction in the developer community working with Claude Code. The difference from a regular chat is that Claude Code can iterate over real files, run code, read errors, and fix issues without the developer manually pasting snippets between windows.

Why This Matters for the Python-in-Browser Ecosystem

Pyodide has matured considerably, but running complete ASGI applications in the browser remains largely uncharted territory. Most projects attempting this assume strict constraints on what the frontend can do. If the Service Worker pattern proves stable, it opens the door to porting Python applications with complex JavaScript—dashboards, plugins, interactive visualizations—without modifying the app code.

Datasette Lite is a representative use case: it's a real tool, used by real people, with plugins that depend on JavaScript. If this fix holds in production, other projects in the Pyodide ecosystem will have a concrete implementation reference.

What Remains to Be Seen

Willison is explicit that this is preliminary research. Service Workers have their own complexities: lifecycle, cache updates, different behavior across browsers and security contexts (HTTPS required outside `localhost`). Integration with Datasette's plugin system will require more thorough testing before reaching Datasette Lite in production.

What is clear is that combining Claude Code with exploratory technical tasks—not just routine code generation—is starting to produce results worth following. Not because AI "solves" the problem alone, but because it reduces the cost of investigating approaches that might otherwise remain stuck in the backlog.

---

Takeaway: It's a small experiment, but the honesty with which Willison documents the process—including that it was Claude who explored the solution—is exactly the kind of transparency that helps calibrate what Claude Code is actually useful for in practice.