The decline of Django

David Dahan
Oct 2021 9 min

Let's face it, it’s not very exciting to be a Django developer today.

Since Django 2.0, version numbers use a loose form of semantic versioning, which gives the feeling there are many new features because there are new versions, but it's not the reality.

Lots of developers are choosing to shift to node.js based backends (even if sometimes I think it's not a wise choice, but this would deserve another post to explain).

The purpose here is not to blame anyone for this because Django is a foundation, and without volunteers or funds, nothing can happen. I loved Django and still love it, but sometimes can feel a little bit frustrated by what Django could have evolved towards but did not, purposefully or not.


I'm talking from an external point of view, I'm not an expert knowing exactly what's happening inside the Django Teams and I don't read many tickets. I'm just the guy who waits for new versions with expectations, reads changelog, and keeps being disappointed. If something is wrong or inaccurate in this post, please just tell me and I'll edit the mistake.

Let's now browse my main frustration points.

No efforts are made to modernize tooling

Outdated Documentation

Django is known to be extensively documented, and it's true, and I would even dare to say sometimes it's too documented, and the important stuff 90% of people are looking for is hidden by details that are relevant to 10% of people. But it's more an opinion than a fact, lot's of people love that documentation is often self-sufficient to understand everything, unlike other tools in which you need to read blog posts to truly understand.

For me, in documentation, the main issue is not about the "what", but the "how". After many years of using it, I'm still not sure how it's organised. Navigation from one page to another seems unclear to me. So like many people I guess, I use search. However:

  • Searching from Google, it's really hard to get relevant results. Documentation is scattered between versions and you often get results from older versions, with absolutely no reason. Django documentation SEO seems to be broken, I don't know why.
  • Searching within the Django website is not better, the results are rarely what I expect.

The best process for me to find relevant Django doc today is googling, finding a Stack Overflow post, and having someone pointing to a Django doc.

I'm not whining about this, but the comparison hurts. Take vue.js doc or tailwind CSS doc. You'll find good looking documentation, clear navigation menus, instant search powered by algolia, accesible easily from Google. I'm not whining and saying everything is bad (that's not the case at all), I'm just comparing with newer tools and can't help thinking it could be way better.

Outdated collaboration tools

On the getting help page, I see links to Django IRC channel to ask for a question, and Ticket tracker to report a bug. As a guy who still uses RSS feed rather than twitter, I'm not saying that Discord or Github issues are necessarily better or more suited tools, but come on! If you're a 22 years old student, you probably never used and will never use IRC.

Django looks like the 40 years old guy who feels "in" using Facebook, while everyone else is already using Instagram or TikTok. You could argue that marketing is not the way to make a good framework. I'd answer that to make a good framework, you need a community, and to attract new people, you need marketing.

Partial VS Code support

Let's say you're a beginner and need to pick an IDE today. Let me simplify this:

  • One one hand, you have PyCharm Pro that has an extensive support of Django out of the box. You need to pay, the IDE is not very fast, a little bit bloated, specialized in Python.

  • One the other hand, you have VS Code which is becoming a “no-brainer choice” code editing tool for many people. It's free, it's fast, widely used, it evolves at an amazing pace, it's developed by Microsoft, has a huge community, and supports many languages out of the box. But Django support is partial, for example I never found a tool (not a hack) to auto-format Dango templates.

As a personal opinion, I see no point using PyCharm today except for a pure Django project. VS Code will be better in most cases. But dealing with two IDEs is not an option.

I don’t see a Django beginner spending money to buy PyCharm pro Edition (the free edition has no true Django support), especially because VS Code is free. Which means the first experience this beginner will get with Django templates will be messy. This is another way to keep newcomers away from Django.

Django's obsession to make yearly partnerships with PyCharm (30% discount) because they need money, is a short term vision to make the framework live. Instead, they could build an official VS Code plugin that would give support parity with PyCharm. To me, it’s truly more valuable when it’s official. It brings trust, and removes the need of choosing among 10 different plugins that overlap themselves. That is the main (only?) advantage of using Pycharm Pro today in a Django project.

Bad Official Admin GUI UX

Auto scaffolded Django admin GUI has always been a strength to the framework. But UX standards have evolved, especially with Single Page Applications. We could say a lot, but I'll just stick to the fact that in 2021, I don't want a page reload after making a change. So, is even AJAX too modern for Django?

Async support is still incomplete, 6 years later

After many years of waiting, async support is still partial, and this creates complexity.

I remember 2016: Andrew Godwin, a main Django developer, after a kickstarter campaign, launched Django Channels, a way to add async capabilities to Django. Heroku published an excellent blog post about it.

Whilst channels added a way to add some async functionality to Django apps, Django at its core were still synchronous. In the meantime, maybe in 2018 or 2019, Django decided to rewrite Django core in an asynchronous way. From what I understood, this is a huge amount of work and is done part by part (WSGI handler, base handler, the view layer, the ORM, etc.)

So if you're a beginner and just want to add websockets to your Django project today, you need to understand that some parts of your framework are synchronous, other are asynchronous, and that in the end it does not matter at all because you have to use an external package to make async stuff like websockets work. So in official documentation, ignore everything about async stuff, write your Django code as usual, but then when you want to add websockets, read the Django Channels documentation and change the structure of your code at this time. Someday when async support is fully complete, you'll be able to get rid of Django Channels, and rewrite your code again.

