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
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.
|Batteries included approach|
|Free from global variables|
|Developer controlled entry points|
|Components and services|
|Mixin and multi-inheritance heavy||3|
|Magic filenames and locations|
Configuration and extensibility
|Linear application initialization||1|
|Extensible config files||2|
|Support for configuration secrets|
HTTP request and response
|Application-level middleware ("tweens")|
|Inline URL route declarations|
|Default site page templates|
|Default frontend framework|
|Default 404 and 500|
Database and modelling
|Optimistic concurrency control|
|JSON/JSONB and schemaless data|
|Transient data and caching|
Forms and CRUD
|Form autogeneration from models|
|Widgets for SQL manipulation|
|Automatically generated admin|
Shell and notebook
|One click shell||4|
Login and sign up
|Default sign up|
|Federated authentication (Facebook et. al.)|
|Access control lists and permission hierarchy|
|Forbid CSRF'ed POST by default|
|Race condition mitigation|
|Secrets and API token management|
|Plain text email|
|Addon contributed JS and CSS|
|Extensible widget CSS and JS inclusion on a page|
|Deployment model with staging and production|
|Colored log output|
Testing and debugging
|Functional testing - plain response|
1) Django initialization is driven by framework which reads
settings.py 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
settings.py, but the mechanism is not standardized.
4) Integrated IPython Notebook web shell