ReactPy: React-style components in Python, wired to Flask, FastAPI, Sanic or Tornado

What ReactPy solves, and who it is actually for

The problem is the split between a Python backend and a JavaScript frontend. A small internal tool, a dashboard bolted onto an existing Flask or FastAPI service, or a data app in a notebook usually does not need a separate frontend build chain, a Node toolchain and a second language for the team maintaining it. ReactPy's answer is to keep the component model but write the components in Python. The README describes the library as one for "building user interfaces in Python without Javascript", and says the interfaces "are made from components that look and behave similar to those found in ReactJS".

The audience follows from that. The README states it is designed for people without web development experience, and adds that it should be powerful enough to grow. In practice the second half is the more interesting claim: this is a tool for people who already know Python and want reactivity without learning a second ecosystem. It is not a way to write a public-facing marketing site, and nothing in the repository suggests it is aimed at that.

How the component model and the backends fit together

A ReactPy application is a tree of functions decorated with @component. Each returns a structure built from the html namespace, and the top-level function is handed to run(). The README's Hello World is the whole shape of it: a decorated function returning html.h1("Hello, World!"), then a run call. That is the same mental model as a functional React component, minus JSX.

The backend story is where ReactPy differs from a JavaScript framework. The README lists Flask, FastAPI, Sanic and Tornado as built-in supported backends, and Django, Jupyter and Plotly-Dash as external ones maintained in separate repositories. That split matters: the built-in servers ship with the library, while the external integrations are separate projects you install and track on your own. The pyproject.toml also exposes optional dependency groups named asgi, jinja and testing, with an all group that pulls in asgi, jinja and testing together. The asgi group is where asgiref, asgi-tools, servestatic and orjson live, which tells you the server-side path is ASGI-shaped for the frameworks that support it.

What is not visible in the README is how much state management ReactPy offers beyond the component model. Hooks are not mentioned there, and the pyproject.toml does not hint at them. If your UI needs shared client state, check the documentation before committing, because the README alone will not tell you.

Installing ReactPy and running a first app

ReactPy is published on PyPI under the name reactpy, and the pyproject.toml requires Python 3.11 or newer with classifiers up to 3.14, including PyPy. The installation page on reactpy.dev is where the project documents the install command for your environment, and the README links to it from the supported backends table. The package name on PyPI is reactpy.

That gives you the core library and its runtime dependencies: fastjsonschema, requests, lxml and anyio. If you want the ASGI extras, the Jinja integration and the testing tools in one step, the pyproject.toml defines an optional dependency group named all, which is composed of the asgi, jinja and testing groups. The testing group pulls in playwright and uvicorn[standard], which is a hint that the project expects browser-level tests rather than pure unit tests for interactive components.

A minimal app is short enough to type from memory. The README gives this exact example:

from reactpy import component, html, run

@component
def hello_world():
    return html.h1("Hello, World!")

run(hello_world)

Running that file starts the built-in server and serves the page. For a FastAPI deployment you mount ReactPy as an ASGI application rather than calling run(), and the documentation's installation page is the place to get the exact mounting call for your framework, since the README does not show it. The reactpy.dev docs also link a Jupyter notebook on Binder if you want to try components before installing anything locally.

The beta line is the main reason to wait

The most recent release in the repository's release list is reactpy v2.0.0b13, published on 2026-07-14, alongside @reactpy/client v1.3.0 on the same day. That is a beta, and the version number says so. The pyproject.toml still carries the classifier "Development Status :: 5 - Production/Stable", which is a mismatch worth noticing: the packaging metadata claims stability while the newest published version is a beta of a major bump. Anyone pinning reactpy in a requirements file should decide which of those two signals to trust.

A second constraint is the Python floor. requires-python is ">=3.11". If your deployment target is Python 3.10 or older, ReactPy is simply not installable, and no amount of configuration changes that. The classifiers list 3.11 through 3.14, so the supported range is explicit.

A third is where the project is silent. The README does not document rollback, does not describe a migration path from 1.x to 2.x, and does not discuss breaking changes between the two lines. The CHANGELOG.md file exists at the repository root and the project URLs point to a changelog page, so the information presumably lives there, but it is not in the README. Treat that as a research task, not a footnote.

ReactPy against Streamlit, Dash and plain React

The closest comparison in the README is Plotly-Dash, which ReactPy lists as an external backend integration maintained at idom-team/idom-dash. That is an unusual relationship: ReactPy can render into Dash rather than compete with it. The difference in approach is that Dash gives you a fixed set of widgets and callbacks, while ReactPy gives you a component function that returns markup you compose yourself. If your app is a chart with a dropdown, Dash is less machinery. If your app is a custom interface with nested interactive pieces, the component model is the point.

Against React itself, the README's own framing is the useful one: ReactPy components "look and behave similar to those found in ReactJS". The difference is not the programming model, it is the execution model. You are running Python on a server, not JavaScript in a browser, and you are not shipping a bundled frontend. That removes a build step and a language, and it also means the browser is not doing the rendering work. The related searches people use, reactpy vs react and reactpy vs react js, are asking exactly this question, and the honest answer from the README is that ReactPy borrows the shape of React while replacing the runtime.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-07-14, the same day as the reactpy-v2.0.0b13 and @reactpy/client-v1.3.0 releases. That is a maintained project by the only measure available here, though the beta version number means the 2.0 line is still settling. The @reactpy/client package is versioned separately from the Python package, so a client bump and a server bump are two different decisions.

ReactPy is MIT licensed, and the pyproject.toml declares license = "MIT" with a LICENSE file at the repository root. MIT is permissive: you can use it in closed-source products. That is a statement about the licence text, not legal advice, and if your organisation has specific obligations around attribution or dependency review, run it past whoever handles that.

Upgrade cost is the open question. The release list shows a 1.3.0 client and a 2.0.0b13 server, which implies a major version boundary somewhere, and the README does not describe what crosses it. The realistic cost of adopting ReactPy today is reading the CHANGELOG before every bump rather than pinning and forgetting. The dependency list is small (four runtime packages), which keeps the transitive surface narrow, and that is the strongest argument for the upgrade story that the repository supports.

Editorial conclusion

ReactPy fits Python teams that already run Flask, FastAPI, Sanic or Tornado and want interactive UI written in one language, and it fits Jupyter users through the separate reactpy-jupyter package. It does not fit projects that need a stable 2.0 API today, since the current line is reactpy v2.0.0b13, or teams that need a documented state-management story. Before adopting, check the CHANGELOG for the 1.x to 2.x migration notes, confirm the Python version you run is 3.11 or newer, and read the installation page for the backend you actually use.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. reactive-python/reactpy on GitHub
4. README
5. Releases