# Flexx: a pure Python GUI toolkit that compiles to the browser

> Flexx draws every widget with web technology and transpiles Python to JavaScript with PScript. It has been around long enough to accumulate real design wisdom and long enough that its install instructions have started to drift from the repository it lives in.

**flexxui/flexx** — Write desktop and web apps in pure Python

- Repository: https://github.com/flexxui/flexx
- Website: http://flexx.readthedocs.io
- Stars: 3,328 · Forks: 254
- Language: Python
- License: BSD-2-Clause
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/flexxui-flexx

## What Flexx actually is, in one sentence

Flexx is a pure Python toolkit for creating graphical user interfaces that uses web technology for its rendering. Applications are written purely in Python, and the PScript transpiler generates the necessary JavaScript on the fly. There is no build step you write, no JavaScript file you maintain, and no HTML template; the Python you write is both the logic and, after transpilation, the widget tree.

The payoff is that one codebase targets several outputs. Flexx can create cross platform desktop applications, web applications, and export an app to a standalone HTML document. It also works inside a Jupyter notebook, which is a detail that matters more than it sounds: a scientific notebook user who wants an interactive plot control does not have to leave the notebook or embed a separate web framework to get one.

The project describes itself as versatile and points at its own documentation for the ways it can be run, which is an unusual amount of latitude to grant a GUI library. The same flexibility is also its main hazard, and the README is direct about that.

## The warning in the README is the most useful paragraph

There is a section headed a word of caution, and it deserves to be quoted in substance rather than skimmed. Flexx is very versatile and can be used in different ways. It also makes it easy to mix Python that runs on the server and Python that runs in the browser. The project calls this a powerful feature, and then says plainly that it also makes it easy to create code that becomes difficult to maintain, and that the developer must ensure Python and PScript code are clearly separated.

That is the honest engineering summary of a Python-to-JavaScript toolkit. The transpiler removes the language barrier, and in exchange the language barrier was partly what kept server code and client code from quietly growing into each other. Flexx hands you a way to blur that line in one keystroke, which is exactly why the project asks you to hold it yourself.

If you are evaluating Flexx for a team, this is the criterion to use. A single developer writing a plotting tool can ignore the distinction. A team shipping an application with a real backend and a real frontend has to decide up front where the boundary sits, because the framework will not enforce one.

## Four small dependencies carry the whole design

Flexx requires Python 3.5 or newer and also works on pypy. Its dependency list is short and each entry has a clear job. Tornado is called out as pure Python and provides the asynchronous server side. PScript is the transpiler that turns a Python subset into JavaScript. Webruntime is the counterpart on the JavaScript side, carrying the runtime the generated code needs. Dialite completes the set as another pure Python flexxui project.

The concentration of first party dependencies is the notable thing. Three of the four live under the same GitHub organization and are described the same way, which means the pieces that define what Flexx actually is are developed alongside it rather than vendored from elsewhere. For a project whose central claim is that it can stay small and pure Python, that is a coherent arrangement: the transpiler and the runtime have to agree with each other, and they are maintained together.

The rendering target is the browser, and Flexx aims to support all modern browsers including Firefox, Chrome and Edge. Internet Explorer 10 and up should work, though the README warns that some things may be flaky. For running desktop apps you need either Firefox or NW.js installed. That last requirement is the honest cost of the approach: a desktop Flexx app is a browser window with your application inside it, so you are depending on a browser runtime being present on the machine.

## Installing from PyPI, and the stale branch name in the docs

The install section offers the standard PyPI route first and an archive route second.

```bash
# Install latest release
pip install flexx

# Install latest from Github
pip install -U https://github.com/flexxui/flexx/archive/master.zip
```

The bleeding edge option is the same archive without the upgrade flag.

```bash
pip install https://github.com/flexxui/flexx/archive/master.zip
```

That `master.zip` in both archive URLs is where the documentation has aged. The repository's default branch is `main`, not `master`, so those two commands are pointed at a branch name that the project has since renamed. The first command has no such problem and is the one to use.

The Python 3.5 floor tells you the same kind of story. That floor was written when 3.5 was a reasonable baseline, and it is now several major versions behind, which means the declared support range is wider than the range the code is actually exercised against. Nothing here is broken, but it is a fair signal to verify the install on your own interpreter before planning around it. The PyPI badge in the README and the Read the Docs badge are both live, so the built package and the hosted documentation are both reachable and worth checking against the repository if they disagree.

