Comparison

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

Introduction

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.

Frameworks

Websauna

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

Pyramid

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

Default template engine: None

Django

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

Default template engine: Django

Flask

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

Default template engine: Jinja

Comparison

Note

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.

Legend:
Subsystem Websauna Pyramid Django Flask

Architechture

Batteries included approach
Free from global variables
Developer controlled entry points
Components and services
Mixin and multi-inheritance heavy 3
Events
Magic filenames and locations
URL dispatch
Traversal
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

Templating

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
Migrations
Transient data and caching

Forms and CRUD

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

Admin

Automatically generated admin

Shell and notebook

One click shell 4

Login and sign up

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

Security

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

Responsiveness

Delayed tasks
Scheduled tasks

Email

Plain text email
HTML email

Static assets

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

Devops

Deployment model with staging and production
Colored log output
Backuping

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 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.

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

4) Integrated IPython Notebook web shell