Aug 16 2018
Using a web framework can speed your development time, letting you focus on the custom parts of your application instead of redeveloping the common scaffolding that all web applications need. In the Python development world, two of the major model-view-controller (MVC) frameworks to choose between are Django and Flask. While both support your application development, they have different philosophies that make a big difference in how they help your team complete its project.
Django is a mature web framework, with its first release back in 2005. It's designed to be ridiculously fast, reassuringly secure, and exceedingly scalable.
There's so much included in Django that it's often described as "batteries included"— it ships with all the features you need to implement a modern web application. Some of Django's most important features include support for:
Additional features in Django support the automatic creation of admin interfaces and advanced internationalization and localization features that allow your web application to serve different languages, time zones and date/number formats.
All of this functionality makes Django very powerful. It's opinionated and has strong guidelines for how to structure a web application. Its time-saving features can present a learning curve for developers just picking up the framework. All of its features and functionality are there whether you need them or not.
If you don't want to do things the Django way, you can disable those features, but you need to understand how they interact with the rest of Django and be careful not to break something else. If there's functionality you need that isn't built in, you can add it with third-party extensions like the Django REST Framework or customize yourself. There's an active community you can draw on to get support.
Flask is a few years younger than Django and has an active, but smaller, community. Its website describes it as fun and easy to set up.
The difference in the way Flask describes itself and Django describes itself gives a flavor of the difference between the frameworks themselves. Unlike Django, which is all-inclusive and knows it, Flask is designed to be a minimal microframework, offering an extensible, do-it-yourself solution, without a lot of opinions about how you implement your system. Its built-in functionality includes:
The micro-nature of Flask means there's a smaller learning curve than with Django, and it's easier to get started building a small application. It can be extended with third party packages, meaning you can choose the solution that best matches your needs; there's a large set of available extensions to handle functionality like database access and authentication. Having to choose the right extension adds complexity to developing applications. You have to pick the right components and you have to configure them and make sure they all work together properly.
You have power and you have control, but you can end up adding so many third party products for core functionality that you end up effectively recreating Django.
There are plenty of major websites built with both these frameworks. Many developers recommend using Flask for early prototyping, because it's quick to get started with, and then building the production application in Django, because it has built-in all the features you need to make the application production-ready. Of course, that means you end up building the application twice.
And it's just as easy to argue that you should build a prototype in Django, because its built-in support for almost everything makes it easy to throw together a proof-of-concept. Then when you've tested an idea and know what you want to do and what you need, you can switch to Flask and customize your environment with exactly the components and support your application needs.
There are lots of production applications built in Flask for exactly that reason; they don't need everything Django has. If all you're building is a simple API service that responds to requests, you may not need fancy features like authentication and session management.
The best way to make the choice is by understanding what your project's end-state is and asking what will your project need a year from now, not what does it need today. Despite all the emphasis on rapid delivery, writing code is really about building applications for the long-term. Knowing what you want your application's future to look like can help you choose the right framework today.
Want more? Head back to the Tivix blog