Want to Code Faster? Kite is a plugin for PyCharm, Atom, Vim, VSCode, Sublime Text, and IntelliJ that uses machine learning to provide you with code completions in real time sorted by relevance. Start coding faster today. Send Download Link Download Kite Free

What is Django? Django’s website states that “Django makes it easier to build better Web apps more quickly and with less code,” and calls Django “the web framework for perfectionists with deadlines”. Indeed, Django is a mature framework that (by default) makes many decisions on its own so that the user has that cookie-cutter utility needed in a typical web application. If you’re happy with most of those decisions and the defaults Django provides, you can have a relatively complex web application running in quite a short time. Some companies that use Django: Instagram

Pinterest

Udemy

Coursera

Zapier What is Flask? The Flask website describes Flask as “a microframework for Python based on Werkzeug, Jinja 2 and good intentions” and sports the slogan “web development, one drop at a time.” Once again, this gives you a good sense of the space Flask tries to fill in the overcrowded world of Python web frameworks. Specifically, Flask aims to serve as a minimal framework that handles a few things well, but then leaves more of the decisions on how you want to build your web application up to you – either through custom implementations or any number of 3rd party extensions. Companies that use Flask: Netflix

Lyft

Reddit

Zillow

MailGun How do these different approaches pan out? To better understand the similarities and differences between Flask and Django, let’s take a look at what they offer through the scope of some high-level features you might find in typical web applications. The development environment Development Server Both Django and Flask come packaged with development servers that make it easy and convenient to get started on building your web application quickly. They come with features that you’d expect from a mature web framework, such as the ability to handle requests, serve static files (for development), and detect when your code changes in order to auto-restart and make your changes available. Command Line Utilities Django provides a command line utility that comes with a selection of management commands. One of these runs the development server, while others are used for managing static files and dealing with migrations. Third party apps can enhance the command line utility by offering their own management commands and it can be useful (and easy) to add some of your own. Flask also has a built-in command line utility that uses click which is a mature and robust command line interface toolkit. Just as with Django, it’s possible to add your own custom commands and Flask Extensions can also contribute their own. Testing Both frameworks offer tools that build upon the built-in python unittest framework to make testing your web application easier. Each has a test client that allows you to easily send test requests to your endpoints and inspect the response to validate correct behavior programmatically. Since both Flask and Django use the built-in python unittest framework, you can swap out default test runners and configure your tests to your preference. Request Handling Routes & Views Both Flask and Django allow you to handle requests by defining views either as a function or a class, and then mapping routes (URL paths) to those views. By default, Django organizes your request handling logic (views) separately from your routing definition. For each app, you typically define your “url patterns” in a single file that maps each pattern to a view for handling requests that match that url pattern. An advantage to this method is having a single place in which you can see where a request should be routed. While you can do the same thing in Flask, it’s more common to see the routes declared in the same place as the view, either with a decorator or by explicitly registering the route on the application object (or blueprint if you’re using them). The following examples of routing the “home/” path illustrate the difference. In Django:

from django.urls import path



from .views import HomeView



urlpatterns = [

path('home/', HomeView.as_view(), name='home'),

]

In Flask:

from flask import Flask, render_template



app = Flask(__name__)



@app.route('/home/')

def home_view():

"""

Definition of Home View

"""

return render_template("home.html")

When it comes to class-based views, Django begins to differentiate itself by offering a large variety of additional base classes that offer modifiable base implementations for some common patterns you find in web applications. For example, the FormView class bundles the HTTP GET and POST logic for displaying and processing the inputs for a Django Form. There are a number of these generic views that allow you to build a lot quickly and with minimal code if what you’re building fits the mold. The Request Object Both Flask and Django have a “request object” that holds data about the request, but how this object is made available by the framework is pretty different. In Django, the request object is passed to the view as an argument and must be passed around any time it is needed. The big advantage of this design decision is that the business logic of the application is decoupled from the context of a request. When something needs to be tied to a request context, you’re required to explicitly pass the request object, making it clear where the request context begins and ends. The disadvantage is that whenever you want access to the request it can be cumbersome to have to pass the request object around. Flask, on the other hand, takes a very different approach and uses a thread-local variable for storing the request. This means that if you want access to the request object, you simply have to import the request object from flask and reference it in your code. The upside with this approach is that you don’t need to pass the request around. If you want it – you just access it. The pretty big downside is that if you aren’t careful, it can be confusing to know when you are in a request context or not. This leads to many new Flask users getting errors about there being no request context when trying to run their code. Templates For its templating engine, Flask uses an existing tool called Jinja2. This is a very popular templating engine with many features that enable you to build a lot of the static html portions of your website without needing to do too much repetitious work. Django has its own templating engine that has a very similar syntax and a similar feature set to Jinja 2. In fact, if you prefer to just use Jinja2, it’s simple enough to swap it in as the templating engine of choice. A description of the differences between Jinja2 and Django’s templating engine can be found here, but to give a sense of the syntax see the following. Jinja2:

{% for item in obj.get_items() %} {{item}} {% endfor %}

Django:

{% for item in obj.get_items %} {{item}} {% endfor %}

Static Files Keeping track of static files and knowing how to reference them from within your code and templates in a way that supports different environments can be a bit frustrating. To solve this, both frameworks offer utilities for referencing static files so that, based on your configuration, the urls referencing your static files are properly generated for that environment. Additionally, Django provides a management command for collecting static files from your various apps and putting them wherever your configuration specifies. This comes in handy when it comes to deploying your application in a production environment. Here is an example of how simple it is to reference static files within templates for each framework. Django:

{% load static %} <link type="text/css" href="{% static "style.css" %}">

Flask:

<link type="text/css" href="{{ url_for('static', filename='style.css') }}">

Extensibility Flask, by nature, was made to be extended. As part of its design is that it specifically avoids offering solutions to things that they feel are application specific and allows for 3rd party and custom extensions that plug right into the application object. You can read up on Flask Extensions here. Although Django makes more decisions for you, it similarly doesn’t support every eventuality and has a pluggable application structure that allows for a lot of customization and extension. Ultimately, both frameworks have a very rich selection of 3rd party extensions so that chances are, if you need a solution to what seems like a common problem, you’re very likely to find an existing solution.

Want to Code Faster? Kite is a plugin for PyCharm, Atom, Vim, VSCode, Sublime Text, and IntelliJ that uses machine learning to provide you with code completions in real time sorted by relevance. Start coding faster today. Send Download Link Download Kite Free