Pourquoi j’ai choisi Elixir Phoenix plutôt que Rails, Laravel ou Next.js

 (akarshc.com)
7 points par GN⁺ 2025-10-18 | 3 commentaires | Partager sur WhatsApp
  • Phoenix LiveView offre une grande efficacité à la fois en vitesse de l’application et en vitesse de développement
  • L’un de ses avantages est de permettre une approche monolithique dans un langage unique, sans avoir à maintenir séparément le frontend et le backend
  • Rails Hotwire et Laravel Livewire ont aussi été envisagés, mais la mise en place y demande davantage de configuration pour le temps réel et les tâches en arrière-plan
  • Le framework Phoenix d’Elixir conserve l’élégance de Ruby on Rails tout en offrant des performances nettement supérieures, avec des tâches en arrière-plan via Oban intégrées par défaut, ainsi qu’une syntaxe familière et propre
  • LiveView fournit des mises à jour bidirectionnelles en temps réel via WebSocket, en trouvant un équilibre entre le rendu serveur traditionnel et les frameworks centrés sur le frontend, avec la possibilité d’utiliser Alpine.js ou des bibliothèques JavaScript via des hooks si nécessaire
  • La rapidité de développement, la forte capacité de concurrence, la possibilité d’écrire l’essentiel dans un seul langage, la prévention en amont des bugs grâce au compilateur et l’architecture tolérante aux pannes d’Elixir/Erlang ont été les facteurs décisifs du choix final

Pourquoi avoir choisi Phoenix LiveView

  • Le but du code est de résoudre un problème de la manière la plus optimale possible, et les critères les plus importants ici étaient la vitesse de l’application et l’efficacité du développement
  • Avec React ou Next.js associés à Laravel, ou encore Inertia.js avec Laravel, il faut maintenir à la fois la stack frontend et la stack backend
  • En tant que développeur solo, il n’y avait pas le temps de gérer l’état à deux endroits différents, et il fallait donc une solution monolithique robuste capable de tout gérer ensemble

  • Comparaison des alternatives : Laravel Livewire, Rails Hotwire, Next.js

    • Laravel Livewire et Rails Hotwire sont d’excellents outils pour simplifier le travail frontend sans dépendre fortement de JavaScript
    • Une stack 100 % JavaScript avec Next.js a été envisagée, mais l’usage de JavaScript côté backend n’était pas souhaité
    • Rails Hotwire attirait particulièrement l’attention pour sa capacité à construire rapidement un MVP avec Rails
    • Cependant, il fallait des tâches en arrière-plan, des mises à jour en temps réel et une communication bidirectionnelle ; c’est également possible avec Rails et Laravel, mais cela demande davantage d’efforts de configuration

  • Les avantages décisifs d’Elixir, Phoenix et LiveView

    • Elixir et Phoenix conservent l’élégance de Ruby on Rails tout en offrant des performances bien supérieures
    • Les tâches en arrière-plan intégrées via Oban, une syntaxe familière et lisible, ainsi que la communication bidirectionnelle en temps réel de LiveView constituent leurs grands points forts
    • LiveView trouve un équilibre idéal entre le rendu côté serveur et les frameworks très chargés côté frontend
    • Il permet des mises à jour en temps réel via WebSocket et l’intégration de bibliothèques JavaScript (par exemple Alpine.js)
    • Avec Oban intégré, Phoenix facilite la déclaration des jobs en arrière-plan et leur reprise automatique

  • Les avantages d’Elixir/Erlang

    • Elixir est un langage compilé construit sur Erlang, à la base de systèmes à très grande concurrence comme WhatsApp ou Discord
    • Il offre une forte concurrence, une tolérance aux pannes et une récupération automatique après incident

Raisons du choix final

  • Développement rapide et forte prise en charge de la concurrence
  • Possibilité d’implémenter presque tout dans un langage unique
  • Écriture d’un code lisible
  • Le compilateur détecte la plupart des bugs avant la mise en production
  • Une architecture tolérante aux pannes qui fait que l’application tombe rarement en panne, garantissant ainsi sa stabilité

