Emptyhammock

When you’re learning to implement web applications

Start by using Flask to write a few simple web applications that don’t need a database. Examples of appropriate projects:

• Computation service (e.g., Fahrenheit-to-Celsius conversion)
• Data transformation (e.g., upload a CSV file, get an Excel file back)
• Informational (e.g., display information fetched from a web service)

You’ll be faster off the starting line with Flask. And you want to have Flask in your tool chest for the long term. Aside from web applications, you’ll want to use Jinja2, the templating system used with Flask, in additional situations.

Gotta have a database? Learn enough about running MongoDB and using its APIs to use with your Flask web application.

Avoid the tutorials that direct you to install a bunch of flask-foo packages to add an ORM for integration with a relational database, database migrations, user registration support, etc. That’s the point where it is time to switch to Django, because they’ve taken you out of the sweet spot for Flask. Form support for Flask with CSRF protection is fine, but don’t rebuild more and more of Django piece by piece.

Start learning Django by following the well-known poll app tutorial in the Django documentation. After you finish the tutorial, write a few simple CRUD applications, at least one of which uses the Django admin for all data entry/update, and at least one of which uses Django Class-Based Views for data entry/update (with the Django admin available behind the scenes).

When you’re implementing real web applications

Consider these aspects of the application:

• Anticipated lifetime

  Will the application be relied on for some years? That’s a point in favor of Django.

  Is the application just a prototype, or will it be used only in the short term? Select the framework that allows you to implement a secure, working app the most quickly using your current skills.

• Anticipated amount of function in the web app over time

  Scope or purpose of the application makes growth in function likely? That’s a point in favor of Django.

  Small and well-defined scope? That’s a point in favor of Flask.

• Type of data persistence with the web application

  None? That’s a point in flavor of Flask.

  Traditional RDBMS? That’s a point in favor of Django.

  NoSQL or some other non-relational data store? That’s a point in favor of Flask.

Why?

• Flask can do everything Django can do, if you add in a bunch of Flask extensions to catch up with what Django has out of the box. These extensions are installed separately, documented separately, have different release cycles and vulnerability response protocols, have much smaller teams supporting them, and overall they result in a less holistic design.
• Core Flask (i.e., without adding a bunch of extensions that add in common web framework capabilities) is smaller than Django. There’s less surface area for attack (e.g., fewer features to misconfigure, even if the framework is “perfect”), and less code to consider if you need to understand how some aspect of the framework works in detail.
• The structure of Django applications is more regular. An experienced Django developer can find her way around unfamiliar Django applications without much delay. This is particularly useful for applications with long lifetimes, as the set of maintainers will most likely change.
• If you’re not using much of what Django provides, particularly the ORM, then you’re not taking advantage of the holistic aspects. Flask isn’t at any sort of disadvantage in those cases.

Further reading

• Django vs Flask A Practitioner’s Perspective

  A detailed comparison of Flask and Django.

• “The Flask Mega Tutorial”

  This is a great resource for learning Flask, but it essentially recreates a Django-like framework by assembling a bunch of Flask extensions. It would be great to have a tutorial with the same good pedagogical characteristics but which covered use cases where Django would not be a natural choice for the framework.

• The Django poll app tutorial