LiveView, la tecnología que mejor combina con Svelte

La combinación de LiveView y Svelte

• LiveView ofrece una forma única de construir aplicaciones web.
• El servidor mantiene el estado, maneja desde el backend el comportamiento del frontend y actualiza el DOM de forma gradual.
• La complejidad de las SPA proviene de la complejidad de los sistemas distribuidos, y LiveView ofrece una experiencia de cliente rica sin microservicios de frontend.

Lo difícil de LiveView

• El estado del lado del cliente es inevitable, y la latencia entre el servidor y el usuario no se puede evitar.
• LiveView hace que el servidor se encargue de muchos cambios del DOM, pero no puede controlarlo todo.
• LiveView tiene tres tipos de componentes: LiveViews, LiveComponents y Components.
• Refactorizar entre LiveView y LiveComponents es más engorroso de lo esperado.

La dirección ambigua de LiveView

• LiveView a menudo da la sensación de que le falta algo.
• LiveView tiene mucho en común con los frameworks modernos de frontend, pero hay que reconocer sus diferencias y abordar los problemas de otra manera.

LiveView + Svelte

• LiveSvelte permite renderizar componentes de Svelte dentro de LiveView.
• El backend controla las props de los componentes del frontend, y tanto el frontend como el backend tienen estado.
• Existe un canal de comunicación privado y bidireccional entre el frontend y el backend.

Las características innovadoras de LiveSvelte

• La división de responsabilidades entre backend y frontend es clara, y la complejidad se concentra del lado del servidor.
• LiveView brilla más como frontend para el backend, ya que ofrece procesos de backend que renderizan componentes de frontend y mantienen el estado.

La opinión de GN⁺

• La combinación de LiveView y Svelte separa de forma eficiente la gestión del estado entre servidor y cliente, y permite a los desarrolladores construir aplicaciones de manera más rápida e intuitiva.
• Esta tecnología puede ser especialmente útil para aplicaciones web donde la interacción en tiempo real es importante, y puede contribuir a mejorar la experiencia de usuario.
• Sin embargo, como la latencia con el servidor puede afectar la experiencia de usuario, la optimización del rendimiento y la ubicación regional de los servidores pueden ser factores importantes a considerar.
• La combinación de LiveView y Svelte presenta un nuevo paradigma para los desarrolladores acostumbrados al desarrollo tradicional de SPA, con el potencial de reducir la curva de aprendizaje y mejorar la eficiencia del desarrollo.
• La sincronización de estado en tiempo real y la comunicación bidireccional que ofrece esta tecnología pueden convertirla en una opción atractiva, especialmente para herramientas colaborativas, dashboards o aplicaciones que manejan datos en tiempo real.

[GN⁺]

Opiniones de Hacker News

• Uno de los patrones usados en videojuegos multijugador es que existe código que se ejecuta básicamente tanto en el cliente como en el servidor.

  • El código del cliente se ejecuta como una predicción del estado del servidor.
  • Cuando se recibe el estado del servidor, se aplica forzosamente al estado del cliente.
  • En los juegos, “predicción” es un término apropiado, ya que el cliente puede estimar bastante bien el resultado de la entrada, pero no puede estar seguro porque no conoce la entrada de otros jugadores.
  • Este paradigma también puede usarse para reaccionar de inmediato a la entrada del cliente mientras se espera el estado autoritativo del servidor (por ejemplo, activar/desactivar un menú desplegable, mostrar un spinner de carga).
  • También hay mucho estado del cliente que no se ejecuta en el servidor (por ejemplo, sistemas de partículas, ragdoll: cosas que no necesitan ser exactamente iguales en todos los clientes y que no interactúan con la entrada de otros jugadores o con la física).

• Dio una charla en ElixirConf 2022 sobre cómo combinar LiveView y Svelte, y los contribuidores de live_svelte ayudaron a hacerlo realidad.

  • El estado del lado del cliente siempre es necesario, especialmente en apps con una UX rica.
  • En la ciudad de Nueva York, especialmente cuando uno va en movimiento, la conexión de red no está garantizada.
  • La capacidad de usar pubsub de Phoenix para empujar reactivamente al cliente cambios de estado del lado del servidor ocurridos en otros servidores es muy poderosa.

• Cuando entra una fila nueva, LiveView actualiza al cliente, así que basta con hacer push a la tabla.

  • Recomienda no usar este método en apps de negocio con filas interactivas.
  • Puede haber una latencia cognitiva que haga que el usuario haga clic en algo equivocado, envíe un correo al cliente incorrecto o reembolse la transacción equivocada.
  • Una buena UX es usar un banner discreto que indique que los datos cambiaron o, cuando sea urgente, solo agregar filas nuevas sin cambiar la posición del scroll.

• En BeaconCMS usan Svelte y LiveView juntos.

  • Hay buenos casos de uso cuando se quiere un control más fino de la UI en el cliente.
  • Incluso si usas Phoenix, LiveView no siempre es la respuesta; a veces una página renderizada de forma estática está perfectamente bien.
  • Aconseja no adoptar un enfoque de todo o nada para todo.
  • Como señala el artículo, hay varios buenos casos de uso para salirse de la “forma LiveView”.
  • Si hay un round trip de 1000 ms, puede haber otras consideraciones, pero quizá no sea posible usar servidores geográficamente cercanos por costo u otras razones, así que agregar manejo de estado del lado del cliente puede ser la solución.

• En lugar de manejar el estado en el cliente, se maneja tanto en el cliente como en el servidor.

  • Es difícil verlo como una mejora; elimina la necesidad de construir otra API, pero eso no significa necesariamente que sea mejor.

• La limitación de este enfoque está en la velocidad de la luz: hay un límite a qué tan cerca puede estar el servidor del usuario.

  • El siguiente paso es compilar el servidor a WebAssembly y enviarlo al cliente para renderizar respuestas de forma optimista hasta que vuelva el servidor real.
  • Puede sonar un poco loco, pero realmente lo han hecho con éxito en un proyecto y la experiencia se siente como magia.

• Como creador de LiveSvelte, dice que le avisen si tienen preguntas.

• En general, siempre quiso construir apps con este modelo: orientadas a eventos, actualizaciones bidireccionales en tiempo real con servidor, eventos ordenados, estado local y remoto...

  • No conocía LiveView ni había usado lenguajes de la familia Erlang, pero claramente encontraron algo importante.
  • El modelo tradicional de request-response causa muchos problemas de consistencia y de datos desactualizados.
  • Un pensamiento esperanzador, aunque quizá polémico: si la última década trató de integrar conceptos de FP en los lenguajes mainstream, ojalá la próxima década trate de integrar la programación orientada a mensajes con estado (¿reactiva?) en el stack completo mainstream.

• En su app usa controladores reutilizables de Stimulus junto con LiveView, y esto también funciona sin fricción.

  • En general, construir con LiveView es un placer, pero cuanto más se usa en escenarios reales, más se entienden las ventajas de los frameworks HTTP sin estado.
  • Frameworks como Hotwire ofrecen mejor rendimiento y mayor resiliencia ante reconexiones, y evitan la necesidad de ubicar servidores más cerca del usuario.

• ¡Gran proyecto! Acaba de publicar un episodio de Svelte Radio sobre esto.