My takeaways from DjangoCon EU 2025

Original Article ↗ Hacker News Discussion ↗

Django’s Ongoing Popularity and Use Cases

  • Many commenters say they still choose Django for new projects, especially “website-like” products (e‑commerce, CRUD apps, back-office tools) rather than highly interactive “web apps” (e.g., Photoshop-in-browser).
  • It’s often picked when there’s a single main database (commonly PostgreSQL) and the app benefits from migrations, forms, templates, and auth out of the box.
  • Some orgs are moving new, larger services away from Python/Django toward C#, Go, or TypeScript for stronger typing and performance, but still using Django where it fits well.

Comparisons with Other Frameworks and Stacks

  • Django is framed as one of the best “batteries-included” frameworks, with Ruby on Rails mentioned as a peer.
  • For pure APIs, several prefer FastAPI (+ Pydantic) or Django Ninja over Django REST Framework.
  • SQLAlchemy vs Django ORM:
    • Pro-Django side: ORM is easier, cleaner, less verbose; great for CRUD.
    • Pro-SQLAlchemy side: more powerful, truly object‑relational, better for complex domain modeling but more ceremony (sessions, unit of work).

Strengths and Weaknesses of Django/Python

  • Strengths: stability over time, abundant developers, rapid development, excellent admin, strong ecosystem, minimal “framework churn.”
  • Django admin is strongly defended as a huge productivity win, especially for internal/backoffice CRUD. Some think it’s underused or prematurely discarded.
  • Weaknesses cited for Python: messy imports, mutation surprises, runtime slowness vs Go/Rust, and an imperfect typing story (mypy rough edges).

htmx and Frontend Approach

  • Django + htmx (sometimes with Alpine.js) is praised as a simple, cohesive full-stack pattern vs split frontends (React/Next.js).
  • Seen as easier to reason about, more durable for long-lived or side projects.
  • Some warn that partial updates via htmx introduce tricky UI edge cases and can require heavier end-to-end testing (e.g., Playwright) compared to classic full-page reloads.

Primary Key Debate: BIGINT vs UUID

  • One camp: always use BIGINT; UUIDs double key size, bloat indexes, hurt performance at large scale, and are harder to debug by hand.
  • Another camp: UUIDs (especially v7) are a safe default; the overhead is rarely the bottleneck, and local ID generation greatly simplifies distributed systems and long-running “business transactions.”
  • Nuanced views:
    • Use BIGINT internally and UUIDs as external/natural IDs.
    • Don’t blindly default to BIGINT; think about table cardinality and growth, but also avoid running out of INT range.
    • Several note real-world pain both from switching INT→BIGINT late and from poorly performing UUID-heavy schemas.