historical - django-reversion

Historia de la popularidad de Django (9)

"Mi favorito personal, y espero que eso siga siendo un favorito por mucho tiempo, es algo llamado Django" - Guido Van Rossum en el episodio semanal 11 de FLOSS, emitido el 4 de agosto de 2006

[Haga clic aquí] (escuche el último tercio de la entrevista)

¿Crees que esto podría haber ayudado? ¿o al menos la razón por la cual Google lo eligió para App Engine?

por supuesto, la comunidad django (incluidos los desarrolladores) está haciendo muchas cosas bien. Por ejemplo (Algunos análisis en los enlaces):

Mejorando la modularidad: [Haga clic aquí]

patear la documentación del culo Haga clic aquí

También hay algo en la comunidad que hace que las personas quieran contribuir, algo que todavía tengo que decir: haga clic aquí.

Por supuesto, todo eso lleva a que Django sea un valor atípico: haga clic aquí

No hay dudas sobre la popularidad de Django.

¿Qué secuencia de eventos convirtió a Django en el framework web más popular de Python ... y aún así? A pesar de que existen muchos otros marcos.

Nota : Esta pregunta no es argumentativa ni confrontativa . Simplemente pedí (objetivo) "la secuencia de eventos" que conducen a su popularidad real. Al estar consciente de la dinámica de la aceptación del software , no pretendo que nadie se meta en discusiones sobre superioridad técnica.

Al menos para mí, un factor importante fue que Simon Willison y Adrian Holovaty ya eran jugadores conocidos en la escena de "estándares web", así como Jeff Croft más tarde.

Eso no solo era un sello de calidad, sino que también hacía que Django fuera muy amigable con la web, con su respeto por HTTP, marcado e incluso la manera rápida y sucia de "depurar las impresiones" a la que las personas provenientes de PHP estaban acostumbradas.

Podría estar muy equivocado aquí, sin datos para respaldar esto, pero siento que Django ganó mucha más tracción de las personas provenientes de PHP, a diferencia de Rails, que obtuvo una gran cantidad de conversiones de Java / .NET.

Como ya se señaló, la documentación está muy por encima de la media. Lo mejor que he visto, por lo que recuerdo.

Creo que hubo algunos factores, la combinación de los cuales fue mayor que la suma de sus pesos individuales.

Una es simplemente la sincronización: Django apareció justo cuando la primera gran ola de la exageración de Rails estaba aumentando, y por eso fue retratada inmediatamente como una especie de "respuesta de Python a Rails". Eso resultó en un número no despreciable de globos oculares en el proyecto casi desde el principio. El hecho de que Adrián estuvo en la reunión de "Snakes and Rubies" en Chicago y participó en las conversaciones paralelas sobre Rails y Django hizo mucho por eso.

Otro factor es que Django es y siempre ha sido una instalación de paquete único (bueno, no del todo: todavía necesitas un adaptador de base de datos, a menos que estés en Python 2.5+ y usando SQLite, pero lo suficientemente cerca). Las alternativas que no son Zope, todas enfocadas en dejar las opciones de componentes en manos del desarrollador, requirieron bastante más trabajo solo para llegar al punto en que pudieras hacer un tutorial básico: tendrías que buscar un ORM, un lenguaje de plantilla, etc., etc. y conseguir que todos estén instalados y configurados. Aunque ha mejorado mucho con los años, creo que el recuerdo persistente de eso todavía tiene un efecto.

Y Django salió de la puerta con documentación que (si me permite decirlo) fue muy superior al estándar habitual para proyectos de código abierto, y solo ha mejorado con el tiempo. El tutorial, con todas sus fallas, coincide con varios puntos importantes que hacen que Django sea útil, y el resto de la documentación siempre ha sido de buena calidad, mezclando referencias de API e importantes "cómo", según sea necesario. Esto produce una buena experiencia lista para usar y ayuda con la curva de aprendizaje post-tutorial (algo que siempre ha plagado a Zope).

También creo que hay una percepción, con razón o sin ella, de que, por ejemplo, Pylons o Werkzeug son mejores para los desarrolladores experimentados que ya conocen su camino alrededor de WSGI y el ecosistema web de Python; el hecho de que tienden a ser opciones fuertes para tomar sus bibliotecas favoritas existentes y conectarlas juntas es la fuente de esto, creo, y tal vez empuja a algunas personas más nuevas hacia el enfoque integrado de Django. La otra cara, por supuesto, es que muchas personas que estarían mejor aprendiendo más por adelantado antes de intentar con Django no hacen eso;)

Finalmente, creo que hay algo que decir sobre la forma en que Django se ha comercializado, lo que quiere decir que realmente no se comercializó durante mucho tiempo, o al menos no en el sentido de que, digamos, se comercializó Rails. Hasta que Django 1.0 aterrizó, el esfuerzo de "marketing" consistía principalmente en blogs de personas (y hubo algunos incidentes notables donde se les pidió a las personas bajar el tono un poco), habla en PyCon y luego simplemente mejora el marco, creando cosas geniales con él y dejar que los resultados hablen por sí mismos. Ahora, por supuesto, en el mundo posterior a la versión 1.0, DSF y DjangoCon y los consultores orientados a los negocios realizan sesiones de capacitación, muchos libros y todo lo demás, pero eso todavía es bastante nuevo.

