With my new job I have been using Django for about two months. Most people say it is a ‘batteries-included’ framework, and indeed, it is. Here I want to give my first impressions about Django, to talk about what are the included ‘batteries’ and what I like and dislike about using it so far.
What Are Included?
Based on my experience with Django so far, useful included batteries are:
- A user authentication system so that you do not need to implement your own
- Form and field validation is part of the middleware, you only need know how to customize certain parts in the validation chain, and it is not hard; The official documentation is a must-read
- Messaging framework to display one-time notification message to the user after processing a form or some other types of user input. In my usecase, it was handy for displaying form validation error message to the user.
- Available view decorators to simplify your view handlers
- Django Signals to implement ‘Observer Pattern’. This is useful to make the components in a web system decoupled from each other and more event-driven.
What I Like About Django
A good piece of software requires good documentation. Django documentation is huge and comprehensive! According to my experience with Django so far, I could already find most answers and learn important concepts about Django directly in the online documentation directly. Django documentation is really one of its strong points.
Another advantage of Django is it is one of the most popular (and also most mature?!) web frameworks, therefore it is easy to find solutions (including countless plugins and third-party Django apps) and examples to more difficult problems from the opensource community. That means most of the time you do not need to build from scratch. For example, Huey and django-background-tasks are task queue solutions I researched about which have Django integration support (the solution includes an Django app).
What I Dislike About Django
I do not have strong opinions about Django as I haven’t had extensive experience with it yet, however, based on my limited experience so far, I could mention a few things I do not like about it.
The template system in Django is inconvenient, because a python function cannot be called from within a template directly, and yet Django let you create a custom template tag or filter to achieve the same thing (then why bother?).
Django is too monolithic. For the parts you do not like, there seems to be no easy way to swap them out, for example, Django’s ORM (you cannot simply replace Django ORM with SQLAlchemy, to use SQLAlchemy, you might want to consider using SQLAlchemy with Flask or Pyramid).
Yes, speaking of Django’s ORM, there are quite a few shortcomings. For example, Django model field choices does not enforce
Enumchecks on database level, instead, it only does checking on model forms. For the cases where you want database DDL to implement data type checks, you will need to write some custom model fields. In fact, what’s even worse: no full support for database vendor-specific (for example, Oracle) data types; and the solution is the same: write custom model fields. This is where SQLAlchemy shines, it supports SQL/ORM in different dialects. Another example is missing composite primary key; Django does not support creating a multi-column primary key, you will have to settle with using
unique_together, which translates to
UNIQUEconstraint in SQL DDL; this sounds like a degenerate choice.
Everything seems to be based on the ORM, for projects that does not need the ORM, there seems to be no way to ‘turn it off’.
Some others’ insights about Django from this quora answer.
My experience with Django is still not enough to judge that much; but once I gain more insights I will update this post to share more.