Conclusion et conseil

  • Phoenix n’est pas systématiquement supérieur à Rails, Laravel ou Next.js
  • Tous ces frameworks sont excellents, et chacun a été utilisé sur divers projets
  • Pour cette situation précise et ce projet (Hyperzoned.com), Phoenix était le meilleur choix
  • En explorant au-delà de ce que l’on connaît déjà, on peut trouver une manière meilleure et plus efficace de résoudre le problème suivant
  • Ne cessez jamais d’apprendre

À lire aussi

3 commentaires

 
clastneo 2025-10-23

Pour les mêmes raisons qu’avec JSP, j’ai l’impression qu’au-delà d’un certain niveau, ça devient inutilisable.
 
GN⁺ 2025-10-18
Avis Hacker News

  • J’ai déjà intégré CKEditor moi-même avec Rails, Livewire, Phoenix et React. Parmi eux, du point de vue de l’expérience développeur, Phoenix a été de loin le plus impressionnant. Le framework est extrêmement bien conçu, ce qui a rendu l’intégration vraiment simple. Je n’ai jamais ressenti ce niveau de satisfaction avec Rails ni avec React, surtout pas avec Next.js. Avec Next.js, le routeur change beaucoup trop souvent, et comme tout évolue en permanence, je n’arrive pas à lui faire confiance. Livewire donne une impression proche de Phoenix, mais c’est relativement moins intuitif et moins riche en fonctionnalités. Par exemple, Livewire ne prend pas en charge les slots de composants, alors que Phoenix les gère sans problème. Sans slots, la structure des templates devient vite chaotique et le code inutilement complexe. Si ça intéresse quelqu’un, voir le GitHub de ckeditor5-phoenix

    • La combinaison PHP (Laravel) + JQuery reste tout à fait utilisable en 2025. En revanche, personnellement, je n’ai pas envie d’utiliser Livewire. Node.js peut être moins productif, mais il devient pertinent quand on a besoin de fonctionnalités plus puissantes. Il prend en charge async/await, socket.io et TypeScript. Next.js est utile quand on a besoin à la fois de SEO et d’une UI interactive, mais combien de sites ont réellement besoin de tout cela en même temps ? Peut-être seulement des services comme LinkedIn

    • Je ne pense pas que Livewire soit une copie de Phoenix. Le nom pourrait le laisser croire, mais à ma connaissance les deux projets ont commencé quasiment en même temps, et Livewire est même plus ancien. Hotwire est arrivé le plus tard. Les deux projets adoptent des approches différentes, car PHP et Elixir ont des caractéristiques trop éloignées. Je trouve aussi Livewire assez utile. Comme il n’est pas facile d’utiliser les WebSocket en PHP, il fonctionne surtout via HTTP, et dans la plupart des cas cela suffit. À l’inverse, les WebSocket de LiveView peuvent être excessifs

    • Je serais curieux d’avoir des détails concrets sur les problèmes rencontrés avec Rails. J’aimerais savoir ce qui a été difficile

    • Je serais curieux de savoir ce qui a été compliqué avec Rails

    • Livewire 4 doit ajouter la prise en charge des slots de composants. Mais il reste encore quelques semaines. La nouvelle version devrait aussi améliorer les performances et le confort de développement

  • Cet article donne l’impression que l’auteur défend le framework qu’il a choisi tout en ignorant volontairement les fonctionnalités des autres. Tous les avantages de Phoenix mentionnés ici existent aussi dans Rails. En plus, le texte laisse entendre que Rails ne permet pas la communication entre le front-end et les WebSocket, ce qui est totalement faux pour quiconque a construit une app avec Rails au cours des trois dernières années. Bien sûr, Phoenix et LiveView sont de très bons outils, mais si je continue à utiliser Rails, c’est grâce à Hotwire Native. Cela me donne un énorme avantage de productivité, car je peux créer seul à la fois des apps mobiles et web en très peu de temps

    • Je n’ai pas beaucoup utilisé Ruby, mais au-delà de la communauté, je me demande en quoi Ruby on Rails serait supérieur à Elixir & Phoenix. Grâce à la plateforme BEAM, je considère en théorie Phoenix comme très supérieur pour les systèmes soft real-time, la tolérance aux pannes, les NIFs, le modèle acteur, les innombrables processus légers, une concurrence facile à raisonner, la programmation fonctionnelle, OTP et un GC sans interruption. Cela dit, chacun utilise ce qu’il préfère, et je compte aussi essayer Hotwire Native

    • Il est clair que Rails peut aussi communiquer avec le front via WebSocket. Cela dit, je suis développeur Rails et si j’avais besoin d’un grand nombre de connexions socket persistantes, je choisirais Phoenix. Phoenix peut couvrir 100 000 connexions socket de façon bien moins chère et plus simple sur des services comme Gigalixir. Si on gère soi-même l’infrastructure, c’est une autre histoire. Mais sur Heroku, il est difficile de gérer ne serait-ce que quelques milliers de connexions, et le coût devient vite lourd

    • Je me demande où, dans le texte, il est dit que Rails ne prend pas en charge la communication WebSocket avec le front. Dans l’original, il est seulement écrit que « c’est faisable à la fois dans Rails et Laravel, mais que cela prend un peu plus de temps à configurer ». Ce n’est pas du tout la même nuance

    • La combinaison Rails + Hotwire est elle aussi très puissante, et encore plus avec Hotwire Native. Le point principal de cet article n’est pas de dire que Phoenix et LiveView sont meilleurs, mais que la structure de LiveView (état piloté par le serveur, séparation des processus, canaux légers, etc.) est adaptée à certains cas. Les deux écosystèmes résolvent des problèmes similaires de manières différentes. Rails mise sur les conventions et l’amélioration progressive, Phoenix sur la concurrence et la tolérance aux pannes de BEAM. Au final, l’important est de savoir quelle architecture correspond le mieux au produit que l’on construit

    • J’avais déjà entendu parler de Hotwire Native, mais j’ai l’impression que les nouvelles se sont calmées depuis. Je serais curieux d’avoir des retours d’expérience sur de vraies apps mobiles, ainsi que sur le support, la documentation et le niveau de finition de l’implémentation

  • Moi aussi, j’ai une vision très positive d’Elixir, presque autant que l’auteur, mais après trois ans d’utilisation en production comme CTO, j’ai aussi ressenti de plus en plus de limites à mesure que l’échelle augmentait. BEAM (concurrence, tolérance aux pannes) a bien tenu ses promesses, et Ecto, Oban, remote iex ainsi que le vivier de talents étaient excellents. Mais l’expérience développeur (DX) est devenue peu à peu un goulot d’étranglement. Sur un gros projet de 300 000 lignes, j’ai rencontré les problèmes suivants :

    • Temps de compilation : changer une seule ligne de code entraînait plus de 10 secondes de compilation en environnement de développement, ce qui cassait sans cesse la concentration
    • Tooling : l’autocomplétion d’ElixirLS n’était pas fiable, ce qui me faisait perdre du temps à chercher des noms de fonctions ou des champs de schéma
    • LiveView : peu adapté aux UI complexes, ce qui nous a forcés à introduire un front-end React, et donc à réintroduire toute la complexité de GraphQL et d’une séparation du stack
      Si vous réfléchissez à un stack à utiliser sur le long terme, le billet 3-year Retrospective peut être utile

    • Je suis très surpris d’apprendre qu’une compilation dans l’environnement de développement Elixir puisse prendre plus de 10 secondes. J’avais toujours entendu dire qu’Elixir apportait davantage de bénéfices que Rails, donc je me demande si ce genre de cas est fréquent en conditions réelles

    • J’ai eu une expérience similaire en apprenant Elixir. J’aimais bien le langage, mais en travaillant sous Windows avec WSL, le LSP plantait souvent, ce qui était pénible. J’espère que cela s’améliorera nettement avec la sortie prochaine du LSP officiel

    • Que ce soit avec LiveView ou React, si le front-end n’est pas bien maîtrisé, le code devient vite désordonné dans une grosse application. Plus l’équipe grandit, plus les revues de code et le nettoyage de la logique inutile deviennent indispensables. J’ai l’impression que c’est pareil pour tous les frameworks. Il reste encore énormément de marge de progression

  • L’article affirme que « les jobs en arrière-plan, les mises à jour en temps réel et la communication bidirectionnelle légère sont tous possibles dans Rails et Laravel avec juste un peu de configuration supplémentaire », mais Rails prend déjà en charge Solid Queue (jobs) et Solid Cable (messagerie temps réel) par défaut

    • Depuis que je suis passé récemment à Rails, je trouve que SolidQueue est vraiment très simple à utiliser avec la configuration de base. En ajoutant même Solid Queue Dashboard, on peut avoir une vue d’ensemble très claire

    • Si l’on parle uniquement de messagerie temps réel, je trouve que la configuration de Solid Cable est plus fastidieuse que LiveView. LiveView va plus loin, puisqu’il gère aussi le rendu, et je pense qu’il est bien en avance sur le développement avec SolidCable dans Rails

    • Toutes ces fonctionnalités sont également possibles avec Rails. C’est un très beau framework, et avec Phoenix c’est plus simple et plus agréable. Je recommande vraiment de l’essayer au moins une fois

    • Ayant utilisé Rails et Elixir en production, je peux dire qu’ils ne sont absolument pas équivalents. Oban est clair à utiliser, et pour relancer un job il suffit de mettre à jour une colonne en base pour que le supervisor Oban s’en charge correctement. Avec Solid Queue, il n’y a pas de moyen simple de relancer un job réussi. Il y a aussi trop de tables, ce qui complique la gestion. Oban se contente de deux tables, fonctionne naturellement dans la même app, alors qu’avec Solid Queue il faut modifier des réglages après avoir lu plusieurs billets de blog pour que tout marche correctement. La configuration par défaut est insuffisante. Grâce aux caractéristiques d’Erlang/Elixir, Oban est remarquablement performant tout en restant très simple, ce qui est un vrai plaisir pour un développeur. J’utilise Solid Queue un peu par contrainte

  • Après avoir développé longtemps avec Rails, Phoenix/Elixir est devenu mon stack par défaut ces derniers temps. Rails reste vraiment le meilleur pour créer rapidement des apps CRUD, et sur ce point il est clairement excellent. Mais quand la complexité augmente et que le temps passe, Phoenix/Elixir devient globalement un meilleur outil

    • Depuis l’arrivée des LLM, ce genre d’app simple peut être généré en quelques minutes. En revanche, sur les parties vraiment importantes auxquelles il faut faire attention, j’ai l’impression que Phoenix donne plus de contrôle

    • J’aimerais entendre plus précisément ce qui te semble mieux convenir, et sur quels points tu le trouves supérieur

  • La phrase « nous écrivons du code pour résoudre les problèmes de la meilleure façon possible » laisse sentir une vraie passion. Moi, je suis plutôt du genre à être raisonnablement satisfait tant que ça marche, donc rester sur Rails me convient probablement mieux

    • Cette phrase m’a fait éclater de rire. En pratique, si on code en ne pensant qu’à l’optimisation, le travail finit surtout par avancer plus lentement. Pour moi, coder est aussi un moyen de gagner ma vie, et parfois simplement un loisir

  • On dit souvent que la communauté Elixir est petite, mais elle vise un niveau très élevé avec des bibliothèques de pointe. Cela me rappelle ce qu’avait dit un ancien développeur : « moins, c’est mieux ». Il y a aussi beaucoup de très bons projets open source, comme elixir-dbvisor/sql

    • À l’inverse, l’écosystème JS me semble pénible parce qu’il est trop vaste. Il y a dix bibliothèques différentes qui existent chacune de leur côté, et personne ne suit de standard. C’est un peu comme choisir un menu dans une grande chaîne de supermarchés américaine, ou se faire imposer un choix dans une chaîne de restaurants Vercel

  • Si vous voulez vraiment saisir la valeur d’Elixir, je recommande de regarder toutes les conférences de Saša Jurić

    • Saša Jurić est l’auteur de 'Elixir in Action', et le livre est lui aussi excellent

  • Cet article se concentre davantage sur Phoenix LiveView que sur le framework dans son ensemble. En pratique, je n’aime pas le fait que, même si on retire LiveView des options de génération dans Phoenix, il reste encore du code LV par-ci par-là

    • Moi aussi, je trouve que LiveView est très directif et plein de boilerplate. J’aime la concision et l’expressivité d’Elixir, et LiveView me donne plutôt l’impression inverse

  • La seule raison pour laquelle je n’ai pas choisi Elixir, c’était l’absence de type checker. Je me demande si cela a évolué
 
colus001 2025-10-18

Il est vrai que Livewire est amusant, mais dès que l’UI devient un peu plus complexe, ça tourne à l’enfer. À partir de ce moment-là, Phoenix perd brutalement ses avantages. Comme cela devient de plus en plus difficile à mesure que le cycle s’allonge, je ne peux pas vraiment le recommander.