Espero que haya una reacción violenta, tal como ha sucedido con Rails, y de hecho creo que ha estado gestando por un tiempo y ya ha comenzado. Pero hasta ahora creo que los factores que he enumerado aquí son al menos los más importantes detrás del constante y constante crecimiento en popularidad que Django ha visto desde su lanzamiento inicial.

El hecho de que haya varios sitios de alto volumen que ya usan Django (es decir, lawrence.com, etc.), incluso en los 0,96 días, me ayudó a convencer a la gerencia de que era seguro de usar. Cosas como Pylons y Turbogears realmente no tenían eso.

En cuanto a la popularidad de Django en el tiempo (el significado literal del título de su pregunta, si no es exactamente su pregunta real), eche un vistazo a la tendencia de Google .

En mi caso, compré el libro de TurboGears, y luché a través de sus inconsistencias y su ruta al azar para explicar las cosas. Luego conseguí el libro de Django y ¡voilá! Mi primer proyecto de pago se creó mientras trabajaba en el proyecto de muestra del libro. Eso más la documentación en línea selló el trato. Para mí, fue simple: documentación, documentación, documentación.

Muchos frameworks web de Python ya existían cuando apareció Django en 2005; de hecho, la broma ya estaba dando vueltas, para entonces, que Python es "el lenguaje con más frameworks web que palabras clave" (y Guido rechazó mi propuesta de arreglar eso en Py3k agregando muchas, muchas más palabras clave). Ahora "django" per se es un poco ambiguo como término de búsqueda (también es el nombre de un guitarrista popular cuya vida inspiró una película de Woody Allen, etc.), sin embargo, agregó "pitón" a la búsqueda para eliminar esos otros significados se puede ver, por ejemplo, en este gráfico cómo cambió su popularidad relativa en comparación con otro marco web clásico de Python, Zope. En su mayor parte, crecimiento estable trimestre a trimestre, con un gran salto sorprendente al inicio del segundo trimestre de 2008 ... que coincide con la fecha en que Google anunció App Engine (es imposible probar la causalidad en tal caso, pero la coincidencia es al menos interesante ;-).

App Engine básicamente descarta cualquier estructura web de Python que dependa en gran medida de componentes codificados con C personalizados, o intrínsecamente requiere una funcionalidad "fuertemente relacional"; de aquellos que funcionan bien con el código puro de Python, Django es probablemente el que App Engine más directamente y visiblemente admite. Sin embargo, esto fue solo un impulso, lo que se sumó a la tendencia de crecimiento saludable subyacente de Django. La explicación de esa tendencia (y de hecho para el equipo de App Engine y la decisión de los usuarios de apoyar a Django tan bien) debe residir en las características que son intrínsecas a Django.

Django a veces es criticado (incluso por ... el tuyo verdaderamente ;-) por ser "demasiado mágico" o "demasiado monolítico", en comparación con alternativas como Pilones, TurboGears, Werkzeug, etc., que son más livianos (especialmente el último). , mi favorito ;-), más transparente, y permite un intercambio más fácil dentro y fuera de componentes específicos (ORM, plantillas, etc.). Sin embargo, la popularidad de Django nos dice que, para la mayoría de las personas interesadas en desarrollar aplicaciones y sitios web del lado del servidor, estas opciones de diseño de Django se perciben positivamente: Django es visto como un marco muy rico y bien integrado (y tiene mucho ons y contribuyeron con "complementos", pero esos son más una consecuencia que una causa de su ascendencia).

Facilidad para comenzar, "páginas de administración" automáticas, y similares, así como el hecho de que Django puede inclinarse a hacer sitios / aplicaciones realmente ricos y complejos y satisfacer requisitos peculiares o únicos, con mucha habilidad y algo de trabajo, son probablemente las "características asesinas". Para utilizar Werkzeug en su mejor aspecto, debe comprender HTTP y WSGI, y seleccionar e integrar su almacenamiento y plantillas favoritas: desarrolladores de sitios web y aplicaciones basados en Python (como, en cierto sentido, usuarios de Rails o usuarios de ¡PHP aún más popular! -) están "votando con su capacidad mental" para un entorno en el que no necesariamente tienen que hacer nada de eso, pero pueden enfocarse principalmente en su dominio de aplicación. Tendré que admitir que probablemente tienen un punto ;-).

Noté que a menudo se promocionaba como el equivalente de Ruby on Rails en Python. También tiene una conexión con Google (Google aloja eventos de Django y lo admite en su App Engine). Un marco web avalado por Google tiene que representar algo. :)

Puedo pensar en tres razones para la popularidad de Django, solo una de las cuales se ha abordado en otras respuestas por lo que veo:

Documentación. Está bien estructurado, es completo y se puede acceder desde varios niveles de habilidad.
Diseño. El diseño visual del administrador, las páginas de error y el sitio del proyecto están muy por encima del nivel de diseño visto con la mayoría de los proyectos de código abierto.
Soporte comunitario. Comenzando con el equipo en World Online, Django recogió algunos evangelistas influyentes desde el principio. No estoy seguro de que pueda exagerar la importancia de las publicaciones de blog como Django de Jeff Croft para no desarrolladores (creo que ese era el título).