Django vs Flask - Deadlines vs Control

Django vs Flask is mostly about philosophy (batteries included vs barebones), and what you want out of the tools you’re using.

Flask is a barebones DIY approach. If you know what you want to build, and want complete control over that then Flask is great. It provides you with the skeletal base to work with but does not provide much more than that.

Django on the other hand is batteries included (not activated) and is a bit opiniated. This lets other django devs get started up and running quickly, it allows ease of maintenance of 3rd party apps, and allows for a more uniform ecosystem – this means there is a LOT to choose from.

So in a situation when you don’t know what you will have to build Django gets you running faster.

• Maybe you suddenly need LDAP support?
• Lots of DB relations, many to many fields
• Complicated Form logic and Handling (formsets is just one example)
• Rest Frameworks
• Integration with some obscure tech?
• Maybe you have to iterate on some complicated database designs quickly?
• More advanced debugging?
• Viewing and inspecting ORM queries?
• Integration with OAuth?
• Maybe push notifications?
• Support for Sorl? Elastic search?
• Tree based tagging/heirarchy (maybe to use with permissions?)
• Ratelimiting, honeypots for admin logins? much moree..

All of this is possible with Flask. But it’s not guaranteed that you’ll find a maintained (or any for that matter) 3rd party packages. But it’s almost a guarantee that you will find it for Django (huge community + opiniated framework)

But once you’ve gone through the initial phase, the implicit abstractions of Django cause more harm than good. Things become intertwined or as Rich Hickey likes to call it "complected", and you’re somehow limited to do things the Django way. This is not bad, but on large projects it can be severely limiting.

Other benefits of Django are the inbuilt admin module, persmissions system, secure auth, secure mail modules, etc.

But the single biggest gain is..

..the Django ORM. It’s easier than SQLAlchemy by an order of magnitude for most simple queries, and maybe a bit tougher for complex queries (ofcourse this is my opinion, some folks believe otherwise). But the complex queries are 1 in 100, and even then Django ORM is very flexible (+ there’s always RAW Sql)

Django works predicatably. It’s much easier to find issues and come across similar problems which the community has faced and resolved already. This is a huge gain when you are solving problems for business.

More Benefits

Lets be honest, in most small to medium sized web projects we end up doing a ton of CRUD. We have to deal a lot with data handling, and data modelling. All of this is much easier with Django ORM. I’ve lately been trying this out with Clojure and I can see why ORM is not really needed, but that does not translate well in languages where we’re using classes and traditional OOP as ways of data modelling.

Django DB Migrations are the best in class. 100% automated and you will never have to worry about it again ever.

Django docs are amazing to read and follow. They are extremely indepth and 99 out of 100 times that is the only resource needed to figure out how to do something.

Django saves a lot of time as it has a lot of stuff included. I truly believe it’s much much faster to get things working at production level quality very quickly with Django.

Lastly, I would like to say that all the above is just circumstantial. It’s important to weight down the benefits and the tradeoffs based on your requirements. Falling into the trap of dogma is always bad.

Flask vs Django has been discussed to death over the years and you will find a lot of varied opinion there.

That makes the tag line of Django really apt, and beautiful to conclude my thoughts on:

Django - The web framework for perfectionists with deadlines.