ReactPy Turns Python Functions Into React-Style Components

ReactPy Renders Components to HTML Tags, Not JSX

ReactPy builds interfaces out of functions decorated with @component, each returning calls into an html module rather than writing JSX or any markup language of its own. The README's own Hello World application shows the shape directly: a function named hello_world, wrapped in @component, returns html.h1("Hello, World!"), and a call to run(hello_world) starts the application. There is no separate template file and no compiled JSX step between the Python function and the tag it returns.

That design is where the README's description, a library for building user interfaces in Python without JavaScript, reads as literal rather than as marketing language. The component function is Python, the tag it returns is Python (html.h1 is a function call, not a string of markup), and the only thing resembling ReactJS is the shape of a function component returning a tree of elements. Someone used to ReactJS's function components will recognize the pattern immediately; someone who has never touched ReactJS only needs to know Python functions and the html module's tag names.

A Separate @reactpy/client Package, Versioned on Its Own

ReactPy's own release history shows two version tracks moving inside one repository. The Python package sits at reactpy-v2.0.0b13, still a beta tag, while a separate package, @reactpy/client, has already reached v1.3.0 and v1.2.0, released a week apart. That name, an npm-style scoped package, points to a JavaScript client library shipped alongside the Python package rather than bundled invisibly inside it.

Splitting the two tracks fits what each side has to do. The Python package defines components and runs the server-side logic; something has to turn whatever that logic produces into actual DOM updates inside a browser, and that is the client package's job, versioned and released on its own so a client-side fix does not force a new Python release and vice versa. The README does not describe the protocol between them.

Installing ReactPy: a Package the README Never Shows You pip Installing

The README never gives a pip install command. Its PyPI badge links to https://pypi.org/project/reactpy/, and pyproject.toml's [project] table names the package reactpy directly, the name PyPI lists it under, but the install instructions themselves live behind the Documentation link rather than in the README. What the README does give in full is the first program to run once the package is installed.

from reactpy import component, html, run

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

run(hello_world)

run(hello_world) is the entire startup step shown here: no separate server process to configure by hand for this minimal example, though the Supported Backends table in the README lists Flask, FastAPI, Sanic, and Tornado as the servers ReactPy integrates with directly.

Built-In Servers Versus Community Packages: Flask and Tornado Inside, Django and Jupyter Outside

The README splits backend support into two columns, Built-in and External, and the difference is where the code lives, not what it can do. Flask, FastAPI, Sanic, and Tornado sit under Built-in, meaning ReactPy's own repository ships the integration code for them directly. Django, Jupyter, and Plotly-Dash sit under External, each linked to a separate repository: reactive-python/reactpy-django, reactive-python/reactpy-jupyter, and idom-team/idom-dash.

The Dash integration lives under a different organization, idom-team, rather than reactive-python. A Django project adding ReactPy pulls in a package maintained in a different repository, on its own release schedule, not the one tracked in reactive-python/reactpy's own CHANGELOG.md.

Python 3.11 Is the Floor, and a Beta Tag Sits Behind a Production/Stable Classifier

pyproject.toml sets requires-python at >=3.11, a floor that excludes Python 3.9 and 3.10 outright, both still in use on plenty of existing projects. The same file lists a classifier, Development Status :: 5 - Production/Stable, next to a release history where the current Python package tag is reactpy-v2.0.0b13, a beta version by its own naming.

The two signals point in different directions: the classifier claims production stability while the version number itself still carries a beta suffix. Neither pyproject.toml nor the README explains which one should be trusted over the other, so anyone pinning a version in a production dependency file should read the beta tag as the more specific signal and test accordingly before relying on the classifier's label alone.

ReactPy Against ReactJS: Same Component Model, No JavaScript Toolchain

ReactPy names its own point of comparison directly: its interfaces are made from components that look and behave similar to those found in ReactJS. ReactJS runs in the browser, written in JavaScript or JSX, and most ReactJS projects depend on a Node-based build toolchain, bundlers and transpilers, a package.json with its own dependency tree, to turn that JSX into code a browser can run.

ReactPy keeps the same function-component shape but removes that toolchain from the Python side entirely: a component is a decorated Python function, run through Python's own interpreter, with no separate JavaScript build step for the backend logic. The tradeoff is not fewer concepts, props and a render tree still exist under different names, but fewer languages and build tools a Python-only team has to maintain, at the cost of needing the reactpy-django, reactpy-jupyter, or similar package once the project needs to live inside a framework ReactPy does not support directly.

MIT License, Discord Support, and Two Packages Releasing Together

ReactPy is released under the MIT license, credited in pyproject.toml to two named authors, Mark Bakhit and Ryan Morshead, placing almost no restriction on reuse beyond keeping the license notice intact. The project's own support channels are a Discord server and GitHub Discussions, linked directly from the README, rather than a single maintained FAQ document.

The latest releases, reactpy-v2.0.0b13 and @reactpy/client v1.3.0, were both tagged on 2026-07-14, so the Python and client releases shipped together for that cycle; the last push to the repository was on 2026-10-20. Anyone adopting ReactPy for a new project should read CHANGELOG.md directly for what changed since reactpy-v2.0.0b13, since a beta-tagged release is the kind of version number that invites checking release notes before upgrading, not after.

Editorial conclusion

A Python team that wants ReactJS's function-component shape without a Node build toolchain gets that directly from ReactPy's @component decorator and its built-in Flask, FastAPI, Sanic, and Tornado integrations. A team that needs Django, Jupyter, or Plotly-Dash support is pulling in a separately maintained package on its own schedule, and anyone pinning a version for production should read reactpy-v2.0.0b13's beta tag as the more specific signal than the pyproject.toml classifier claiming Production/Stable, and check CHANGELOG.md before upgrading.

Frequently asked questions

Official sources

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