- Phoenix LiveView ofrece alta eficiencia tanto en velocidad de la aplicación como en velocidad de desarrollo
- Una ventaja es que permite resolver todo de forma monolítica con un solo lenguaje, sin necesidad de mantener el frontend y el backend por separado
- También se consideraron Rails Hotwire y Laravel Livewire, pero para implementar funciones en tiempo real y trabajos en segundo plano requieren más configuración
- El framework Phoenix de Elixir conserva la elegancia de Ruby on Rails, pero ofrece un rendimiento muy superior, incluye trabajos en segundo plano con Oban de forma nativa y admite una sintaxis familiar y limpia
- LiveView ofrece actualizaciones bidireccionales en tiempo real basadas en WebSocket, logra un equilibrio entre el renderizado tradicional del servidor y los frameworks centrados en frontend, y cuando hace falta permite usar Alpine.js o librerías de JavaScript mediante hooks
- Factores decisivos en la elección final: velocidad de desarrollo rápida, alta capacidad de concurrencia, posibilidad de escribir casi todo en un solo lenguaje, prevención anticipada de bugs mediante el compilador y una arquitectura tolerante a fallos basada en Elixir/Erlang
Por qué elegí Phoenix LiveView
- El objetivo de programar es resolver problemas de la manera más óptima posible, y para mí los factores más importantes son la velocidad de la aplicación y la eficiencia de desarrollo
- Si usas React o Next.js junto con Laravel, o Inertia.js con Laravel, tienes que mantener ambos stacks, frontend y backend
- Como desarrollador en solitario, no tenía tiempo para gestionar el estado en dos lugares distintos, y necesitaba una solución monolítica sólida que pudiera manejarlo todo en conjunto
-
Comparación de alternativas: Laravel Livewire, Rails Hotwire, Next.js
- Laravel Livewire y Rails Hotwire son herramientas excelentes para simplificar el trabajo de frontend sin depender mucho de JavaScript
- Consideré un stack completamente JavaScript con Next.js, pero no prefiero usar JavaScript en el backend
- Rails Hotwire llamó especialmente la atención por su capacidad para construir rápidamente un MVP con Rails
- Sin embargo, necesitaba trabajos en segundo plano, actualizaciones en tiempo real y comunicación bidireccional; esto también es posible en Rails y Laravel, pero requiere más esfuerzo de configuración
-
Ventajas decisivas de Elixir, Phoenix y LiveView
- Elixir y Phoenix conservan la elegancia de Ruby on Rails, pero ofrecen un rendimiento mucho mayor
- Sus puntos fuertes son los jobs en segundo plano integrados mediante Oban, una sintaxis familiar y legible, y la comunicación bidireccional en tiempo real de LiveView
- LiveView logra un equilibrio ideal entre el renderizado del servidor y los frameworks pesados de frontend
- Permite actualizaciones en tiempo real mediante WebSocket e integración con librerías de JavaScript (por ejemplo, Alpine.js)
- Phoenix facilita la declaración de jobs en segundo plano y la recuperación automática gracias a la integración de Oban
-
Ventajas de Elixir/Erlang
- Elixir es un lenguaje compilado construido sobre Erlang, base de sistemas de alta concurrencia a gran escala como WhatsApp y Discord
- Ofrece alta concurrencia, tolerancia a fallos y recuperación automática ante errores
Razones de la elección final
- Desarrollo rápido y alto soporte de concurrencia
- Posibilidad de implementar casi todo con un solo lenguaje
- Escritura de código legible
- El compilador detecta la mayoría de los bugs antes de que lleguen a producción
- Una arquitectura tolerante a fallos hace que la app casi nunca se caiga y garantiza la estabilidad de la aplicación
Conclusión y consejo
- Phoenix no es automáticamente superior a Rails, Laravel o Next.js
- Todos los frameworks son excelentes, y he tenido experiencia usándolos en distintos proyectos
- Para mi situación específica y mi proyecto (Hyperzoned.com), Phoenix fue la mejor opción
- Si intentas explorar más allá de lo que ya conoces, puedes encontrar una forma mejor y más eficiente de resolver tu próximo problema
- No dejes de aprender
3 comentarios
Por la misma razón que JSP, siento que una vez que supera cierto nivel deja de ser usable.
Comentarios en Hacker News
He integrado CKEditor personalmente con Rails, Livewire, Phoenix y React. De todos, Phoenix fue el que más me impresionó en cuanto a experiencia de desarrollo. El framework está muy bien diseñado, así que el trabajo de integración fue realmente simple. Con Rails y React, especialmente Next.js, no sentí esa misma satisfacción en absoluto. Next.js cambia demasiado seguido hasta el router, y como todo cambia cada rato, no me parece confiable. Livewire se siente parecido a Phoenix, pero comparativamente es menos intuitivo y le faltan funciones. Por ejemplo, Livewire no soporta slots de componentes, mientras que Phoenix los maneja sin problema. Sin slots, la estructura de las plantillas se vuelve un desastre y el código se complica innecesariamente. Si a alguien le da curiosidad, puede revisar ckeditor5-phoenix en GitHub
La combinación de PHP (Laravel) y jQuery sigue siendo bastante usable incluso en 2025. Pero personalmente no quiero usar Livewire. Node.js puede ser menos productivo, pero sirve cuando necesitas funciones más potentes. Soporta async/await, socket.io y TypeScript. Next.js sí es útil cuando necesitas tanto SEO como una UI interactiva, pero ¿cuántos sitios realmente necesitan ambas cosas al mismo tiempo? Tal vez solo servicios como LinkedIn
No creo que Livewire sea una copia de Phoenix. Por el nombre podría parecerlo, pero según entiendo ambos proyectos empezaron casi al mismo tiempo y Livewire incluso es más antiguo. Hotwire fue el que apareció más tarde. Los dos proyectos toman enfoques distintos, y PHP y Elixir tienen características demasiado diferentes. Aun así, me parece que Livewire es bastante útil. Como en PHP no es fácil usar WebSockets, funciona más alrededor de HTTP, y en la mayoría de los casos eso basta. De hecho, los WebSockets de LiveView pueden ser excesivos
Me da curiosidad conocer en detalle qué problemas tuvo con Rails. Me gustaría escuchar qué parte fue difícil
También me interesa saber qué fue lo complicado al usar Rails
Livewire 4 sí tendrá soporte para slots de componentes. Pero todavía faltan unas semanas. Dicen que la nueva versión también mejora el rendimiento y la comodidad de desarrollo
Este texto parece escrito para defender el framework que eligió el autor e ignorar deliberadamente funciones de otros frameworks. Todo lo que menciona como ventaja de Phoenix también existe en Rails. Además, deja la impresión de que Rails no soporta comunicación entre frontend y WebSockets, y cualquiera que haya hecho apps con Rails en los últimos 3 años sabe que eso es completamente falso. Claro, Phoenix y LiveView también son buenas herramientas, pero yo sigo usando Rails por Hotwire Native. Me da una ventaja enorme en productividad porque puedo hacer tanto apps móviles como web yo solo y en poco tiempo
No he usado mucho Ruby, pero más allá de la comunidad, me da curiosidad saber en qué supera Ruby on Rails a Elixir y Phoenix. Gracias a la plataforma BEAM, Phoenix me parece teóricamente muy superior para sistemas soft real-time, tolerancia a fallos, NIFs, actor model, muchísimos procesos livianos, concurrencia fácil de razonar, programación funcional, OTP y GC sin interrupciones. Igual, cada quien puede usar lo que le guste, y pienso probar Hotwire Native también
Está claro que Rails también puede comunicarse con el frontend por WebSockets. De hecho, soy desarrollador Rails, pero si necesitara una gran cantidad de conexiones de socket persistentes, elegiría Phoenix. Phoenix puede cubrir 100 mil conexiones de socket mucho más fácil y barato en servicios como Gigalixir. Si administraras tu propia infraestructura, la historia cambia. Pero con Heroku incluso unos pocos miles de conexiones ya son difíciles, y además sale caro
Me pregunto en qué parte del texto dice que Rails no soporta comunicación por WebSockets con el frontend. En el original solo dice: "es algo que tanto Rails como Laravel pueden hacer, pero toma un poco más de tiempo configurarlo". Ese matiz es completamente distinto
La combinación Rails + Hotwire también es realmente poderosa, y con Hotwire Native todavía más. El punto del texto no es que Phoenix y LiveView sean mejores, sino que la estructura de LiveView (estado guiado por el servidor, separación de procesos, canales ligeros, etc.) encaja bien en ciertas situaciones. Ambos ecosistemas están resolviendo problemas parecidos de formas distintas. Rails lo hace desde las convenciones y la mejora progresiva; Phoenix desde la concurrencia y la tolerancia a fallos de BEAM. Al final, lo importante es qué arquitectura se adapta mejor al producto que estás construyendo
Había escuchado de Hotwire Native hace tiempo, pero después sentí que ya no se hablaba mucho del tema. Me da curiosidad saber cómo ha sido usarlo en apps móviles reales: soporte, documentación y nivel de madurez de la implementación
Yo también tengo una opinión muy positiva de Elixir, tanto como el autor, pero como CTO, después de 3 años usándolo en producción, mientras más crecía la escala más cosas empecé a extrañar. BEAM (concurrencia, tolerancia a fallos) sí cumplió su promesa, y Ecto, Oban, remote iex e incluso el pool de talento fueron excelentes. Pero la experiencia de desarrollo (DX) se volvió cada vez más un cuello de botella. En un proyecto grande de 300 mil líneas de código tuve los siguientes problemas:
Si estás pensando en un stack para usar a largo plazo, puede ayudarte leer este retrospectivo de 3 años
Me sorprende muchísimo eso de que una compilación en desarrollo de Elixir tarde más de 10 segundos. Siempre había escuchado que Elixir tenía más ventajas que Rails, así que me pregunto si este tipo de casos es común en trabajo real
A mí también me pasó algo parecido aprendiendo Elixir. El lenguaje me gustó, pero trabajando en Windows con WSL el LSP se rompía seguido y era incómodo. Espero que eso mejore bastante cuando salga pronto el LSP oficial
Si el frontend no se gestiona bien, ya sea con LiveView o con React, en una app grande el código se vuelve caótico muy rápido. Mientras más crece el equipo, más indispensables se vuelven el code review y limpiar lógica innecesaria. En eso todos los frameworks se parecen. Todavía hay muchísimo espacio para mejorar
Dice que "soportar de forma ligera background jobs, actualizaciones en tiempo real y comunicación bidireccional es algo que Rails y Laravel también pueden hacer agregando un poco de configuración", pero Rails ya trae soporte por defecto con Solid Queue (jobs) y Solid Cable (mensajería en tiempo real)
Desde que me pasé recientemente a Rails, SolidQueue me pareció realmente simple: se puede usar casi de inmediato con la configuración básica. Y si además le agregas Solid Queue Dashboard, hasta puedes ver toda la situación de un vistazo
Si hablamos solo de mensajería en tiempo real, siento que configurar Solid Cable es más engorroso que LiveView. Como LiveView también se encarga del renderizado, me parece que está mucho más adelantado que desarrollar con SolidCable en Rails
Todo eso también se puede hacer con Rails. Es un framework hermoso, y con Phoenix se hace más fácil y agradable. De verdad recomiendo probarlo al menos una vez
Hablando desde la experiencia de haber usado tanto Rails como Elixir en producción, los dos sistemas no son para nada equivalentes. Oban tiene un uso claro y reintentar un trabajo es tan simple como actualizar una columna en la base de datos, y el supervisor de Oban se encarga del resto. En Solid Queue no hay una forma fácil de volver a correr un job exitoso. Además, hay demasiadas tablas y eso complica la administración. Oban solo maneja dos tablas, funciona naturalmente dentro de la misma app, mientras que para que Solid Queue funcione bien hay que ir ajustando configuraciones siguiendo varios blogs. La configuración por defecto se queda corta. Gracias a las características de Erlang y Elixir, Oban logra ser muy simple y aun así funcionar de forma excelente, lo cual da gusto como desarrollador. Solid Queue lo estoy usando más por obligación
Después de muchos años desarrollando con Rails, ahora Phoenix/Elixir se volvió mi stack por defecto. Rails sigue siendo lo mejor para crear rápido apps CRUD, y en eso sigue siendo claramente superior. Pero cuando la complejidad crece y pasa el tiempo, Phoenix/Elixir termina siendo una mejor herramienta en conjunto
Desde la llegada de los LLM, apps simples como esas ya se pueden generar en cuestión de minutos. Aun así, en las partes principales que realmente importan, siento que Phoenix te da más control
Me gustaría escuchar algo más concreto sobre en qué te encaja mejor y qué te parece superior
La frase "escribimos código para resolver problemas de la mejor manera posible" transmite claramente la pasión del autor. Yo soy más de quedar razonablemente satisfecho si el problema se resuelve, así que creo que quedarme en Rails va más con mi estilo
Dicen que la comunidad de Elixir es pequeña, pero aun así está apostando por bibliotecas de muy alto nivel. Me acordé de una frase de un desarrollador de hace tiempo: "menos es mejor". También hay muy buen open source como elixir-dbvisor/sql
Si quieres sentir la verdadera esencia de Elixir, recomiendo ver todas las charlas de Saša Jurić
Este texto está más enfocado en Phoenix LiveView que en el framework completo. Personalmente no me gusta que, incluso si excluyes LiveView en las opciones de generación de Phoenix, igual quedan pedazos de código base de LV por todos lados
La única razón por la que no elegí Elixir fue la falta de un type checker. Me pregunto si eso ha cambiado
Es cierto que Livewire es entretenido, pero en cuanto la UI se vuelve un poco más compleja, se convierte en un infierno. A partir de ese momento, Phoenix pierde claramente sus ventajas. Como se vuelve más difícil cuanto más largo es el ciclo, no puedo recomendarlo mucho.