Lo que me encanta de Django
Django emerge como un framework web ampliamente admirado por su estabilidad, compatibilidad hacia atrás a largo plazo, ORM potente y funciones integradas como la interfaz de admin y una documentación sólida. Los comentaristas destacan cómo su evolución “aburrida” e incremental reduce la necesidad de reescrituras y lo hace adecuado para productos grandes y de larga vida, sin dejar de permitir salidas de escape hacia SQL en bruto, arquitecturas alternativas o servicios externos. Las críticas se centran en el ORM al estilo Active Record (y su propensión a consultas N+1), las limitaciones de async y rendimiento, la complejidad de despliegue frente a stacks serverless y las diferencias filosóficas frente a frameworks como Rails, FastAPI y Phoenix.
Sentimiento general
- Muchos comentaristas son muy positivos sobre Django: “bien diseñado”, “aburrido en el buen sentido” y productivo para aplicaciones pequeñas y grandes.
- Un tema recurrente es la estabilidad a largo plazo: proyectos de varios años e incluso de varias décadas actualizados a través de versiones mayores con roturas mínimas.
Puntos fuertes principales señalados
- Sin cambios dramáticos: la evolución lenta y cuidadosa es muy valorada frente a marcos que obligan a reescrituras.
- ORM + migraciones: ampliamente elogiados por su potencia y flexibilidad; pueden expresar SQL complejo y tienen salidas de escape a SQL en bruto.
- Admin: a menudo “vende” Django a los clientes y se reutiliza como back office interno o inspector de datos.
- Flexibilidad: se ve como opinativo pero no rígido; es fácil anular el comportamiento, personalizar el enrutamiento, usar Jinja2, conectar otros ORM o dividir responsabilidades con otros servicios (p. ej., APIs en Rust con Django para migraciones/admin).
- Ecosistema: DRF + OpenAPI + generadores TS, django-allauth, herramientas de un solo archivo y frontends en Rust como django-bolt reciben menciones destacadas.
Puntos de dolor y críticas
- ORM/ActiveRecord:
- Críticas: fomenta consultas “por todas partes”, problemas N+1 fáciles, cargas implícitas amplias, el patrón ActiveRecord no gusta a algunos; sintaxis como
field__gtey relaciones tipadas como cadenas se consideran feas / frágiles. - دفاعensas: los N+1 se pueden manejar con
select_related/prefetch_related, próximos modos de fetch y disciplina. Algunos ven las quejas como problemas de “habilidad/ajuste”.
- Críticas: fomenta consultas “por todas partes”, problemas N+1 fáciles, cargas implícitas amplias, el patrón ActiveRecord no gusta a algunos; sintaxis como
- Arquitectura y estructura de la app:
- Preocupaciones por el spaghetti derivado de consultas entre apps,
models.py/views.pyenormes y falta de capas de servicio claras. - Otros abogan por capas explícitas de servicio/selector, signals para desacoplar y apps centrales/aglutinadoras en forma de “estrella”. Los signals se ven como potentes pero arriesgados por sus efectos secundarios ocultos.
- Preocupaciones por el spaghetti derivado de consultas entre apps,
- Content Types: impresionantes, pero se advierte contra su uso para el mantenimiento a largo plazo.
Comparaciones con Rails y política
- Algunos prefieren Django frente a Rails por razones técnicas (menos “Rails Way”, más flexible).
- Un hilo lateral debate evitar Rails por las opiniones públicas de su creador; otros argumentan separar el software de la política del autor o señalan incoherencias en boicots selectivos.
Async, rendimiento, despliegue
- La historia de async y el rendimiento de alto throughput se citan como puntos más débiles; algunos se pasan a Go u otras pilas para eso.
- El despliegue se percibe más difícil que el de frontends estáticos o microservicios porque Django necesita un proceso de servidor 24/7.