This current state is too complex and you'd better not be a beginner if you need to deal with async in Django. The funny thing is that we can not blame anyone for this, because there is no evidence of a better way to do it. But the result is the same, we're given a "temporary" solution for years. It's not the most elegant way, but it works.

A "feature" that takes more than 6 years to be complete reveals two major weaknesses for Django:

  • When you loosely couple a feature to build and an individual, the result is very unpredictable. I love Andrew Godwin, what he made for Django is unestimable. But come on, if this guy stops coding to grow wheat in the countryside, Django async is dead? Or even maybe Django. A little bit like Evan You and Vue.js.
  • Django is a victim of its full-featuredness, and its serious will to not break anything between versions. This is the perfect example to illustrate it.

I think a great support of real-time is essential nowadays. I can not say having to use a plugin that forces you to change the core of your code is a convenient way to do it. Hence having real async needs is IMO a right reason to move to node.js backend today.

Static types are right here in Python, but not used in Django

Static typing is amazing to reduce bugs. If you ever replaced pure Javascript by Typescript, you probably understand how better and confident you feel with static typing.

Fortunately for us, Python language is awesome, and in 2015 were introduced Type hints, a way to optionally type Python, without impacting the runtime itself. Then we had mypy, an official Python type checker.

So, now we have the language and the tool, it should be a piece of cake to be integrated into Django right? Well, no. While type hints have existed in Python for 6 years, I found no mention of them in the official Django documentation. All I found is, again, an unofficial package that brings Django stubs (type definitions). While I admit not everything is supposed to be part of the official code (Django REST Framework is a good example of that), I can't help thinking type definitions are so closely related to the framework itself that they should be a part of it.

The philosophy of Django itself is "full-featured", and if I wanted to do plumbing and search for plugins for everything, I'd use Flask instead.

Speaking of other Python frameworks, it's interesting to note that FastAPI uses Pydantic which provides data validation using python type annotations.

Django always deals with MVC architecture while you might now need it for back-end only

10 years ago, MVC (or MVT for Django) architecture was king and frameworks like Django or Rails were state of the art. Today however, you might want to build a SPA, and use Django for the back-end only. In the "MVT" architecture, you would use the "M" and "V" only, the "V" part returning JSON to your front-end.

But if you can move mountains you can move molehills, right? Yes but no. Django's official primary purpose is not to let you build an API, but a website. Which means if you use Django with this goal in mind, philosophically speaking, you're not using the right tool, as you'll need external packages to do that. On the contrary, FastAPI has this specific purpose in mind!

Of course, you can build APIs with Django, but since it's not the main purpose, for example you don't have embedded swagger like you'd have with FastAPI. Or when a new way to build API emerges (Hello GraphQL), you have no mention of it in the documentation, while solutions do exist.

Speaking of the documentation, it can feel cumbersome by always referring to all M+V+T tiers while you don't care about templates. Imagine a book in which you'd have to skip one page every two pages.

So, Django can build APIs, but it's not primarily designed for. I'd love to see a fork of Django, specialized in backend. Or a way to make a clean and modern front-end with Django.

Some new pieces of tech are just ignored

I'm not saying Django should find a way to integrate every new trendy tech in the framework. But at least, I think there should be mentions in the docs about the possibilities you have for this. When I'm trying to embrace a new piece of technology with Django, I always get the feeling there could be a better way.

The examples I have in mind:

  • Phoenix LiveView → I'm jealous to have no equivalent, this is an amazing way to modernize the front-end.
  • Serverless → While I agree it's not a part of the framework and kind of unrelated, absolutely no mention of it in the docs perplexes me.
  • SPAs → That's not Django business, but for example it could be mentioned how to serve a SPA using Django static files.

What does the future of Django look like?

First, I'd say despite its defaults and difficulties to embrace the modern world, in 2021, Django remains an amazing solution as a "full-featured framework" and has no equivalent in the node.js world. This is precisely its best chance to survive in my opinion.

The main reason I'm still using Django in 2021 is not Python itself: even if Python is way easier and pleasant to use that JS/TS, and has a better standard library, there are on the other hand some reasons to prefer JS/TS, like using the same language on front-end and back-end. The real reason I'm still using Django in 2021 is the "all-batteries-included" philosophy that makes me spend less time and less decision fatigue in building tooling (what I call plumbing).

But what if tomorrow, Microsoft launches a full-featured node/Typescript framework? You would get:

  • all modern features and tooling Django has failed to provide over the last years
  • the qualities of Django itself (all batteries included, consistence, security, support, stability)
  • having to master only one language as a developer.
  • safety of a big corp to maintain the framework, rather than relying on individuals

In my opinion, a framework like this would nail it, and would leave no hope for a Django future. In the meantime, the Django community still exists, even if it seems to slowly decline. Maybe the rise of IA and data science helps Python to shine, which in turn helps Django to get newcomers, not sure about this: I have clues, not stats.

Django sounds like a framework that was top of its category 10 years ago, and is still the top of this category today, with this category becoming less and less relevant over time.

Even if we can not blame Django Foundation for not having enough money or taskforce, can we blame them for their willingness to blindly stick with the original purpose of Django?

written by
David Dahan