Django and Postgres for the Busy Rails Developer

Original Article ↗ Hacker News Discussion ↗

Rails and Django developers weigh the trade-offs of moving from Ruby on Rails to Django with PostgreSQL, contrasting Django’s batteries‑included approach (notably its admin, GeoDjango, and Python’s data/ML ecosystem) with Rails’ stronger defaults, cohesive conventions, and tools like Hotwire. Critics of Django point to its templating language, ORM verbosity, migration system, and inconsistent project structure, while defenders argue its explicit patterns, extensibility, and replaceable components (e.g., alternative ORMs or template engines) remain powerful for many workloads. Hiring considerations also surface: Python’s broader adoption and talent pool make Django attractive for organizations, even when individual developers prefer Rails’ ergonomics.

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.