Desde 1998 que venimos usando PHP ("Para Hacer Paginas" xD) para construir nuestros sitios. Pero lo cierto es que las cosas cambian y evolucionan: los sistemas comenzaron a hacerse en Java, .NET, y desde hace años (digamos unos 8, aunque bien marcadamente 5) Python.
PHP se hizo famoso por ser el primero y el más difundido. También el más fácil de instalar si tus necesidades son simples (un sitio, sin mas cosas dando vueltas). Además, con esto de los hosts virtuales (tanto para el HTTP como para el SMTP/POP), es por lejos más facil montar servicios de hosting compartido que con sistemas con Python o Java (cuyos mantenimientos requieren acceso a un usuario en servidor que no muchos hostings están dispuestos a proveer).
Pero PHP es molesto en sintaxis (en mi opinión), tardó mucho en ganar determinadas capacidades hoy presentes en PHP 5.3 y PHP 5.4, y tiene una comunidad con una mala cultura de programación en la que prácticamente nos enseñan a construir código que accede a bases de datos introduciendo cuanta inyección SQL se nos ocurra (¿quién no habrá visto esos tutoriales en PHP que componen un SQL para MySQL como "select * from employees where id = $id"?).
Es cierto que, con el tiempo, aparecieron muchisimos frameworks o CMS ("o" dije, porque por lo general nunca son lo mismo: un framework es una estructura marco para que puedas hacer un programa a tu medida, mientras que un sistema de administración de contenido está pensando para que puedas fácilmente administrar contenido sobre una base ya hecha) como los tres mosqueteros del PHP: Drupal, Joomla, Wordpress. Pero lo cierto es que tienen una curva de aprendizaje muy dura, e incluso al día de hoy tienen más fallas de seguridad que los frameworks modernos. Adicionalmente, manejar el cache es complicado (a mí se me hizo un infierno instalar el APC todas las veces, especialmente si hablamos de los casos en los que tuve que usar Windows). Tambien es cierto que los hostings de PHP comenzaron a regalar sus "1-Click installers" para desplegar rápido esos sistemas.
Al parecer el usuario tiene todo regalado ¿no?. Al parecer, PHP y su comunidad nos dan la sensación de que no necesitamos realmente de un programador (sino ya solamente de un diseñador web y especialistas en comunicación y medios digitales) ¿no?. Es decir ¿qué tan difícil puede ser? Incluso en la Casa Blanca (whitehouse.gov) hay un CMS atendiendo.
Todo eso es cierto PERO:
- Hay programadores y expertos de seguridad (muy buenos - imagínense que se tienen que aguantar hasta a hackers del ISIS o M.E.C.A.) tras el sitio de la Casa Blanca.
- Realmente si tu intención es "salirte del libreto" con uno de esos sistemas, programar es por lejos más difícil que en un framework WEB normal.
- El administrador trasero de esos frameworks es tan complejo para el usuario final que frecuentemente se necesitan expertos en Drupal, Joomla, y Wordpress solamente para utilizarlos.
Entonces ¿qué usar para desarrollar sitios?
En realidad depende lo que queremos. Mi consejo es no recurrir a balas de plata. Cada uno de ellos tiene su propia metodología y limitaciones, y siempre va a depender su idoneidad de lo que queramos desarrollar. Si querés un sitio WEB, te toca ponerte a desarrollar. Si querés presentar fotos, formularios de contacto, multimedia en cualquier formato, y sin procesamientos complejos entonces un CMS te sirve perfectamente. Y si querés comunicación en tiempo real, directamente deja de servirte el PHP en comparación a otras tecnologías.
¿Y dónde entra Python acá?
Realmente Python (así como Java y .NET) es una plataforma (Python 2, Python 3, en sus varias implementaciones existentes) para correr cualquier tipo de programa, mientras que PHP es, tradicionalmente, ejecutado DENTRO del contexto de una petición web (sí, ya se que me van a venir con winbinds y con el servidor interno que existe desde PHP 5.4, pero al menos este último es un chiste en cuanto a performance). Esta limitación hace que el diseño de los frameworks sea más molesto, y que cada petición tenga mucha carga en memoria, terminando el usuario obligado a usar APC o cualquier caché que encuentre).
Con el tiempo aparecieron dos frameworks muy usados (entre otros): Django y web2py. Ambos tienen un portal administrativo y, en particular web2py, hasta un editor de código y modelos (digamos que es su propio entorno de desarrollo).
Django corre sobre Python y se originó como un CMS (sus autores lo llamaban "El CMS" a priori, antes de darle nombre), pero evolucionó hasta convertirse en un framework.
En lo personal nunca usé web2py seriamente, por lo que no podría compararlos a priori. Pero sí puedo compararlos contra PHP y sus "soldados" y mostrando por qué es superior en todo sentido a la hora de desarrollar sitios desde cero.
Algunos frameworks sumamente complicados de PHP son Propel, Doctrine, y Simfony (aunque siguen en mantenimiento, la misma sociedad los va deprecando). Otros son más fáciles y con algunos asistentes, como Yii y Laravel. Al final quedan los CMS que ya mencionamos.
Instalar los tres primeros es un embole y se necesita que el servidor se encuentre configurado con librerías especiales. Instalar los del medio es más fácil. Instalar los CMS es, en general, extremadamente fácil. Sin embargo, a medida que se vuelven fáciles también se vuelven limitados o pesados en memoria. No digo que a priori deba ser así, que sea ley de vida, pero evidentemente la comunidad de PHP tiene un estilo de desarrollo en donde esto ocurre casi en la totalidad de los casos.
Python es más fácil en todo sentido, aunque requiere permisos de acceso a un shell que son más difíciles de obtener (razón por la cual aún hoy pocos servicios ofrecen python en sus planes básicos). Es un lenguaje poderoso y, generalmente, podemos levantar varios procesos en un servicio de python, por lo que podemos valernos de un sistema distribuido para hacer lo que necesitemos.
Django en particular succiona lo mejor de todos los mundos: Es más versátil que Laravel, Simfony, Doctrine, y Propel (y más fácil de manipular el sistema de ORM), más administrable que Yii, y más fácil de usar, desarrollar, acoplar, y "plantillar" que Drupal mismo (y más eficiente: los ganchos de drupal te comen la memoria).
¿Por quéser tan fanboy?
Aunque lo intento, por lo general no puedo elegir otra cosa para programar. Siempre que me enfrento a requerimientos que no sean cambiar una simple imagen sino rehacer todo un sitio, Django es mi opción (me vuelco a Laravel si estoy obligado a usar PHP).
Y es que logré hacer una aplicación para Facebook, con sus artes, administrable, con capacidad de descargar un excel, capacidad de mandar e-mails de contacto, y otros chiches por ahí tomándome un tiempo de entre uno y dos días completos de trabajo. Este proceso lo hice al menos seis veces, metiendo seis aplicaciones en dos cuentas de OpenShift.
Leí decir que "Django y Drupal son dos bestias diferentes que no se pueden comparar". Eso es cualquier mierda. Ambas terminan usándose para sitios similares (y en particular Django nació como un CMS), y tienen ventajas y desventajas.
Drupal:
- Instalarlo es fácil.
- Viene con algunas plantillas predeterminadas.
- Programar es más fácil. Desarrollar módulos ("aplicaciones") es increíblemente fácil.
- El administrador es más liviano (y en parte limitado) que el Drupal, pero altamente (y fácilmente) personalizable.
- Los aportes de la comunidad de Django son tan fuertes que fácilmente se pueden comparar a los aportes de la comunidad de Drupal y superarlos.
- Existen frameworks que nos ofrecen un CMS sobre Django (como django-cms y wagtail), que le ofrecen a Django las ventajas que tiene Drupal, pero mantienen la facilidad para programar que nos ofrece Django.
Django es mejor que Drupal y sus amigos. #DealWithIt.
La peor parte de esto es: realmente me gustaría que existan tecnologías así de cómodas en otros lenguajes (principalmente en PHP), pero por limitaciones del lenguaje o por cultura, es difícil lograr que aparezcan, y no tengo el tiempo para desarrollarme mi propio framework para que eso ocurra. Por lo que me sigo quedando con Django como preferencia (con Python como lenguaje, obvio).
Finalmente, todo esto se trata de gustos (aunque PHP con algun CMS o Framework es menos performante que Django), pero también se trata de que nosotros hagamos más cómodo nuestro trabajo, y en poco tiempo sacar algo que quede vivo y funcional, y no un feto a medio abortar o un homúnculo de Fullmetal Alchemist. Deberíamos ponernos a revisar qué es más fácil de mantener a largo plazo y, en particular, a mí Django se me hace mucho más fácil y más estable que los Drupals que tuve que mantener (que siempre me implicaban quejas de parte del hosting en relación a la seguridad y a la memoria o procesamiento que consumen).
Y para rematar, quisiera remarcar los me gusta y los no me gusta de Django, ya que lo justo es que exponga ambas cosas:
Me gusta:
- ORM fácil, super intuitivo, y poderoso.
- Administrador comparablemente fácil y poderoso (aún con sus falencias). Generalmente, este punto agrega un valor determinante a la hora de decidir usar Django como framework de desarrollo.
- Sistemas de plantillas bastante lindos. Desde 1.8, también se da soporte a sistemas más poderosos (y que nunca usé) como Jinja.
- Librerías de terceros bastante poderosas, como Django REST Framework ("djangorestframework"), ideal para desarrollar puntos REST.
- Migraciones! Desde 1.7, muy poderosas aunque aún pueden mejorar. En versiones anteriores se usaba la librería "django-south" para realizar migraciones.
- Una consola por lejos mejor que "drush" y que "artisan" (para Drupal y Laravel, respectivamente). Altamente personalizable (tanto o más que "artisan").
- Sistema muy cómodo de MVC (o algo similar), y direccionamiento y referenciamiento de URLs de manera "cómoda".
- Alta compatibilidad con las bases de datos más modernas (sí, también existe un soporte comunitario para Oracle).
- La documentación oficial es una de las mejores documentaciones oficiales que leí en mi vida.
- Buen soporte para agregar condiciones escritas con SQL puro.
- Se le reportaron pocas fallas de seguridad en relacion a los otros frameworks.
- Al ser basado en Python y orientado a proceso en lugar de a petición, se puede implementar un caché "tonto" para los entornos de desarrollo sin obligarles a instalar un Memdached, hasta la etapa de producción o staging. De la misma forma, se permite hacer una única carga pesada de todo el esquema de clases (cosa que sería peligrosamente pesada si se hiciera petición por petición), lo que permite hacer un ORM sumamente poderoso.
- Algunos factores de diseño, como en las claves foráneas, son estéticamente inconsistentes.
- En mi -no tan humilde- opinión, la comunidad parece ligeramente cerrada a cambios (aunque en realidad no me puse a compararla con las comunidades de otros frameworks).
- Las migraciones "rompen" en algunas bases de datos como PostgreSQL si hacen cambios "verticales" (es decir: alterando tabla y columnas) y "horizontales" (es decir: alterando datos) en una misma tabla. PostgreSQL arroja un error, y no existe un mecanismo de dar a optar al usuario si quiere ejecutar cada migración en una transacción, o todas en una única transacción.
- No tiene buen soporte para consultas como "select * from manager m where (select count(*) from employee where manager_id = m.id) > 5" mediante ORM sin recurrir a SQL puro.
- El esquema de URLs es muy pesado. Habría sido ideal si, durante la carga, hubieran creado un esquema de URLs que fuera "compilable" (una única vez durante la carga del servidor), en lugar de obligar a cada petición a recorrer el complejo esquema de URLs, que es medio pesado (poderoso pero pesado).
- De cuando en cuando es difícil obtener la petición actual, especialmente para propósitos de validación (ejemplo: yo mismo hice un componente en donde, para validar un campo, necesito acceder a la petición actualmente ejecutada), en contraste con otros frameworks como Flask.
- Al ser WSGI es síncrono (esta desventaja la comparten todas las aplicaciones WSGI) y, aunque gunicorn (aplicación útil para desplegar cualquier cosa que sea WSGI) tiene un soporte para cosa asíncronas, no es lo más canónico y no siempre funciona bien. Determinadas aplicaciones no pueden realizarse, como chats o juegos en tiempo real, sin recurrir al long-polling o a soluciones algo inestables. Termino integrando otros frameworks como Tornado para esas tareas.
Espero que con este post hayas aprendido en qué sentido vale la pena relativizar una elección y en qué sentido no. Para los djangueros frecuentemente nos es dificil soltar Django, pero es útil que veamos también las desventajas y ver que soluciones podemos integrar. Cada vez más hostings están soportando Python, con un cómodo shell para usuarios (y cada vez son más baratos los VPS), por lo que implementar soluciones integradas es más fácil y no estamos obligados a atarnos a una bestia monolítica como suele ocurrir con PHP. Vale la pena que nos modernicemos y le demos oportunidades a muchas tecnologías para poder compararlas y elegir la mejor para nuestras necesidades, sin andar atándonos completamente a supuestas "modas" que nos impone el mercado. Lo importante no es poder elegir, sino saber elegir, y creo que eso siempre lo debemos tener en cuenta para el desarrollo, por mucho que nos guste una tecnología. Es importante elegir adecuadamente en relación a la plataforma y capacidades disponibles, pero también en relación a los recursos humanos y su productividad.
Tengo la esperanza de que, con el tiempo, más servicios de hosting van a soportar Python (hoy ya son muchos, igual), y más gente se va a introducir a este mundo de una manera no tan críptica sino más concentrada en el aspecto humano (y sus necesidades) de nuestra actividad.
