LiveView, la technologie qui se marie le mieux avec Svelte

La combinaison de LiveView et Svelte

• LiveView propose une manière unique de créer des applications web.
• Le serveur détient l’état, traite côté back-end le comportement du front-end et met à jour progressivement le DOM.
• La complexité des SPA vient de celle des systèmes distribués, et LiveView permet d’offrir une expérience client riche sans microservices front-end.

Les difficultés de LiveView

• L’état côté client est inévitable, et la latence entre le serveur et l’utilisateur ne peut pas être évitée.
• LiveView confie au serveur une grande partie des modifications du DOM, mais ne peut pas tout contrôler.
• LiveView dispose de trois types de composants : LiveViews, LiveComponents et Components.
• Le refactoring entre LiveView et LiveComponents est plus fastidieux que prévu.

L’orientation ambiguë de LiveView

• LiveView donne souvent l’impression qu’il lui manque quelque chose.
• LiveView partage beaucoup de points communs avec les frameworks front-end modernes, mais il faut comprendre ses différences et aborder les problèmes autrement.

LiveView + Svelte

• LiveSvelte permet de rendre des composants Svelte dans LiveView.
• Le back-end contrôle les props des composants front-end, et l’état existe à la fois côté front-end et côté back-end.
• Il existe un canal de communication privé et bidirectionnel entre le front-end et le back-end.

Les caractéristiques innovantes de LiveSvelte

• La répartition des responsabilités entre back-end et front-end est claire, et la complexité se concentre côté serveur.
• LiveView révèle tout son potentiel comme front-end du back-end, en fournissant un processus back-end qui rend les composants front-end et en maintient l’état.

L’avis de GN⁺

• La combinaison de LiveView et Svelte sépare efficacement la gestion de l’état entre serveur et client, et permet aux développeurs de créer des applications plus vite et plus intuitivement.
• Cette technologie peut être particulièrement utile pour les applications web où les interactions en temps réel sont essentielles, et peut contribuer à améliorer l’expérience utilisateur.
• Cependant, la latence avec le serveur peut affecter l’expérience utilisateur ; l’optimisation des performances et le déploiement de serveurs au plus près des utilisateurs deviennent donc des points importants.
• La combinaison de LiveView et Svelte propose un nouveau paradigme aux développeurs habitués à la manière classique de créer des SPA, avec le potentiel de réduire la courbe d’apprentissage et d’améliorer l’efficacité du développement.
• La synchronisation d’état en temps réel et la communication bidirectionnelle qu’offre cette technologie peuvent en faire un choix particulièrement attractif pour les outils collaboratifs, les tableaux de bord ou les applications qui traitent des données en temps réel.

[GN⁺]

Avis Hacker News

• L’un des schémas utilisés dans les jeux vidéo multijoueurs consiste à avoir du code qui s’exécute fondamentalement à la fois côté client et côté serveur.

  • Le code client s’exécute comme une prédiction de l’état du serveur.
  • Lorsque l’état du serveur est reçu, il force l’application de l’état côté client.
  • Dans les jeux, « prédiction » est un terme approprié, car le client peut assez bien deviner le résultat des entrées, mais ne peut pas en être certain puisqu’il ne connaît pas les entrées des autres joueurs.
  • Ce paradigme peut aussi être utilisé pour réagir immédiatement aux entrées du client en attendant l’état serveur faisant autorité (par ex. activer/désactiver une liste déroulante, afficher un spinner de chargement).
  • Il existe aussi beaucoup d’états côté client qui ne s’exécutent pas sur le serveur (par ex. systèmes de particules, ragdolls — des éléments qui n’ont pas besoin d’être exactement identiques sur tous les clients et n’interagissent pas avec les entrées/physiques des autres joueurs).

• J’ai fait une présentation à l’ElixirConf 2022 sur la manière de combiner LiveView et Svelte, et les contributeurs de live_svelte ont aidé à en faire une réalité.

  • L’état côté client reste toujours nécessaire, surtout dans les applications avec une UX riche.
  • À New York, la connectivité réseau n’est pas garantie, surtout en déplacement.
  • La capacité de pousser de façon réactive vers le client les changements d’état côté serveur survenus sur d’autres serveurs en utilisant le pubsub de Phoenix est très puissante.

• Quand une nouvelle ligne arrive, LiveView met à jour le client, donc il suffit de la pousser dans le tableau.

  • Je recommande de ne pas utiliser cette méthode dans les applications métier avec des lignes interactives.
  • Cela peut provoquer une latence cognitive : l’utilisateur peut cliquer sur la mauvaise chose, envoyer un e-mail au mauvais client ou rembourser la mauvaise transaction.
  • Une bonne UX consiste à utiliser une bannière discrète signalant que les données ont changé, ou, en cas d’urgence, à seulement ajouter de nouvelles lignes sans modifier la position de défilement.

• Nous utilisons Svelte et LiveView ensemble dans BeaconCMS.

  • C’est un bon cas d’usage quand on veut contrôler plus finement l’UI côté client.
  • Même en utilisant Phoenix, LiveView n’est pas toujours la réponse, et parfois une page rendue statiquement convient parfaitement.
  • Je conseille de ne pas adopter une approche tout ou rien.
  • Comme l’article le souligne, il existe de bons cas d’usage pour sortir de la « manière LiveView ».
  • S’il y a 1000 ms d’aller-retour, d’autres considérations peuvent entrer en jeu, mais il peut être impossible d’utiliser des serveurs géographiquement proches pour des raisons de coût, etc., donc ajouter une gestion d’état côté client peut être la solution.

• Au lieu de gérer l’état sur le client, on gère l’état à la fois sur le client et sur le serveur.

  • Il est difficile de voir cela comme une amélioration ; cela évite certes de devoir construire une autre API, mais cela n’en fait pas pour autant un progrès.

• La limite de cette approche, c’est la vitesse de la lumière : il y a une limite à la proximité du serveur avec l’utilisateur.

  • L’étape suivante consiste à compiler le serveur en WebAssembly et à l’envoyer au client pour rendre les réponses de manière optimiste jusqu’au retour du vrai serveur.
  • Cela peut sembler un peu fou, mais je l’ai fait avec succès dans un vrai projet, et l’expérience est magique.

• Je suis la personne qui a créé LiveSvelte, donc n’hésitez pas si vous avez des questions.

• De manière générale, c’est avec ce modèle que j’avais envie de construire des applis : orienté événements, mises à jour temps réel bidirectionnelles avec le serveur, événements ordonnés, état local et distant...

  • Je ne connaissais pas LiveView et je n’avais jamais utilisé de langage de la famille Erlang, mais ils ont clairement découvert quelque chose.
  • Le modèle traditionnel requête-réponse provoque beaucoup de problèmes de cohérence et de données obsolètes.
  • Une pensée optimiste, mais peut-être controversée : si les dix dernières années ont porté sur l’intégration des concepts de FP dans les langages grand public, j’espère que les dix prochaines porteront sur l’intégration d’une programmation orientée messages avec état (réactive ?) dans l’ensemble de la stack mainstream.

• J’utilise dans mon application des contrôleurs Stimulus réutilisables avec LiveView, et cela fonctionne aussi sans accroc.

  • En général, construire avec LiveView est un plaisir, mais plus je l’utilise dans des scénarios réels, plus je réalise les avantages des frameworks HTTP sans état.
  • Des frameworks comme Hotwire offrent de meilleures performances et une meilleure résilience aux reconnexions, tout en évitant la nécessité de déployer des serveurs plus proches des utilisateurs.

• Super projet ! Nous venons justement de publier un épisode de Svelte Radio à ce sujet.