我几次开始一个项目时，觉得也许Django太重了，但很快…

我也非常喜欢Django。我可以非常快速地搭建一个可以运行的项目。 在我的日常工作里，我使用Go，虽然它还不错，但我为简单的API端点编写的代码量是Django的10倍。一旦你添加了用于过滤、分页等的查询参数，代码量会变得更长。在上面添加权限模型也会有类似的情况。当然，性能差异很大，但就我所做的大部分事情而言，数据库查询在性能上占主导地位，即使是在Python中。

完全同意。我也认为对于一个自包含的SaaS初创公司来说，用Django来做几乎所有的事情都很简单。营销可以通过Wagtail来完成。支持由一个可重用的应用程序管理，这个应用程序是每个页面上的一个简单静态元素（类似于Intercom），会将用户引导到标准的Django页面，并收集有关问题的一些信息，包括提出问题的用户（如果已认证的话）。 我尝试进一步简化堆栈，使用SQLite和Borg进行备份。缓存使用Diskcache。 部署稍微复杂一些。我使用容器和podman以及systemd，但也可以轻松地进行git pull和gunicorn重启。 我的前端实践经历了一些变化。我发现Alpine和HTMX对我来说限制太多，所以我更喜欢使用Typescript和django-vite集成。是的，这意味着要使用一些前端工具，但它意味着我可以使用TailwindCSS、React、Typescript…

> 始终选择非常无聊的技术。只用Python/Django/Postgres做所有事情。 该死，考虑使用Postgres之前要再想想。SQLite的可扩展性比大多数人想象的要好，特别是对于本地开发/启动隔离的CI实例。对于小型应用来说，它在生产环境中也往往足够好。

> 忘记Kubernetes，Redis 我同意你的观点，但对我来说，这两个技术在2025年已经变得很无聊了。它们非常可靠，有明确的使用场景，而且我们知道它们在哪些地方表现完美，也知道它们不应该被使用的地方，我们了解它们的陷阱，围绕它们的兴趣似乎在慢慢减弱。我个人非常欣赏这些技术，只是因为它们非常稳定，而且能很好地完成它们该做的事情。

几乎同意你的所有观点，但在我的Django项目中Celery还是很常见的。我不喜欢它的复杂性成本，但特别是当使用某些PaaS进行托管时，它通常是痛苦最少的选择。我总是开始时想着这次我不会用它，但随后通过HTTP调用触发的一堆任务就会遇到超时问题。这时候要么用线程，要么用cron jobs（在PaaS上很难处理），要么用Celery。你的做法是怎样的？

> 大多数应用程序不需要是单页应用，也不需要使用重型前端框架。即使对于那些能从中受益的应用，传统的Django视图对于80%的页面来说已经足够了。其余的可以考虑AlpineHJS/HTMX 这不就和“精通一个工具”相矛盾了吗？ 我写的每一页网页都用React，不是因为我认为每件事都需要是SPA，而是因为足够多的事情最终需要客户端状态，我需要一个能很好地管理它的工具，而这时干脆把所有事情都用React来做反而更容易，即使一开始看起来它可能太重了，就像你的例子一样。

> 忘记Celery 不用Celery你怎么处理后台任务？我曾经开发过的每个应用/网站都需要某种后台任务处理，对于Python我用Celery，Rails我用Sidekiq，Node.js我用Faktory。其中最大的缺点之一（至少直到不久前）是设置这个必须通过一个黑客式的webhook调用你的应用，允许最多N秒的请求/响应。

这很好，但它只适用于非常狭窄的编程问题。 你显然在开发中等规模的网络应用。例如，一旦后端服务达到一定规模，Kubernetes 和 Redis 可能突然变得几乎不可或缺。