Django and Postgres for the Busy Rails Developer

Original Article ↗ Hacker News Discussion ↗

Project and models structure in Django

  • Concern raised about the article implying all models live in a single models.py; several posters say that’s only for small apps.
  • Common patterns: multiple apps each with their own models.py, or a models/ package with one model per file and an __init__.py “barrel” that re-exports them.
  • Some see Django’s app vs project distinction as confusing; others simplify by putting everything in a single “core” app.

Django vs Rails: developer experience

  • Multiple commenters strongly prefer Rails, citing:
    • Better defaults, scaffolding, deployment story (Capistrano), and Hotwire/Turbo integration.
    • More consistent project structure, making it easier to move between codebases.
  • Others prefer Django/Python, emphasizing:
    • Batteries-included approach, especially the built-in admin.
    • Ability to swap components (templating engine, DB, management commands).
  • Some argue big projects in any framework get messy; others insist language/framework choice heavily affects how long they stay manageable.

Templating and front-end approaches

  • Django’s template language is heavily criticized as slow, restrictive, and dated; some want something closer to ERB/React or LiveView/Blazor.
  • Others defend it as intentionally limited for safety and separation of concerns, while acknowledging it’s overkill for simple logic.
  • Alternatives mentioned: Jinja2, Python-based HTML builders (htpy, htmy), React-based server-side rendering for Django, Hotwire/Stimulus with Django, PEP 750 proposals for “native” templating.

ORMs and querying

  • Rails’ ActiveRecord is widely praised as the most natural and productive; several find Django ORM and SQLAlchemy more verbose or awkward.
  • Counterpoint: many Python devs strongly like Django ORM; some call it a “work of art” and main reason to use Django.
  • Debate over readability of Django’s double-underscore joins vs nested data structures, and over unit-of-work capabilities (SQLAlchemy praised; Django seen as per-object).
  • Discussion of architectural patterns: ActiveRecord vs data mapper, domain logic entangled with persistence, N+1 query risk in Rails, and the value of keeping business logic separate from the ORM.

Migrations and schema management in Django

  • Django migrations are a major pain point for some:
    • Not-null-by-default plus Python-level default vs SQL db_default can cause deployment-time crashes.
    • on_delete and some defaults enforced in Python rather than as DB constraints surprise people.
    • Auto-generated AlterField SQL can be slow or dangerous (dropping/recreating constraints, undoing manual tweaks).
    • makemigrations historically created noisy, no-op migrations (partly improved in newer versions).
  • A few advocate hand-written SQL migrations only, or careful use of RunSQL and SeparateDatabaseAndState.

Ecosystem, hiring, and language choice

  • Python is seen as more broadly useful beyond web (ML/AI, data science), giving Django higher perceived ROI for some.
  • Others argue framework learning dominates language learning; switching between Ruby and Python later isn’t hard.
  • Several note it’s much easier to hire experienced Python devs than Ruby devs. Ruby is described as delightful but more “clever”; Python as “boring” but large and pragmatic.

Use cases and ecosystem strengths

  • Django + GeoDjango + PostGIS + Python geospatial libs (GDAL, shapely, etc.) are praised as uniquely strong for GIS-heavy stacks.
  • Django is also favored for internal tools and data-heavy apps where Python’s scientific ecosystem matters.
  • Rails is preferred for fast-moving, customer-facing products needing rich interactivity (Hotwire, Turbo, strong scaffolding).
  • Some dislike Django so much they recommend composing Flask/SQLAlchemy/Jinja2 instead; others who’ve inherited Flask systems trying to match Django’s “full stack” regret that choice.