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:
Flask key benefits:
Starting from these features we can make a deeper flask vs django comparison.
A conventional project structure is used in django and an arbitrary structure - in flask.
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.
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.
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:
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.
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:
With an eye to it, people give funny answers on Stack Overflow. The answer here offers a more informed decision:
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 +.
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|
In UNIX way, each view should solve single task. This is good idea, but sometimes we need to mix logic of different views on same page. Filter, sort, paginate, or, for example, add comment on product page. In this article I'll show how we can mix such multiple views.
In this article we'll review general approach to working with the best kind of projects - the ones with old untested and undocumented spaghetti code and a tight schedule. We'll review anger management techniques, coping mechanisms and some refactoring tips that might come in handy.