Django in 2026. Does it still fit into current development environments
Introduction
Django was first released in 2005 by Adrian Holovaty and Simon Willison. It’s more or less dominated the python web framework since then. Its “batteries included” nature has been a great fit for 1000’s of projects, and while many other frameworks have emerged and marked as the newer and better ones to use, Django continues to be extensively used in many projects.
What I want to do is take a look at the framework as it stands and really look at what django can offer for current projects, but also look at the parts of the framework that could either be improved or removed entirely.
The Why of Django
Django has been around for over two decades, maintaining its popularity and fending off competition from newer frameworks. This longevity is largely due to its core philosophy and robust feature set that solves common web development problems out of the box.
One of Django’s strongest assets is its Object-Relational Mapper (ORM).
It provides a powerful abstraction layer that allows developers to interact with their database using Python code instead of raw SQL. This not only speeds up development but also offers database portability, meaning you can switch from SQLite in development to PostgreSQL in production with minimal changes. The ORM is also way easier to use when compared to third party ORM’s like SQLAlchemy.
While the ORM has its issues (speed and async support), it has a well-designed code structure and a VERY stable migration system. It covers nearly every item you would care to deal with and does support all the main RDB’s. It’s also well integrated into the framework, so you don’t have to worry about setting up interaction code.
The framework also shines with its built-in templating engine. It started life as a copy of the Jinja2 templating engine, but has evolved over time to somewhat eclipse its parent. JS framework developers would look on in envy at the power the templating engine has.
One of the best elements of the templating language is the ability to add more tags and filters to the framework. This not only means that you can extend the templating engine, but others can create add on modules that you can take advantage of. There are also a LOT of modules created by third parties that can be added to django to extend its use. The one I like the most is Django Cotton. This allows you to create components that look and feel VERY similar to components in React and Vue. The difference is that the components don’t need to include Javascript or similar and don’t get put into a shadow DOM, thus no need to have a state management system. You can also still use all the filters and tags from Django, plus any you make yourself.
Security, user management, and session management are often pain points in web development. Django comes with these built in. The session management system is really robust and much better than most other frameworks. I like the fact that the session records are held in the database , thus are long lasting, and they are linked using encrypted references. You can also add your own data into the session manager, thus no need to store data in cookies etc. Its all handled nice and easy by the session manager.
The user Management is not perfect though. The Django team seems to think it works, so why play with it. Yet there are a couple of glaring elements missing. The most obvious one is that customizing the user models is not as straightforward as it could be, and in many cases this is required. The second is that most systems will require a user profile, yet the user model does not come with any ability to handle this. As such you usually end up creating a profile model, which really could be handled by a simple json field or similar in the main user model. Another pain point is the lack of built-in support for Oauth. Yes, there are add on modules to handle this, but it really should be part of the main framework.
There is a bright spark here though. The add on module Django Ninja, while kinda written for API’s, can be used for html pages. It allows for customized authentication modules to be added as well. Django itself does allow for this as well, and there are a lot of additional modules for alternative authentication. I just think they should be part of the core system and not third party add-ons
Django’s built in system for structuring projects is a MASSIVE win for developers. It’s easy to understand and use, and encourages best practices. It’s also very flexible, allowing for customization without having to rewrite the core framework. I think this, more than anything, has allowed Django to stay in front of other frameworks.
For example, I love FastAPI, but you should see the mess that some developers make of it. Django enforces the structure and pushes for reusable code and separation of concerns. This structuring also includes ensuring that settings are kept in a single file, and that they are well-defined. An oddity of this, though, is that they have not added support for environmental variables or .env files in by default. I don’t know any Django developer that does not start by installing dotenv to handle this.
Either way, any coder or project manager should consider the structure and scalability that Django offers to their code before opting for a smaller alternative, especially if they are using developers who are less experienced.
Django’s Admin interface that comes with the framework is a massive time saver for developers. It’s a fully featured CRUD interface that can be customized to fit your needs. It’s also very secure and easy to use. Some developers think that they can use this instead of creating a web app, but the admin console is just the admin console. It does add an extensive list of security options and would be great for Admins monitoring an API system and fixing data issues. It, however, cannot be made into a nice and fancy web app. It has it limits
As a final high point for Django, is the well built and maintained command line interface. It makes deploying code easy. It’s easy to handle the database migration, access to django code shells, and it can be used to gather and move static files to a different location. These kind of commands really do make deployment simple.
The Why Nots of Django
Django has been around for a little over 2 decades. That means is mature and has a large community. However, in some areas it has not really looked at how the world has changed and adapted itself to those changes.
With this in mind, there are a couple of modules that Django should have rewritten or dumped a long time ago.
The Forms module is a prime example of a module that made sense in 2005, but really has no place in 2026. It’s complex to use, and its original purpose was to make it easier for python coders to insert forms into the templates, and of course, handle the reissuing of the templates when errors occur. We just don’t work that way, in today’s world. validation is more likely done on the frontend, and if it is done by the backend, libraries like pydantic or marshmallow are much more appropriate. When it comes to rendering the forms, then it’s a waste of time since the world long ago swapped to using css libraries like bootstrap or tailwind to format the forms, and trying to get the Forms module to use this is additional
work that is not worth the effort. I’ve hated the Forms module since v1.2. I’ve never liked it and never will like it. Just dump it. If you want a good replacement for this, just look at django-cotton. It creates components just like vue and react, but are rendered in the Django templates. That is the future.
It’s also worth noting that Django and HTMX fit together perfectly. This means we can render forms with Django Cotton and similar, more easily than using forms and use Django Ninja with its form validation done using Pydantic and you have a much better user experience and an easier to code one than compared to Forms
My second hated part of Django are generic views and the views mixins. These are the remit of lazy coders in my opinion. Others may feel different, but taking over code where someone has used generic views and mixins, is a real pain. They are also part of the past. We just don’t need them and should not be using them in today’s world.
My last gripe will be the Asyncio support and the ORM. Yes, I said the ORM was a great feature and it is. but it’s had outstanding issues with performance for a very long time and while we can get around them, the issues have never really been addressed. This leads directly into Asyncio support. Django has been SUPER slow to adopt Asyncio, and even now that
support is partial. When you see the capabilities of a framework like FastAPI, you can see the massive benefits of full asyncio support, yet the Django team seems reluctant to adopt it.
Conclusion
In 2023, a speaker at a Django conference said the future of Django was HTMX, and they were right. Django should be maximizing what they do well, such as project structures, Authentication modules, Admin UI’s and a great templating module. These are all things that frameworks like FastAPI just don’t have, and they are the real reason developers still turn to Django in many cases. They are the reason that I would still use Django over FastAPI, for a website that did not require websockets or SEE elements. I can build the site faster and better with Django when compared to FastAPI.
Django also makes it easy to add in additional modules and thus extend it without a massive amount of coding. This is something that frameworks like FastAPI just don’t have.
Yet Django should be looking at FastAPI and the massive leaps it has made. Using Pydantic, Dependency injection, and full async support including websockets and SEE, are all there at your fingertips. I would like to see Django cull outdated modules and replace them with more modern alternatives. It should also consider HTMX and the way it melds with Django.
This makes Django a better choice for many developers who don’t want to use two different frameworks for their projects. Django, Dango Ninja, Django Cotton, and HTMX make a fantastic stack. One, I think outshines stacks like FastAPI/React and similar when it comes to development speed, and scalability.
That is Django’s future, and it’s a bright one, if they take the time to embrace it.