En 2011 escribí sobre un framework web que prometía, en 2013 hice una charla sobre este mismo framework para presentarlo a la comunidad informática cordobesa, más tarde incluso lo emplee en desarrollos en un par de empresas, ¿por qué no triunfó ChicagoBoss?
Hay cientos de motivos que se me vienen a la cabeza cuando pienso en ChicagoBoss y los motivos por los que no triunfó. En este artículo quiero recoger cada uno de estos pensamientos para darles forma y confrontarlos con el porqué creo que Phoenix Framework sí que tuvo este éxito.
El lenguaje
Aunque cueste reconocerlo sí, Erlang fue una barrera de entrada. No conozco a ningún profesional que considere este lenguaje como ideal para el desarrollo de aplicaciones web. Se lleva intentando desde hace mucho tiempo, Zachari Kessin publicó en 2012 un libro para desarrollar con Yaws y no tuvo una gran acogida. Más tarde surgieron una gran cantidad de frameworks web entre los cuales ChicagoBoss se decantó como el más completo. Pero algo no funcionaba.
La mayoría de lenguajes sobre los que se desarrollaba web eran orientados a objetos y aunque en Ruby on Rails la orientación a objetos es circunstancial, es normal entender que un lenguaje 100% orientado a objetos finalmente tendrá algo orientado a objetos. De hecho, ActiveRecord realizaba un uso intenso de objetos para incrustar la información de las consultas dentro de estos objetos definidos a modo de tablas con la base de datos.
En resumen podríamos decir que a nadie le gustaba la sintáxis de Erlang lo suficiente para escribir código Erlang para interfaz web. Al menos, era la típica respuesta que yo recibía cada vez que intentaba vender la idea.
Acceso a Base de Datos
Además, el lenguaje fue la gran perdición de BossDB que nunca llegó a funcionar correctamente por querer funcionar de la misma forma que ActiveRecord o SQLAchemy. Su potencia era muy limitada y no llegaba a ayudar a los desarrolladores a realizar acciones de nivel medio, ni mucho menos avanzadas. Además, la dependencia de los módulos parametrizables (que fueron marcados como desfasados y eliminados en las versiones actuales de Erlang), dio un golpe muy negativo a la forma de trabajar que intentaba instaurar BossDB haciendo que finalmente la gente prefiriese otros enfoques.
A día de hoy, Erlang tiene algunos elementos para realizar consultas y acceso a base de datos como DBI que permite realizar consultas SQL conectando con MySQL, PostgreSQL o SQLite principalmente, o SumoDB el cual es una adaptación para Erlang de Ecto y emplea algunos trucos a través de parse transformations. Hay muchos trabajos realizados en este sentido pero no todos son mantenidos actualmente.
Realmente, nunca se pensó cómo Erlang debía implementar el acceso a base de datos sino que se intentó adaptar cómo otros lenguajes lo hacían. Esto llevó a sistemas que no terminaban convenciendo y se hacían muy tediosos e incómodos.
Plantillas
Aunque este si fue un punto muy potente en ChicagoBoss, el uso de ErlyDTL para la construcción de plantillas no terminó gustando a todos. Los profesionales llegados de Django lo veían muy cómodo pero el código a escribir en la plantilla era muy diferente al código que normalmente podíamos escribir en los controladores o para los modelos.
Muchos echaban de menos el inicio que había tenido lugar con Yaws a través de unas plantillas mucho más al estilo Erlang que esta nueva forma al estilo Django.
No obstante, huelga decir que el sistema de plantillas quizás fue la parte más potente del sistema consiguiendo velocidades de renderizado que ningún otro lenguaje o framework conseguían. Esto debido a que la plantilla era convertida a código en Erlang y compilada.
Puesta en Producción
Evans cometió un gran error al intentar equiparar ChicagoBoss con Django o Rails. Mientras que estos frameworks se basan en lenguajes interpretados y el código fuente es necesario tal cual para el despliegue, Erlang no funciona de esta forma. Es más, al momento de salir tampoco existía una forma de realizar liberaciones unificadas en la comunidad, por lo que era difícil especificar una forma de llevar a producción algo construido en ChicagoBoss.
Inestabilidad
Desgraciadamente, esto fue otro de los grandes problemas. El sistema no proveía tests para comprobar la correctitud de cada versión liberada. Incluso el sistema para realizar tests era defectuoso no permitiendo mantener una sesión a lo largo de un test completo.
Este tipo de problemas que iban surgiendo y generando correcciones continuas cada vez que se liberaba una nueva característica convertían al sistema no solo en problemático sino también en incómodo. Con cada nueva versión en la que aparecía una nueva característica, cabía esperar ciertas otras antiguas características rotas o funcionando de forma defectuosa hasta ser corregidas a posteriori.
La carencia de un sistema de tests para comprobar la correctitud del sistema desde el principio hizo que muchos no consideraran nunca ChicagoBoss como una solución preparada para la empresa, solo como un juguete.
Falta de Documentación
Sí, disponíamos de un documento en la web llamado Una tarde con ChicagoBoss donde su autor daba un recorrido práctico de cómo crear un blog. Si tus necesidades estaban alineadas a ese uso, perfecto, si necesitabas algo más completo o complejo entonces te las tenías que ver con el código. No había mucho más que pudiese ser leído además de una referencia bastante escueta de los modelos, controladores, rutas y poco más.
No hallar documentación suficiente hacía sentir a los que llegaban que el sistema no estaba preparado ni terminado.
Pérdida de Interés
Además, su creador cesó en su interés sobre ChicagoBoss y cedió el control del sistema completo a otros. Uno tras otro fueron pasando varios responsables hasta terminar en manos del creador de Nitrogen. El problema no fue que estas personas no tuviesen interés o no tuviesen calidad técnica para hacerse con el proyecto, sino más bien que la extensión del proyecto y las necesidades de este hicieron muy complejo llevarlo a un estado que pudiese considerarse como preparado para el nivel empresarial.
Hubo muchos momentos en los que ChicagoBoss parecía completamente muerto, de hecho su lista de correo donde circulaban las noticias de nuevas versiones, correcciones, peticiones de ayuda y comentarios sobre el proyecto llegó al más completo silencio durante esos días.
Llegada de Phoenix Framework
El auge de Elixir y Phoenix Framework realmente no ayudaron al proyecto. El nuevo lenguaje era mucho más parecido a otros como Ruby y prometía resolver los problemas que ChicagoBoss tenía:
- El lenguaje era ideal. Disponía de meta-programación y permitía construir DSL de forma fácil y sencilla.
- El acceso a base de datos quedó indiscutiblemente resuelto con Ecto.
- Las plantillas implementaban el propio Elixir a través de EEx lo cual lo hacía mucho más ideal. Además la creación de vistas y plantillas simplificaba la agregación de helpers y otros elementos en las plantillas.
-
La puesta en producción quedó resulta con mix. La herramienta de Elixir disponible desde su lanzamiento. Cualquier proyecto creado en Elixir dispone de un
mix.exs. - Además, el sistema fue lanzado desde primera hora con un sistema férreo de tests y todo el código dispone de su conjunto de tests a todos los niveles. Llego a ser enterprise-ready rápidamente.
- La cantidad de documentación en Phoenix es impresionante. Solo hay que echar un vistazo a su guía de referencia, sus guías, how-tos e incluso dispone ya de material más completo como un par de libros. Uno hablando en general de Phoenix y otro sobre Ecto (de momento).
- Por último, Phoenix fue desarrollado por una comunidad cansada de Rails, el interés fue su arma secreta.
Por estos motivos, Phoenix se impuso rápidamente como una buena solución mientras que ChicagoBoss se condenó finalmente a permanecer como un proyecto que intentó tomar un sitio en el desarrollo web para el mundo Erlang sin mucho éxito.
Conclusión
A mi parecer ChicagoBoss fue un proyecto muy interesante pero, tal y como dije la sensación que siempre me transmitió es está en desarrollo. Un proyecto que tenía muchas carencias y no apuntaba en la dirección correcta para ser enterprise-ready, lo que terminó de condenarlo al terreno de los toy-projects o para early adopters a los que no les importaba trabajar un poco más para adaptar e incluir nuevas liberaciones y realizar gran cantidad de pruebas para dar su feedback y ayudar a corregir su juguete. Yo fui uno de ellos y fue divertido, pero también fue un pequeño sufrimiento cada vez que surgía un problema por su escueta documentación. Finalmente había que ir a mirar el código.
¿Consideraste ChicagoBoss para algún proyecto? ¿Lo conociste antes de saber de Phoenix Framework? ¿Qué te pareció como framework? ¿Consideras que pueda tener un futuro? ¡Déjanos tus comentarios!