## How the repository is laid out and what it does not tell you

The tree is small and organized around a library, its examples, and its own tooling. `flexx/` is the package itself. `flexxamples/` holds the runnable examples, and the hosted documentation links a demo source file rendered as an interactive example, so that directory is the reference for what working Flexx code looks like. `docs/` holds the documentation sources, `demo/` holds a small demo application including a Dockerfile and a README of its own, and `tasks/` holds the project's own development tasks. Build configuration is old-school and explicit: `setup.py` and `setup.cfg` rather than a modern declarative backend, with `MANIFEST.in` controlling what ships in the source distribution. `CONTRIBUTING.md` and `LICENSE` are present, and a `.github/` directory holds the CI workflow the badge at the top of the README points at.

What the repository does not offer is a release history. No tags or published releases are recorded for the project, and there is no changelog file in the tree. Instead, the README routes change tracking to a single long-lived issue, a NEWS issue at number 477, and asks anyone who wants to stay current to subscribe to it. That is a deliberate choice for a project whose changes are mostly dependency and compatibility updates rather than feature work, but it does mean the only way to answer what changed in a given Flexx version is to read a discussion thread.

So on maintenance evidence the picture is mixed in an honest way. The most recent push is dated 2026-09-28 and there are 3,328 stars with 254 forks, so the code is being touched. But with 96 open issues and no published releases, a reader planning to depend on this should judge it on the issue tracker rather than on a version history, and should treat the hosted documentation at flexx.readthedocs.io as the more current of the two sources.

## Choosing between Flexx and the usual alternatives

The comparison that matters is not feature to feature, because Flexx does not compete on widget count. It competes on output targets. A toolkit like Tkinter or Qt produces a native desktop application and stops there. A browser framework produces a web page and leaves the desktop case to an Electron-like wrapper. Flexx is built so that the same source produces a desktop window, a web application, or a single self-contained HTML document, which is a genuinely different proposition for anyone who has to target more than one of those.

The costs are equally concrete. You are running a browser to display your desktop application, so Firefox or NW.js has to be installed. Your Python is transpiled rather than interpreted, so the subset PScript supports is the subset you have, and the library is explicit that mixing server and browser code is your responsibility to keep clean. And the project is BSD 2-clause licensed, which is about as permissive as software licenses get and a genuine advantage over the copyleft and source-available licenses common in this space.

If you only need a desktop window on one platform and do not care where it runs, this is more machinery than the job requires. If you need the same interface to work offline as a desktop app and as a link you can send someone, Flexx is a smaller and more coherent answer than wiring a web framework and a desktop wrapper together yourself.

## Conclusion

Flexx is a good fit when one interface has to ship as both a desktop window and a web page from the same Python source, and a poor fit if you want a native-looking toolkit or a package with an active release cadence. Start with `pip install flexx`, then read the caution about keeping server-side Python and PScript clearly separated, because that separation is the whole maintenance discipline the project asks of you. Note that the install command still points at `master` while the default branch is `main`, so take the PyPI release rather than the archive URL.

## FAQ

### What is Flexx used for?

Flexx is a pure Python GUI toolkit that renders with browser technology and transpiles Python to JavaScript using PScript. The same source can produce a cross platform desktop app, a web app, or a standalone HTML document, and it also runs in a Jupyter notebook.

### How do I install Flexx?

Use pip install flexx for the latest release from PyPI. Flexx requires Python 3.5 or newer, works on pypy, and depends on Tornado, PScript, Webruntime and Dialite.

### Do I need a browser installed to run a Flexx desktop app?

Yes. For running desktop apps you need Firefox or NW.js installed, because Flexx renders its interface with browser technology. Flexx targets all modern browsers including Firefox, Chrome and Edge.

### Why does the README warn about mixing server and browser Python?

Flexx makes it easy to mix Python that runs on the server with Python that runs in the browser. The project calls that powerful but also easy to abuse, and asks the developer to keep Python and PScript code clearly separated to avoid unmaintainable code.

## Sources

- [flexxui/flexx on GitHub](https://github.com/flexxui/flexx)
- [Issues](https://github.com/flexxui/flexx/issues)
- [License: BSD-2-Clause](https://github.com/flexxui/flexx/blob/main/LICENSE)
- [Project website](http://flexx.readthedocs.io)
- [README](https://github.com/flexxui/flexx/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flexxui-flexx