Some more things about Django I've been enjoying

The loudest reaction was to the author’s benchmark numbers. The post said a small site on a cheap VM handled only a few requests per second before caching and about 12 requests per second after template caching. Almost nobody treated that as a meaningful Django result. The consensus was that those numbers point to setup issues, not framework limits. People called out likely culprits like using the development server, serving static files through Django, weak VM performance, missing reverse proxy caching, or simply measuring with `ab -c 1`, which reports single-request latency more than realistic concurrent load. The punchline was simple: 12 requests per second at concurrency 1 is about 83 milliseconds per request, which is ordinary for a dynamic page and not evidence that Django is inherently slow. A second theme was architecture fit. People were unusually bullish on synchronous Django for ordinary line-of-business apps. The case was not that sync is universally better. It was that Python’s async stack is easy to misuse in ways that only blow up under production load, from unbounded queues and accidental blocking calls to leaked tasks and cancellation bugs. For CRUD-heavy apps behind a reverse proxy and worker pool, synchronous Django was framed as easier to reason about and easier to keep alive when things go sideways. The more specialized Django advice came from people running large systems. The strongest practical warning was about Django “apps” as boundaries inside a big monolith. Once foreign keys cross app lines, migrations become tightly coupled, hard to squash, and expensive in CI. Several experienced users said a single core app with normal Python modules is often cleaner than splitting one product into many Django apps too early. The same commenters still praised Django’s migration system itself. Their complaint was about project structure, not the tooling. There was also a smaller but useful thread on templates. Django’s built-in template language still frustrates people who want richer expressions, slots, or more reusable component patterns. The defense was that those limits are often a useful forcing function that pushes nontrivial logic back into Python, where it is easier to test and optimize. For teams that want a more capable template language, Jinja2 was described as practical in Django, though not truly drop-in once you account for tag differences, test behavior, and third-party package support.