A service worker intercepts HTTP requests and handles them in a Python ASGI app running entirely in the browser

Simon Willison described a research experiment where Python ASGI apps run directly in the browser using Pyodide and a service worker. It builds on his work with Datasette Lite, a version of Datasette running in WebAssembly without a traditional server, but this time he moved from Web Workers to a service worker, which solves an earlier problem: scripts inside script elements were not executed in the Web Worker approach.

A service worker intercepts the request and routes it into a Python ASGI app with no backend

The mechanism is technically clean: the Python runtime runs in the browser through Pyodide, while the service worker intercepts same-origin requests under /app/ and routes them into the ASGI app. The browser becomes a small local environment that can serve HTTP-like traffic without a remote backend.

Willison verified the approach on two concrete cases: a FastAPI demo and the full Datasette 1.0a31. The service worker solves the key problem with the original Web Worker implementation, where scripts inside script elements were not executed, which broke plugins.

For data tools and documentation this is an interesting distribution model

For developer tools, this is an attractive approach. Documentation can include a live app, a demo can run without an account or deploy, training material can work offline and more sensitive data may not need to leave the browser.

The ASGI angle matters because it is a familiar interface in the Python web ecosystem. If this approach stabilizes, experiments do not need to be rewritten in JavaScript just to be shared as web pages. Datasette Lite as a long-running project shows this path is viable, not just a conceptual demo.

The browser has limits that keep this approach from replacing a production backend

The browser has limits around performance, memory, persistence, security and integration. Willison himself notes he is still getting his head around how the service worker behaves in this setup. A service worker also does not turn a local demo into a robust multi-user service.

The main value is distribution: if a small Python app can be shipped as a web page, friction between idea, demo and validation drops sharply.

Tooling and ecosystem will decide whether this stays a research experiment or becomes a pattern

The important questions are caching, package management, download weight and access to local data. Tooling that turns a normal ASGI app into a browser-ready demo without hand-built magic will matter most.

The most promising areas are data tools, documentation and education. That is where local Python in the browser can remove the most operational overhead and reduce dependence on server infrastructure.

Lilith's verdict

This approach does not replace a server. It reduces friction between idea and demo: a Python app as a web page, no deploy, no account, no server infrastructure.