Here is a feature comparison of a few popular Python frameworks with Websauna.


Websauna does not want to only offer a pile of Python code for the developers to play with - it wants to offer enough tools and an integrated approach to cover the full website lifecycle.

Websauna does things differently as it…

  • wants to provide a functional site out of the box

  • does not make a too tight coupling between the components, like CRUD and models

  • standardizes timed and asynchronous tasks

  • extends the framework to cover basic devops like backups

Modern web development is not simply having a script on the server which sends HTTP responses to HTTP requests. The topic covers tasks like setting up servers, optimizing response times, balancing the load, handling operations securely. Websauna does not force its approaches upon the developer, but want to offer at least one solution, that conforms to the best practices in that field, aiming to a minimum fuzz full website life cycle management.



A working website with sign in and sign up out of the box. Build the first version fast, but make sure the developer is in the driver’s seat for iteratively scale up and replace components and parts of the stack.

Default template engine: Jinja


A small, fast, down-to-earth, open source Python web framework. From developers to developers.

Default template engine: None


Python Web framework that encourages rapid development and clean, pragmatic design.

Default template engine: Django


Flask is a microframework for Python based on Werkzeug, Jinja 2 and good intentions.

Default template engine: Jinja



The following table considers a feature present only if it’s contained in the default project scaffold, core system and tutorials. Many frameworks may have these features as an addon, but require additional integration on the behalf of a developer.

Subsystem Websauna Pyramid Django Flask


Batteries included approach
Free from global variables
Developer controlled entry points
Components and services
Mixin and multi-inheritance heavy 3
Magic filenames and locations
URL dispatch
Type hinting

Configuration and extensibility

Project scaffolding
Linear application initialization 1
Extensible config files 2
Support for configuration secrets
Addon mechanism

HTTP request and response

Application-level middleware ("tweens")
WSGI middleware
Inline URL route declarations


Default site page templates
Default frontend framework
Default 404 and 500
Flash messages

Database and modelling

SQL modelling
Optimistic concurrency control
JSON/JSONB and schemaless data
Transient data and caching

Forms and CRUD

Form schemas
Form autogeneration from models
Themed forms
Widgets for SQL manipulation


Automatically generated admin

Shell and notebook

One click shell 4

Login and sign up

Default login
Default sign up
Federated authentication (Facebook et. al.)


Access control lists and permission hierarchy
Forbid CSRF'ed POST by default
Non-guessable IDs
Race condition mitigation
Secrets and API token management


Delayed tasks
Scheduled tasks


Plain text email
HTML email

Static assets

Addon contributed JS and CSS
Extensible widget CSS and JS inclusion on a page
Cache busting


Deployment model with staging and production
Colored log output

Testing and debugging

Debug toolbar
Unit testing
Functional testing - plain response
Functional testing with JavaScript and CSS

1) Django initialization is driven by framework which reads file. For a developer it's not very transparent and customizable how and in which order things are set up.

2) Django supports including other settings files from, but the mechanism is not standardized.

3) The overusage of mixin and multiple inheritance may often lead to a "mixin hell".

4) Integrated IPython Notebook web shell