Flask vs Django. Which Is Better for Your Web App?

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.

Review

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.

Project layout

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.

Objections:

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

Conclusion

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

Routing

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.

Conclusion

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

Additional materials

• How Django processes a request.
• Methods of URL registration in Flask.
• URL centralized configuration in Flask.

View layer

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.

Conclusion

• Django +.
• Flask +.

Both frameworks have excellent tools for processing requests.

Model layer

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…

With an eye to it, people give funny answers on Stack Overflow. The answer here offers a more informed decision:

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

Conclusion

Django -, for severe restriction to single ORM. Flask +, for the freedom of choice of tools for tasks.

Template layer

So far both frameworks support:

• templateless responses
• jinja2 templates (django, flask)
• context processors (django, flask)

Server templates are not a bottleneck in web applications for a long time already, so nothing more is required.

Conclusion

Django +. Flask +.

Pros and cons

It seems useless to compare django vs flask performance. Then what should we compare by? Let's see: