Listed in editorial order, grouped by use case. Click a column to re-sort the whole list.
Press / to search. Tap a tag to filter. Click any row for details.
Search and filter
Results
| Row number | Tags | |||||
|---|---|---|---|---|---|---|
Synchronous 5 projects |
||||||
| 1 | flask Synchronous | 138,022,508 | 74,837 | Synchronous Web Frameworks Web Development | → | |
|
A microframework for Python.
|
||||||
| 2 | django Synchronous | 41,636,388 | 91,257 | Synchronous Web Frameworks Web Development | → | |
|
A high-level web framework that encourages rapid development and clean, pragmatic design.
|
||||||
| 3 | bottle Synchronous | 7,064,428 | 8,793 | Synchronous Web Frameworks Web Development | → | |
|
A fast and simple micro-framework distributed as a single file with no dependencies.
|
||||||
| 4 | pyramid Synchronous | 2,021,903 | 4,100 | Synchronous Web Frameworks Web Development | → | |
|
A small, fast, down-to-earth, open source Python web framework.
|
||||||
| 5 | fasthtml Synchronous | 583,499 | 7,049 | Synchronous Web Frameworks Web Development | → | |
|
The fastest way to create an HTML app.
|
||||||
Asynchronous 4 projects |
||||||
| 6 | starlette Asynchronous | 496,876,138 | 12,649 | Asynchronous Web Frameworks Web Development | → | |
|
A lightweight ASGI framework and toolkit for building high-performance async services.
|
||||||
| 7 | tornado Asynchronous | 99,166,902 | 22,170 | Asynchronous Web Frameworks Web Development | → | |
|
A web framework and asynchronous networking library.
|
||||||
| 8 | litestar Asynchronous | 1,722,985 | 8,491 | Asynchronous Web Frameworks Web Development | → | |
|
Production-ready, capable and extensible ASGI Web framework.
|
||||||
| 9 | reflex Asynchronous | 288,446 | 28,938 | Asynchronous Web Frameworks Web Development | → | |
|
A framework for building reactive, full-stack web applications entirely with Python.
|
||||||
No projects match your search or filter.
Try a broader term, or .
Web Frameworks guide
Django comes with a full stack for convenience, and its pieces stay independent where possible. You describe your database layout as models in Python, and Django builds an admin interface from them. User authentication with accounts, groups, and permissions is built in too. A project holds your settings and one or more apps, and an app can move between projects. Before you deploy, run manage.py check --deploy against your production settings. Async views work under WSGI, but for slow streaming and long polling, deploy Django under ASGI.
Flask keeps the core simple but extensible: it doesn't pick your database or form library, and extensions add them. Create the app in an application factory and bind each extension with init_app, so tests can build instances with their own settings. Flask runs each async view on a separate thread, not an event loop, which costs performance compared with ASGI frameworks. For a mainly async codebase, its docs point you to an async-first framework.
Bottle is a single file module with no dependencies outside the standard library. Its FAQ pitches it for prototyping, weekend projects, and small applications, and suggests a full-stack framework like Django when you have tight deadlines. In production, have Gunicorn or another WSGI server load your app instead of calling run().
Pyramid is built so you don't have to rewrite a small app in another framework when it gets too big. Its core maps URLs to code, handles security, and serves static assets, and it makes no assertions about which database or template system you use. Start from its cookiecutter, which asks for your template language, persistence, and URL mapping. Deploy with the production.ini it generates, which turns off the interactive debugger.
FastHTML is designed to create hypermedia applications: it returns HTML from the server, the approach HTMX uses, and you often won't write any JavaScript at all. It's built on Starlette and Uvicorn. Its docs say not to assume other frameworks' best practices apply: let the function name define each route, and use only GET and POST.
Starlette is a lightweight ASGI framework/toolkit: use it as a complete framework, or take any of its components on their own. Install an ASGI server such as Uvicorn next to it, and pick any async database library you like. Keep configuration in environment variables or a .env file that you don't commit.
Tornado isn't based on WSGI and typically runs one thread per process, with its own web framework and HTTP server used together. Its non-blocking I/O makes it a fit for long polling, WebSockets, and other long-lived connections. Hand blocking code to run_in_executor, and run one process per CPU.
Litestar is not a microframework: it comes with ORM integration, client- and server-side sessions, and caching, though it will never have its own ORM. Class-based controllers sit at its core. Set dependencies, guards, and middleware on any layer, from the app down to one handler, and the setting closest to the handler wins.
Reflex builds the frontend, backend, and database in pure Python. It compiles your UI to a React frontend, runs your state handlers on the server, and syncs the two over WebSockets. Change state only through event handlers on your State class. In production, the Reflex team runs Redis as the state manager. Keep auth data and other sensitive state in backend-only vars.
Don't deploy on the development server: Flask and Django both tell you to switch to a production server, and to turn debug mode off.
For a site with forms and logins, turn on CSRF protection. Django's CSRF middleware is on by default. Tornado, Pyramid, and Litestar have it as a setting you turn on. Flask leaves it to a form library, and Starlette to third-party middleware.
Contribute
Know a project that belongs here?
Tell us what it does and why it stands out.