When Everyone Can Write Code with AI, Why Did I Choose to Return to Django?

Preface

Last September, I wrote an article: Is Django Outdated? Thoughts from ASGI to the AI Era

At the time I laid out several of Django's pain points: cumbersome SSE/WebSocket support, the framework being too heavy and not lightweight enough... I even planted a flag: I wouldn't prioritize Django for new projects.

Yet who would have thought the boomerang would come back so quickly.

Just a few months later, after struggling through other tech stacks, I turned my gaze back to Django... 🤣

Ramblings

The code we wrote in those years

Thinking about it, I really miss those days.

My first encounter with web development dates back to 2016.

Back then I used PHP for student team assessment problems, and the code was still that caveman style of concatenating SQL directly in the webpage. 😂

My first proper web development experience was given by Django.

I can barely remember under what circumstances I encountered the Django framework; I only remember that this framework was extremely quick to pick up.

I originally only knew a little Python, and as I learned Django, my Python skills rose with the tide.

I got hooked at version 2.0, and in the blink of an eye version 6.0 has already been released.

From university to work, I've used Django to develop a great many websites and backend projects, wrestled with admin and forms, worried about ORM performance issues, and chewed through quite a bit of the framework source... In short, if we're talking about the framework I'm most proficient with, Django would definitely make the list.

By the way, the backend of my graduation project was also written in Django 😄

What's funny is that for a long time I pronounced Django's name wrong. The correct pronunciation is "Jango" — the D at the front is silent — and even now many people still say "D-jango".

PS: From the 2016 era of handwritten SQL in PHP, to later encountering Django 2.0, I witnessed this framework's solidity. Django's design philosophy is "Batteries Included", which at the time not only helped me earn my first pot of gold, but also gave me confidence in subsequent work, whether facing complex requirements or independent products.

Even though many people complain it's heavy, and some can't even pronounce the name right (Remember, the 'D' is silent), it has always been the technology I find most handy.

OK, that's some rambling. Next, let's get back to the main topic.

Some Attempts

Fortress Besieged by Technology

In search of a more modern development experience, I've tried quite a few popular tech stacks during this period:

• Next.js full-stack (with drizzle, tRPC, better-auth)
• Node.js backend (Hono framework)
• AspNetCore (EFCore, FluentStorage)

I used these technologies to develop several projects respectively:

• Social science testing platform (Next.js full-stack + third-party ws service for chat)
• AI calling (Next.js frontend + hono backend)
• A multi-agent SaaS AI product (AspNetCore + unorthodox frontend)

But none of them actually felt that comfortable; each had its own problems. Next.js full-stack looks wonderful, but the prosperity of the JS/TS ecosystem is also its curse. Setting aside how fragmented the ecosystem is, the biggest problem is still that the ORMs are too hard to use. Prisma and Drizzle both feel like unorthodox hacks 🤣. The only one that somewhat matches my taste, MikroORM, is relatively niche, and pairing it with better-auth still requires all kinds of tinkering.

The Node.js backend experience was pretty good — more precisely, Hono felt good to me. In terms of syntax I prefer nest.js; I believe backend folks would all like nest.js. But hono is really both lightweight and feature-rich. In the comments of my last article Why Is Edge/Serverless the Development Approach Best Suited for Independent Developers?, some readers said it was an advertorial for hono. Sorry, I might write more articles hyping hono in the future 😄

AspNetCore should have the most comfortable coding experience, but it's 2025 now, not 2020, and coding experience is less important than AI adaptability 😂. For enterprise development, this framework is still fine, but for small teams and rapid iteration, development is still a bit slow. Then again, it's more likely that I'm just not skilled enough and didn't design the architecture well. DDD is out of the question for small projects, so I could only use traditional MVC, but once the logic gets complex it easily becomes a mess. In the project I developed, I wrote over 30 Service interfaces alone and over 50 implementation classes. With so many code files all in the service layer, the code was a complete mess, and maintaining it was a headache.

Turning Back to Django

I myself am someone who enjoys learning and tinkering with new technologies, but now I have a lot to do, time is very limited, and I often feel anxious that project progress isn't fast enough.

Striking a balance among ecosystem maturity, development efficiency, and code rigor — especially considering that products nowadays are almost all built around AI — Django is a very suitable choice. It means I can directly and seamlessly call various libraries from the Python ecosystem, with no overhead from cross-language calls.

On top of that, with my years of accumulation in the Django space, and maintaining things myself, once I stopped agonizing over it, the anxiety eased a lot as well.

So rather than spending time wrestling with Auth configuration in Next.js, or writing tedious DTO conversions in .NET, I'd rather use Django's out-of-the-box Admin, ORM, and Auth systems to quickly get the product to market. My DjangoStarter project template was born for this.

Of course, returning doesn't mean ignoring the problems.

In an era where AI and async are popular, choosing Django will run into quite a few issues, but fortunately none of them are unsolvable.

SSE and async are still Django's pain points, but they can be achieved using django-ninja + ASGI. The async issue has been discussed for a long time, and recently every new version has been advancing async support. Now, except that the ORM still can't be truly async, other async support has improved a lot.

After deciding to stick with Django, I checked the official blog again and found it had actually been updated to 6.0. This major version update has many features I'm interested in, such as native WebSocket support and a built-in async task queue, which in one go knocks out two important components of the Django ecosystem: channels and celery 😂

I plan to write another article later to share more about Django 6.0's updates.

Wrapping Up

There's no absolute right or wrong in tech choices, only whether they fit. In the present pursuit of AI-native, rapid delivery, that Django I once dismissed as too heavy is still the most trustworthy companion.

This is an extremely restless era. People with no programming background at all can, with AI, even "generate" a decent-looking Demo without writing a single line of code. Social media is flooded with takes about "AI replacing programmers," and this environment easily makes us feel anxious and lost.

But a Demo is not a product, and generating code is not the same as engineering. If you've looked closely at those AI-generated projects, you'll find that AI-generated code is like a castle on a pile of sand — it looks magnificent but can't withstand the wind and waves.

Fast doesn't mean good; only by walking steadily can you go far. Since AI has helped us solve the problem of writing code slowly, we should spend our energy on making the product solid.

The more it is times like these, the more we need a mature, rigorous framework like Django.

It can help us take those wild, unrestrained ideas and, through a solid ORM, complete authentication, and a stable architecture, land them as truly maintainable, commercially viable products. Rather than wrestling with AI-generated shit-mountain code in a fragmented tech stack.

In this AI era full of uncertainty, Django has given me the certainty I need most.