Cuando escribí el libro Phoenix Framework: Red Social en 7 días me pregunté si valdría la pena incluir LiveView, en esos momentos se incluía por defecto con Phoenix Framework y me preguntaba si sería estable, no obstante, no consideré que fuera el momento, ¿lo es ahora?
He estado escribiendo un artículo sobre las novedades de Phoenix Framework 1.7 de la presentación de Chris McCord en la última ElixirConf US 2022, con respecto a LiveView mencionan los cambios y mejoras de la versión 0.18 y su futuro trabajo de realizar un cambio en su API para fusionarlo mejor con los componentes.
La lectura que me llevo es:
- Su número de versión dice aún 0.18, diciendo que no hay una versión 1.x disponible y por tanto que aún su forma puede cambiar mucho igual que lo hizo Phoenix antes de llegar a su versión 1.x.
- La inclinación a cambiar la API para mezclarse mejor con los componentes indica un claro deseo de cambio, ya sea en los componentes o en LiveView.
- Mirando hacia atrás, en las últimas 4 versiones su API ha cambiado mucho y cualquier desarrollo realizado con hace tres o cuatro versiones requiere una reescritura importante.
En resumen, LiveView es una tecnología estable, muchas empresas la están utilizando a día de hoy para ciertas áreas de sus desarrollos, pero implica una apuesta, una inversión. Estamos implementando una tecnología aún no estable ni madura y eso conlleva una necesidad no tan solo de invertir ahora en la implementación de esa tecnología, sino también a futuro para seguir implementando los cambios de las siguientes versiones hasta alcanzar una que mantenga la API más estable.
En el libro de Phoenix Framework que escribí en febrero de 2021, a fecha de hoy, tan solo el capítulo que habla sobre los assets y el capítulo indicando cómo instalar phx.gen quedaron desfasados, el resto del libro sigue siendo completamente válido y es estable. Esto es debido a la madurez de Phoenix y que su estructura básica empleada en el libro no ha cambiado, se ha mejorado cualitativamente pero no han surgido características que rompan la compatibilidad hacia atrás.
Por otro lado, desde la versión 0.15 las modificaciones no han sido muy drásticas y se esperamos no haya muchos más cambios en las siguientes versiones. De hecho, los cambios de API referidos en relación con la interoperatividad de los componentes esperamos que afecten única y principalmente a los componentes y no a LiveView.
Entonces, vamos a revisar un poco más en profundidad qué es LiveView para poder llegar a una conclusión.
¿Qué es LiveView?
Cuando Chris McCord dejó el mundo de Ruby on Rails y comenzó en Elixir para implementar algo que fuese similar a Rails y su nuevo elemento para comunicación por WebSocket conocido como [ActionCable], lo hizo por problemas de rendimiento en Ruby, cada vez más le pedían desarrollar SPAs (Single Page Application o Aplicaciones de una Única Página) y aunque el mercado se mueve a implementar sistemas cliente-servidor donde la aplicación cliente gestiona llamadas AJAX o HTTP simples cada cierto tiempo y el tan solo algunos casos mantienen abierto un canal de comunicación por WebSocket, McCord quería algo diferente.
Pensemos que con la llegada de Phoenix, muchas de las prácticas de otros lenguajes de servidor de acoger React, Angular, Elm y otras muchas soluciones para crear aplicaciones en el navegador para realizar peticiones al servidor se hacían posibles gracias a la implementación de los channels de Phoenix. Estos canales basados en OTP prometían ser escalables y así lo demostraron tanto Valim como McCord en una prueba en la que consiguieron (en tan solo una máquina) mantener 2 millones de usuarios conectados de forma simultánea.
Pero todo esto lo comento en los capítulos de introducción no solo del libro de Phoenix Framework sino también del libro sobre Elixir: Introducción para Alquimistas. Así que vayamos al grano.
Los canales evolucionaron a presencia, donde no solo se mantiene la conexión, sino también un estado. Información referente y relativa a la conexión. Esta presencia es útil para mantener información rápida y accesible según se pida desde el navegador. Por lo que LiveView no es más que otro paso más sobre esta presencia donde además de estado se dan las mecánicas necesarias para automatizar qué se debe mostrar, dibujar y redibujar cuando el estado cambia.
Es decir, cuando renderizamos una página, estamos enviando un texto HTML al navegador, pero cuando hacemos lo mismo con respecto a una página de LiveView, LiveView mantiene en un contenedor identificado todo ese trozo HTML y al mismo tiempo mantiene la forma de generar ese HTML de nuevo. Si algún dato se modifica en su estado, ese código HTML es procesado de nuevo y los cambios detectados son enviados al navegador y este los implementa en el HTML.
Este sencillo (aunque no simple) cambio rompe la necesidad de implementar un cliente de código en JavaScript, elimina la necesidad de emplear Vue, React, Angular, Elm o cualquier otro sistema para enriquecer la creación de código en el navegador y mantiene la lógica de la aplicación en un solo sitio.
En esencia: elimina la necesidad de escribir código JavaScript. Esa es la poderosa frase de márketing que ha facilitado la entrada de LiveView en las empresas y los equipos de desarrollo.
¿Y lo debería usar?
Como dije al principio, el hecho de no ser una versión 1.x crea la sensación de estar empleando un software experimental y los peligros de este tipo de software son:
- Puede desaparecer. Si no cumple sus objetivos es posible que se determine su no continuación. No valdría la pena utilizarlo. También puede pasar que el autor(es) pierda(n) la motivación inicial y entonces quede abandonado.
- Puede cambiar radicalmente. Si de repente obtienen una forma mejor de hacer lo que hace, teniendo en cuenta su fase experimental, no dudarían en eliminar parte de su API y cambiar radicalmente su forma de uso. Esto conllevaría un esfuerzo cada vez que suceda para reimplementar la nueva versión.
El primer caso no creo que se dé, han probado su utilidad y solo está evolucionando y cada vez está siendo adoptado por más y más usuarios. De hecho, este caso ha sucedido o está sucediendo para otros proyectos en Elixir pero no creo que suceda para LiveView. Un ejemplo de algunos de estos proyectos:
-
Coherence: fue abandonado hace tiempo, surgieron otras iniciativas como Pow pero incluso esta iniciativa está viendo su objetivo un poco difícil de cumplir debido a LiveView y a
phx.gen.auth. - Distillery: el último cambio en el código fue en 2019 y parece que aún habiendo problemas con OTP 25 aún no ha habido solución. Esto puede ser debido a la implementación en Elixir de las releases. La única ventaja de emplear Distillery frente a las releases de Elixir es que Distillery soporta la creación de releases con cambio en caliente (appup y relup) que no están incluidas en Elixir releases, y según Valim, no lo estarán porque es muy complejo y es una característica que no se usa.
Volviendo a la lista de peligros. El segundo mencionado ha pasado de hecho entre la versión 0.13 o 0.14 y 0.15 de LiveView. De hecho, me pasó. Estuve implementando una interfaz de gestión de contabilidad para mi empresa y usé LiveView 0.13 cuando un par de versiones salieron y me dejé llevar por el "mantente al día" (up-to-date!) e hice una actualización de dependencias para descubrir que nada funcionaba.
Tuve que reimplementar los módulos de LiveView porque todo cambió. Igualmente, en las últimas versiones y debido a los componentes se ha pasado de .leex a .heex. Este cambio en la extensión trae consigo un gran cambio en la forma de escribir el código HTML y obviamente también en la forma de tratarlo y las funcionalidades nuevas que proporciona, entre ellas la comprobación de la escritura correcta del HTML.
Conclusiones
Entonces, ¿lo debería usar ahora?
En estos momentos me siento como un corredor de bolsa o de apuestas. Es complejo. No parece que deba cambiar mucho más el sistema y debería estar próxima la salida de la versión 1.0, pero al igual que se ha anunciado la unificación de las APIs para los componentes y LiveView, podría darse el caso de que el equipo considere más fácil modificar la API de LiveView y conlleve cambios en el código para que todo funcione. Es decir, que una actualización rompa el funcionamiento de la web.
En mi caso te puedo decir que hago la apuesta. Quizás pierda tiempo de desarrollo y tenga que hacer una actualización de este post diciéndote que me equivoqué, pero de momento: apuesto a LiveView ahora.
¿Y tú? ¿Has realizado alguna apuesta de esta forma? ¿salió bien la apuesta o te arrepentiste? Yo he hecho muchas apuestas fallidas por tecnologías, si quieres que te cuente alguna o un artículo dedicado a eso, ¡déjame tu comentario!
