¿Por qué Laravel?

Nota: este es un artículo técnico.

Después de presentar Monica en Hacker News, recibí muchas preguntas sobre por qué había escrito la herramienta con PHP y con Laravel en particular. Me sorprendió recibir tantas preguntas sobre el tema, porque considero que el lenguaje no importa: solo cuenta lo que haces con él.

En este artículo explicaré por qué elegí PHP y Laravel y qué dificultades tuve que superar para construir la primera versión del producto. Este texto no pretende iniciar una guerra entre lenguajes.

PHP tiene una historia interesante. Muchos grandes desarrolladores web, que probablemente ya no usan PHP, aprendieron con él las bases de la programación. Era sencillísimo de usar y de empezar y, aunque no era un lenguaje elegante, abrió el camino a muchas carreras en desarrollo web. Con el tiempo PHP fue perdiendo cariño, hasta el punto de que casi daba vergüenza usarlo o incluso decir en un meetup que tu empresa lo utilizaba. Otros lenguajes, sin duda más elegantes, ganaron mucha popularidad (Python, Ruby) gracias a frameworks estupendos construidos sobre ellos. Al mismo tiempo aparecieron nuevos frameworks PHP. Symfony, por ejemplo. Pero Symfony seguía siendo difícil de aprender y de usar. Y entonces PHP murió. O eso decía la gente, ignorando al parecer que muchísimas empresas seguían usándolo y disfrutándolo. Después llegó PHP 5.5, seguido de PHP 7, y apareció un framework con un nombre raro: Laravel. Y la mentalidad cambió por completo. PHP sigue sin ser tan elegante como otros lenguajes populares, pero las cosas mejoraron mucho. Además se volvió rápido.

Aun así, PHP sigue siendo el lenguaje que la gente adora odiar, sobre todo en Hacker News. Dicen que PHP no escala. Probablemente por eso Facebook y Mailchimp, entre otros grandes nombres, usan PHP hoy, y a gran escala.

Con ese contexto en mente, ¿por qué elegí PHP y Laravel?

• PHP es sencillo de aprender y sencillo de usar.
• Hay muchísimos desarrolladores de PHP y, si alguien quiere trabajar conmigo en el proyecto, el grupo potencial de desarrolladores de PHP es mayor, al menos donde yo vivo, que el de desarrolladores de Ruby o Python. Además, hay mucha gente en GitHub que usa PHP y, si quería que este proyecto de código abierto tuviera recorrido, tenía que escribirlo en un lenguaje en el que personas con niveles muy distintos pudieran contribuir con facilidad.
• Lo más importante al elegir una pila tecnológica para un proyecto nuevo es lo fácil que será mantenerlo a largo plazo. PHP es simple. Es fácil de depurar (aunque podría serlo más) y fácil de escalar (aunque ahora mismo no es mi preocupación en absoluto).
• Laravel es con diferencia el mejor framework PHP que he usado. Hace que las cosas complejas resulten muy sencillas. Se nota que se creó para arrancar aplicaciones web muy rápido y es un verdadero placer usarlo. Pero su gran diferencia es la calidad de la documentación, comparada con otros frameworks PHP e incluso con muchos frameworks de otros lenguajes. Todo está documentado de forma excelente. No puedo insistir lo suficiente en lo importante que es una buena documentación (lo que me recuerda que debería documentar Monica todavía más).
• Hay una enorme comunidad alrededor de PHP y de Laravel en particular: Laracasts, Forge, Envoyer y una comunidad de Slack muy activa, por citar solo algunos. Si necesitas ayuda, hay mucha gente dispuesta a echarte una mano.

¿Qué retos me encontré durante el desarrollo del proyecto?

En general no tuve demasiados retos al desarrollar la versión actual de Monica. No es una aplicación compleja y no tengo problemas de escalado, ya que la base de usuarios sigue siendo pequeña (unos 7800 usuarios en total y 4300 activos). Pero hay detalles de implementación que hice mal, no por mala práctica, sino porque mis conocimientos técnicos no daban para resolver esos problemas a corto plazo. Espero que enumerar esos errores ayude a otros a no cometerlos, o que gente amable me escriba para contarme cómo podría haberlos arreglado.

• En versiones anteriores usaba muchos eventos y listeners. El concepto es estupendo, pero por su culpa tuve muchos problemas para hacer pruebas unitarias de las clases base. Además, cuanto más los usaba, más magia ocurría entre bastidores. Pensé que quien entrara en el código tendría dificultades para entender por qué pasaban ciertas cosas al crear un objeto, por ejemplo. En mi cabeza, los eventos y los listeners hacían la aplicación más difícil de entender, así que decidí quitarlos todos (bueno, el 99 %, todavía quedan dos listeners de los que tengo que deshacerme).
• Al principio la base de datos estaba cifrada por completo. Por razones que todavía no entiendo, de vez en cuando había errores en el descifrado que dejaban datos que no podía recuperar. Como no quería lidiar con ese problema en esa etapa, decidí quitar el cifrado. Además, tener los datos cifrados hacía imposible cualquier ordenación o búsqueda en mis consultas, lo que habría sido problemático a la larga. Seguro que hay soluciones para ambos problemas, pero quería centrarme en crear funcionalidades nuevas en lugar de arreglar ese único asunto.
• No escribí pruebas unitarias antes de lanzar la aplicación. Eso me dolió de verdad. No creo que haya que aspirar al 100 % de cobertura, pero al menos hay que tener alguna prueba de las funcionalidades principales de tu sitio. Si no, acabas con un montón de errores en los que no habías pensado y, mientras intentas arreglarlos, tu solución afecta a otras partes de la aplicación. Eso se convierte rápidamente en una pesadilla. Laravel hace que las pruebas unitarias sean muy fáciles: debería habérmelo tomado más en serio. A partir de la próxima versión, no se fusionará ninguna pull request si no trae pruebas unitarias y quizá incluso funcionales.

Conclusión

Estas son algunas razones por las que elegí Laravel. Como decía al principio, tu proyecto no va del lenguaje. A menos que tu proyecto consista precisamente en aprender un lenguaje nuevo, no deberías pasar semanas eligiendo lenguaje o framework. Quédate con lo que conoces y construye algo. A tus usuarios no les importa que tu código sea feo o que hayas elegido Python en lugar de Ruby.