There are two most popular web frameworks in Python. There is the Django with lots of intelligent defaults and the Flask micro framework with complete freedom in the choice of modules. Let’s see, what django vs flask is in 2017.
Hereafter, we will focus on the most recent versions for now. Django - 1.10, Flask - 0.12.
Django key advantages:
- rigid application structure
- lots of batteries
- functional admin panel
- huge community
- as a consequence, a large number of third-party applications
- excellent documentation
Flask key benefits:
- absolute minimalism
- probably the shortest "Hello world" among web skeletons in Python
- there is no even ORM in the delivery (SQL-Alchemy, peewee, etc. can be easily connected though)
- but there is a debugger right in the browser
Starting from these features we can make a deeper flask vs django comparison.
The structure of the application (blueprints - in flask) is equally flexible in Django and Flask. However, due to the inertia of thinking, Django is still blamed for its rigidity.
- Urls.py, models.py and views.py names are not more than conventions. Their use simplifies the adding of new people into the project, as they immediately understand where everything is.
- A long time ago Django application required models.py, even if there were no models in it. It is no longer necessary.
- Django +. Agreements on the structure help and at the same time do not exclude setting flexibility.
- Flask -. It is believed that the "number of different ways to organize Flask code is equal to the number of applications written in Flask". Also, as you can see in Flask’s scaling recommendations, as projects grows, eventually it ends up with a structure similar to Django. "Freedom is slavery".
In Django, connection of URI to view is set in urls.py of the project. Also, urls.py from the project applications are usually connected there. Requests are processed by the first matched view in the regex list. URI can be localized during i18n.
In Flask, URI is almost always set by the view decorator. However, centralized configuration is also possible, like in Django. Extraction of parameters from URL is simpler, and only custom converters allow approaching the flexibility of Django regular expressions.
Before matching url with patterns, the routing module from Werkzeug sorts the URI in an ascending order of complexity. As a result, explicit bypass process can be received through not so explicit flask.Flask.url_map.
- Flask +, for although less flexible, but sufficiently flexible extraction of URL parameters. Also, less obvious URLs bypass process is not so critical. Documentation about URLs localization could not be found fast.
- Django +, for the lack of Flask minor problems.
- How Django processes a request.
- Methods of URL registration in Flask.
- URL centralized configuration in Flask.
This is the part of the web frame, where it is difficult to come up with something special. As a result of routing, some part of the code should get control. The arguments from the URI, request object and perhaps some additional arguments should be transmitted there. It also convenient to connect HTTP-methods restrictions and authorization.
Both frameworks support:
- function based views (django, flask)
- объект запроса (django, flask)
- class based views (django, flask)
- HTTP methods restriction (django, flask)
- other view decorators (django, flask)
The most noticeable difference here is the transfer of the request object. In Django, each view gets it as an individual parameter. It is compliant with the Zen of Python, where explicit is better than implicit. In Flask, the request object is imported from the flask module and at first glance it seems the global variable. Sometimes it is more convenient than forwarding it somewhere deep into the bowels of some form widget. The reasons why this object in Flask is not so global as it seems are well documented.
- Django +.
- Flask +.
Both frameworks have excellent tools for processing requests.
Django relies only on its own ORM. Flask supports at least SQLAlchemy and peewee. That's a key difference between flask vs django.
Yes, there are ways to replace the django ORM with SQLAlchemy. The bitter truth is that at the same time lots of integrations are lost:
- django admin
- model forms
- django rest framework model serializers
- and more…
- Use django ORM, be happy with integration and switch to raw SQL where it can not work properly.
- Or use SQLAlchemy, learning to live with all its faults.
There is a project for django ORM and SQL Alchemy simultaneous usage. The price for such a usage is several limitations of the library.
As there is no ORM for the Flask out of the box, the authors have to create their solutions independent from a specific ORM. So Flask minimalism effects positively on its environment.
Django -, for severe restriction to single ORM. Flask +, for the freedom of choice of tools for tasks.
So far both frameworks support:
Server templates are not a bottleneck in web applications for a long time already, so nothing more is required.
Django +. Flask +.
Pros and cons
It seems useless to compare django vs flask performance. Then what should we compare by? Let's see:
|Feature \ Framework||Django||Flask|
Undoubtedly we have two powerful tools here, with almost no disadvantages. Both are free (decreasing costs for any company), open source, flexible and perfectly suit to startups and enterprise applications. Both are good for outsource or any other IT companies developing software for business. But what should we choose and when?
General recommendations are as follows: if you know exactly why you need granular tuning of Flask, take it.
Otherwise, Django will save you a lot of man-hours with its reasonable defaults and an abundance of ready-made solutions.
If you close to the induction, here are the examples (for the equal conditions let’s assume that both frameworks are unknown for a team):
|Project||What to choose and why|
|A typical online store||Django - there are modules for e-commerce, and ORM possibilities will probably be enough|
|Dynamic blog||Django - examples in the documentation do half the work|
|On-line media||Django - it was created in journalistic realities|
|A beginner in web development who wants to understand how it is arranged||Flask has got a little magic, easy to understand|
|A beginner in web development who wants to create a useful app as soon as possible||Django - a lot of decisions have already been taken, so it is possible to start quicker|
|Integration with existing complex backend system||Flask - it’s just less opinionated|
|REST-ful API||Django - it has Django-Rest-Framework which is great|
|Complex web applications with ingenious SQL queries||Flask - Django-ORM features most likely will not be enough|