当人人都能用 AI 写代码时,我为什么选择重回 Django?
折腾了一圈Next.js和AspNetCore,发现还是Django顺手。AI写代码再快,也架不住它生成的是一堆散装垃圾。与其在花里胡哨的新框架里折腾Auth,不如用自带电池的Django把产品做稳。回旋镖来得真快。
目录5 个章节
前言
去年9月,我写了一篇文章:Django过时了吗?从ASGI到AI时代的思考
当时痛陈 Django 的几个痛点:SSE/WebSocket 支持繁琐、框架太重不够轻量化……甚至立了 flag:新项目不会优先考虑 Django。
然而,谁能想到回旋镖来得这么快。
仅仅几个月后,经历在其他技术栈的摸爬滚打,我又把目光重新投向了 Django……🤣
碎碎念
那些年,我们写过的代码
说起来真是怀念啊。
我第一次接触 Web 开发得追溯到 2016 年。
那时用 PHP 做学生团队的考核题,代码还是那种直接在网页里拼接 SQL 的原始人写法。😂
第一次正经的 Web 开发体验,就是 Django 给的。
我已经记不太清楚是在什么情况下接触到 Django 框架了,只记得这个框架上手极快。
本来我只会一点点 Python,随着学习 Django,Python 水平也水涨船高。
从 2.0 版本入坑,一转眼现在 6.0 版本都发布了。
从大学到工作,我用 Django 开发了非常多的网站和后端项目,和admin、form这些斗智斗勇,操心过ORM的性能问题,也啃了不少框架源码… 总之要说我最熟练的框架,那 Django 肯定是能排上名的。
话说我毕设的后端也是用 Django 写的😄
很搞笑的是,我好长时间都把 Django 的名字念错了,正确叫法是“姜戈”,最前面的 D 不发音,而直到现在还有很多人念“D姜戈”。
PS:从 2016 年手写 SQL 的 PHP 时代,到后来接触 Django 2.0,我见证了这个框架的稳健。Django 的设计哲学是 "Batteries Included"(自带电池),这在当时不仅帮我赚到了第一桶金,也让我在后续的工作中,无论是面对复杂的需求还是独立产品,都有底气。
尽管很多人吐槽它重,甚至连名字都念不对(Remember, the 'D' is silent),但它始终是我用得最趁手的技术。
OK,这是一些碎碎念,接下来说回正题。
一些尝试
技术围城
为了寻找更现代的开发体验,这段时间我尝试了不少热门技术栈:
- Next.js 全栈(搭配 drizzle, tRPC, better-auth)
- Node.js 后端(Hono 框架)
- AspNetCore(EFCore, FluentStorage)
我分别用这些技术开发了几个项目:
- 社科测试平台(Next.js全栈 + 第三方 ws 服务实现聊天)
- AI通话(Next.js 前端 + hono 后端)
- 一个多 agent 的 SaaS AI 产品(AspNetCore+邪修前端)
但其实都不是很顺手,各有各的问题,Next.js 全栈看起来很美好,但JS/TS 生态的繁荣也是它的诅咒,抛开生态非常散装不谈,最大的问题还是ORM太难用了,Prisma 和 Drizzle 感觉都是邪修🤣,唯一比较符合我口味的 MikroORM 又比较小众,搭配 better-auth 用还要各种折腾。
Node.js 后端体验还不错,准确说是 Hono 给我的感觉不错,语法上来讲我是更喜欢 nest.js 的,相信后端同学都会喜欢这个 nest.js ,不过 hono 实在是又轻功能又多,上次那篇 为什么说 Edge/Serverless 是最适合独立开发者的开发方式? 的文章,评论区有网友说是 hono 的软文。不好意思,我以后还可能写文章继续吹 hono 😄
AspNetCore 应该是编码体验最舒服的,不过现在是 2025 年,而不是 2020 年,编码体验不如 AI 适配性重要了😂,现在企业级开发的话,这个框架还是没问题的,但小团队、快速迭代的模式,开发起来速度还是慢了点,不过更大可能是我太菜了,架构没设计好,DDD在小项目是不可能用了,只能用传统MVC,但逻辑一复杂又容易变成一坨,我开发的这个项目,光 Service 接口就写了 30 多个,实现类 50 多个,这么多代码文件都在 service 层,代码乱得一批,维护起来令人头大。
重新转向Django
我本身是一个乐于学习和折腾新技术的人,但现在要做的事情很多,时间是非常有限的,常常为项目进度不够快而焦虑。
在生态成熟度、开发效率和代码严谨性之间做一个平衡,特别是考虑到现在的产品几乎都是围绕 AI 构建的,Django 就是一个非常合适的选择。意味着可以直接无缝调用各种 Python 生态的库,没有任何跨语言调用的损耗。
再加上我在 Django 领域多年的积累,以及自己维护,不再纠结之后,焦虑也随之减轻了很多。
所以与其花时间在 Next.js 里折腾 Auth 配置,或者在 .NET 里写繁琐的 DTO 转换,不如用 Django 开箱即用的 Admin、ORM 和 Auth 系统,快速把产品推向市场。我的 DjangoStarter项目模板 就是为此而生的。
当然,回归不代表无视问题。
在 AI 和异步流行的时代,选择 Django 会遇到不少问题,好在都不是无解。
SSE 和异步依然是 Django 的痛点,不过使用 django-ninja + ASGI 可以实现;异步的问题谈了很久了,近来每个新版本也都在推进异步的支持,现在除了 ORM 不能真正异步,其他的异步支持好了很多了。
决定继续 Django 之后,我又关注了一下官方博客,发现居然都更新到 6.0 了,这次大版本更新,有很多我感兴趣的功能,比如原生支持 WebSocket 和内置异步任务队列,这下一次把两个 Django 生态的重要组件: channels 和 celery 都干掉了😂
关于 Django 6.0 的更多更新内容,我打算后面继续写一篇文章分享。
小结
技术选型没有绝对的对错,只有适合与否。在追求 AI 原生、快速交付的当下,那个曾经被我嫌弃太重的 Django,依然是最值得信赖的伙伴。
如今是一个极度浮躁的时代。没有任何编程基础的人,利用 AI 甚至可以一行代码不写就“生成”出一个像模像样的 Demo 软件。社交媒体上充斥着“AI 取代程序员”的论调,这种环境很容易让我们感到焦虑和迷茫。
但 Demo 不是产品,生成代码也不等于工程化。 如果你深入看过那些 AI 生成的项目,就会发现 AI 生成的代码像沙堆上的城堡,看似华丽却经不起风浪。
快并不代表好,走得稳才能走得远。 既然 AI 帮我们解决了写代码慢的问题,那我们就应该把精力花在把产品做稳上。
越是在这种时候,我们越需要像 Django 这样成熟、严谨的框架。
它能帮我们把那些天马行空的想法,通过坚实的 ORM、完善的鉴权和稳定的架构,落地成真正可维护、可商用的产品。而不是在零散的技术栈里和 AI 生成的屎山代码搏斗。
在这个充满不确定性的 AI 时代,Django 给了我最需要的确定性。
_EOF_
当人人都能用 AI 写代码时,我为什么选择重回 Django?
- 本文作者:
- 程序设计实验室
- 版权声明:
- 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
相关文章
《修真四万年》披着玄幻外皮的伪科幻
前言 自从元旦前后羊了个羊之后,就一直很懒没有更新博客。 最近整理了一下笔记,看到之前写的一些读后感,感觉现在越来越不爱思考了,以前看书一般挑名著来看,再不济也是看金庸、古龙这种经典作品,现在退化到整天利用碎片时间看不需要动脑的网络小说。 不得不说,网络小说的质量可能不咋样,但读起来确实是挺爽的,或许这就是奶头乐吧…… 继上次看了一本很降智的小说之后,我又开始了新的看书之旅,这次是卧牛真人的《修真
2023-01-17 · 0_网络小说 · 约 1 分钟
Java使用JDBC操作SQLite
SQLite介紹 SQLite是一個輕量級的資料庫系統,不需要安裝就可以使用,也可以十分容易的就內嵌於系統內,FireFox就內嵌SQLite,可以在FireFox上直接使用JavaScript來呼叫操作資料庫。 SQLite是由C語言撰寫而已,可以跨Linux及Windows等平台,在Java存取及操作上則可使用JDBC來連線SQLite。 在JDBC連線SQLite上,大概分成二種方式,一種是
2021-12-18 · Java · 约 1 分钟
德力西(DELIXI)充电保护器开箱
鼓包电池?怪谁整晚充电。买个保护器就解决了?设计倒还行。德力西充电保护器,防止过充?延长寿命?试试看吧。
2025-10-28 · 其他 · 约 1 分钟
一个玄学的爬虫bug竟让我放弃Python语言!?背后的原因令人唏嘘~
每一位成功的程序员,背后也许都站着无数秃头的男人——为其提供各种开发工具&代码库,当然也包括…… 各种玄学bug…… 玄学的开端 最近在用Python做一个爬虫项目的时候遇到一个很奇怪的问题,而且还不是每次都会触发,实在是令人费解…… 报错信息如下: UnicodeEncodeError: 'latin-1' codec can't encode character '\u2026' in pos
2021-12-18 · 爬虫 · 约 1 分钟
讨论
共 0 条加载评论中…