Vous utilisez mal Rails
(bananacurvingmachine.com)- À travers la conversation entre deux développeurs autour de l’intégration de Vite à Rails 8, le texte tourne en dérision un environnement de développement web moderne devenu inutilement complexe
- L’un ajoute une multitude d’outils comme Vite, React, Babel, Tailwind, Docker, Husky et présente cela comme une stack “moderne”
- À l’inverse, l’autre montre une application qui démarre immédiatement avec Rails seul, sans aucune configuration, révélant l’utilité de la simplicité
- En se moquant de la situation actuelle, dépendante de chaînes d’outils complexes, le texte insiste sur le message « utilisez simplement Rails » et invite à redécouvrir la vertu de la simplicité
- Il souligne que l’objectif originel de Rails — productivité, cohérence et plaisir de développer — est en train d’être oublié
> « Just F#$%^& use Rails »
Traduction du dialogue original
Kevin : Hé, tu as essayé Vite pour Rails 8 ? C’est super rapide.
John : J’en ai entendu parler. C’est un outil de build, non ? Rails n’avait pas déjà quelque chose comme ça ?
Kevin : Si. Mais Vite, c’est plus moderne. Il faut installer Node et npm puis configurer quelques scripts, mais ça vaut le coup.
John : Attends, Rails a besoin de Node maintenant ?
Kevin : Oui, si tu veux utiliser React. De nos jours, tout le monde utilise React.
John : Rails n’avait pas déjà quelque chose pour ça ?
Kevin : Si, mais maintenant il faut utiliser Vite avec React Refresh. Comme ça, les composants se rechargent instantanément. Et si tu veux TypeScript, il faut aussi configurer ça.
John : Rien qu’à t’entendre, ça a l’air compliqué.
Kevin : Non, ce n’est pas grand-chose. Tu installes Babel, tu configures .babelrc, tu ajoutes vite-plugin-ruby, et pour les styles il faut utiliser PostCSS.
John : PostCSS ?
Kevin : Oui. Et bien sûr, il faut aussi Tailwind — tu ne vas quand même pas écrire du CSS à la main, propriété par propriété.
John : Bien sûr que non.
Kevin : Ensuite, tu nettoies le code avec ESLint et Prettier, et si tu ajoutes aussi des hooks Husky avant les commits, c’est parfait.
John : Donc Vite, React, Babel, PostCSS, Tailwind, ESLint, Prettier, Husky. C’est tout ?
Kevin : Presque. Si tu veux aussi du server-side rendering, il faut utiliser Next.js ou Remix.
John : Attends, on parle toujours bien de Rails, là ?
Kevin : Oui. Aujourd’hui, les stacks hybrides sont à la mode ! Et si tu veux des composants réactifs sans framework JS, StimulusReflex ou Hotwire, ça marche aussi.
John : StimulusReflex ? On dirait le nom d’un personnage Marvel.
Kevin : Haha, non, ça existe vraiment. C’est pour les mises à jour en temps réel. Mais il faut configurer ActionCable, et tu as aussi besoin de Redis.
John : Redis ?
Kevin : Oui, parce qu’il faut une couche pub/sub. T’inquiète, il suffit de lancer un conteneur Docker de plus.
John : Il faut aussi utiliser Docker ?
Kevin : Bien sûr. C’est indispensable pour isoler les dépendances. Et si tu veux une reproduction complète de l’environnement, il faut aussi Docker Compose, le déploiement sur Fly.io, et une pipeline avec GitHub Actions.
John : Ça... commence à faire pas mal de complexité.
Kevin : C’est juste du développement web moderne, mon ami. C’est simple. Et toi, tu fais quoi ?
John : Je bidouille juste un peu.
(John lance une seule commande. L’application démarre instantanément. Les formulaires fonctionnent, le chargement est rapide et la navigation va à la vitesse de l’éclair.)
Kevin : Waouh, ça a l’air assez complexe. Tu utilises quelle stack ?
John : Rails vanilla, c’est tout.
> Just F#$%^& use Rails.
3 commentaires
J’aime les deux outils. Ils ont des écosystèmes et des objectifs qui se recoupent en partie, mais ce ne sont pas exactement les mêmes outils, donc on ne devrait pas les juger selon leur niveau de difficulté. Avec vite, on peut écrire des scripts de manière très large et très fine. Stimulus ou Hotwire sont plutôt mieux adaptés pour minimiser le développement de scripts.
On dirait que la majeure partie du contenu se concentre sur le développement frontend...
Avis Hacker News
Cet article est réécrit depuis plus de 10 ans
La soi-disant « complexité » n’est en réalité qu’une liste d’outils, chacun conçu pour résoudre un problème précis
Les outils ne sont pas le problème en eux-mêmes ; la réalité, c’est qu’il existe une complexité intrinsèque au développement web moderne
On retrouve une complexité « cachée » comparable dans ASP.NET ou dans les frameworks GUI desktop
Par exemple, si Rails sert de backend API et que React prend en charge le frontend, on est alors dans une architecture totalement différente d’un monolithe Rails traditionnel
Une liste d’outils comme Vite, React ou Prettier correspond à des choix visant des problèmes complètement différents (si vous voulez utiliser Rails pour le frontend, utilisez simplement Rails ; les formes intermédiaires ne me plaisent pas trop)
Le vrai problème, c’est la manière d’apprendre
Aujourd’hui, beaucoup de développeurs apprennent d’abord les frameworks avant d’apprendre les bases du web (HTML, CSS, logique côté serveur, base de données)
Chaque outil a sa raison d’exister, et tous sont nécessaires dans le web moderne
Voir cela sous l’angle du « il y en a trop » revient à mal comprendre la réalité du secteur
La complexité n’est pas intrinsèque au développement web
Au contraire, aujourd’hui on peut faire plus avec moins
Hotwire fonctionne presque comme du Rails vanilla, et permet de mettre en place en une seule ligne une expérience moderne avec mise à jour du contenu en temps réel via WebSocket
La méthode habituelle pour déployer du JS dans Rails est aussi devenue très simple grâce aux import maps (pas besoin d’étape de build séparée)
Tailwind aussi s’ajoute très facilement
Même le déploiement est devenu bien plus simple avec kamal
Donc je ne suis pas d’accord avec l’idée que la complexité serait essentielle, et Hotwire sert justement à la réduire
L’apprentissage devrait aller vers « faire plus avec moins », pas vers « apprendre toujours plus de choses »
Le vrai savoir-faire, c’est moins de savoir utiliser 20 langages ou serveurs que d’en utiliser 4, en équipe de 3, pour dépasser 1 000 personnes
Les gens ne s’opposent pas à l’existence des outils eux-mêmes ; ils semblent plutôt rejeter l’idée qu’il faille absolument tous les utiliser
Tous les tutoriels, tous les titres de vidéos YouTube sortent des choses du genre « la stack MONGOOSE indispensable ! », donc beaucoup de débutants finissent par vouloir forcer redis dans un blog de pâtisserie
En réalité, la plupart des sites n’ont pas besoin de stack particulière
Mais comme personne ne fait la promotion de ça, beaucoup de développeurs juniors l’ignorent
Je suis d’accord pour dire qu’il faut d’abord apprendre les technologies fondamentales, mais ce n’est pas facile de faire passer ce message au milieu de toutes les entreprises qui poussent leurs services
Je suis encore assez débutant sur Rails, mais j’ai environ 10 ans d’expérience dans d’autres langages
Ajouter des outils si nécessaire, pourquoi pas (qu’ils soient réellement nécessaires est une autre question)
Mais Rails est à l’origine un énorme framework généraliste qui inclut déjà tout, de l’ORM à la console en passant par la génération de code par scaffolding
Si des outils supplémentaires sont nécessaires, ne faudrait-il pas plutôt reconsidérer Rails lui-même ?
Quelque chose de plus modulaire serait peut-être préférable
L’expression « Rails vanilla » me semble être un signal d’alerte. J’ai du mal à voir comment on peut qualifier de vanilla un framework aussi massif
Le propos de cet article, c’est que beaucoup de gens ne se demandent même pas au départ s’ils ont vraiment besoin d’une « application web moderne », et ignorent qu’un simple Rails vanilla suffit souvent
Il manque un effort personnel pour comprendre les choix par défaut de Rails vanilla
Mentionner la « complexité du développement web moderne », c’est simplement décrire une situation problématique, pas poser une condition nécessaire
Si vous utilisez des milliers de packages npm pour un site qui se résume à une base de données et quelques requêtes SQL, c’est que vous faites quelque chose de travers
J’écris du code Rails depuis 2007
Si la stack est devenue complexe, c’est pour de bonnes raisons, et pratiquement aucune équipe ne fait les choses « correctement » selon les critères de l’article
Le problème des frameworks omakase — ceux qui décident de presque tout pour vous, comme Rails — c’est qu’il faut suivre non seulement les choix initiaux, mais aussi les choix ultérieurs, et entraîner toute l’équipe avec soi
Rails est puissant, mais même ses mainteneurs ne peuvent pas prévoir parfaitement l’avenir
C’est pour ça qu’il n’existe presque plus d’apps revenues à du Rails vanilla aujourd’hui
Avant Docker, déployer Rails était vraiment pénible. Au lieu de rsync ou de tarballs, il fallait des systèmes de déploiement comme Capistrano.
Docker ou k8s sont pratiques, mais ce n’est pas vraiment pire qu’avant
Si vous vous souvenez du déploiement Rails pré-Docker comme d’un simple « rsync puis extraction d’un tarball », c’était vraiment une installation catastrophique
Déployer avec le « vieux » Capistrano était bien mieux
J’aimerais bien qu’on explique plus précisément ce qui posait concrètement problème dans « pousser sur plusieurs instances avec rsync ou des tarballs »
Dit comme ça, ça n’a pas l’air si grave
C’est pour ça que j’ai toujours eu un faible pour Sinatra
C’est dommage que le monde JS n’arrive toujours pas à remplacer les utilitaires fournis out-of-the-box par Rails
La plupart des développeurs JS ne s’en rendent pas bien compte
Mais JS reste un écosystème où l’on réinvente sans cesse la roue
L’un des grands atouts de JS, c’est que tout le monde a sa chance pour créer une nouvelle plateforme
Même en combinant plusieurs plateformes JS à la fois, tout fonctionne à peu près ; c’est très extensible, très hackable, et on peut même tout builder en local de manière permanente pour produire un site figé
Mais cette liberté demande aussi de la retenue
C’est à l’équipe d’empêcher le collègue qui veut introduire un nouveau framework à la moindre occasion
Ember.js est un framework tout-en-un (« batteries incluses ») créé par de grands noms du monde Rails
Mais s’il n’a pas eu autant de succès que d’autres frameworks, il y a bien une raison
Il existe aussi dans l’écosystème JS des frameworks backend batteries incluses, comme AdonisJS
Mais l’écosystème NodeJS est parti des microframeworks en réaction aux frameworks rigides comme Rails ou Django
Le concept d’Express, c’était aussi de faire quelque chose de « rapide et sale »
Il existe aussi plusieurs frameworks full stack en JS, similaires à Rails
Il y a aussi un framework appelé Sails
JS résout des problèmes différents de ceux que Rails adresse, donc les frameworks ne peuvent qu’avoir une forme différente
Rails fournit beaucoup d’utilitaires, mais à long terme il peut être fatigant de devoir mettre régulièrement à jour la codebase et suivre en permanence les tendances de Rails
Stimulus et Hotwire se sont désormais imposés comme la « rails way »
Même en lisant la documentation avec attention, je trouve toujours ça beaucoup trop confus
J’ai toujours l’impression de recréer encore et encore moi-même des composants JS
À mon avis, la combinaison Rails 8 + Inertia.js + React évite davantage de « réinventer la roue », surtout si on utilise des composants shadcn
Je suis d’accord là-dessus
Nous aussi, nous avons remplacé un frontend Hotwire par Inertia, et la différence est énorme
À moins d’être vraiment seul à 100 % sur un petit projet, Hotwire devient vite un bazar que plus personne dans l’équipe ne peut toucher
Pour ma part, j’ai tellement aimé Stimulus que je l’ai repris tel quel de Rails dans une app Phoenix
Mais le problème, selon moi, c’est surtout l’incompréhension autour de cet outil
Stimulus n’est pas une alternative à React
Si vous avez l’habitude d’applications JS de dizaines de milliers de lignes, React peut être le bon choix
Mais si vous avez une application centrée sur le serveur et que vous voulez affiner l’UX avec quelques dizaines de lignes de JS, Stimulus est parfait
Dans Phoenix, c’est une solution minimale qui s’insère exactement entre du HTML statique et des LiveViews dynamiques
Personne n’a jamais dit qu’il fallait construire une SPA avec Stimulus, et dans ce cas-là, il est évident qu’on se retrouvera dans une situation pénible
Stimulus est vraiment minuscule, c’est un système événementiel avec des hooks HTML, et ça s’accorde bien avec le cycle de requête de Rails
Je me demande si quelqu’un a déjà réussi à construire quelque chose de vraiment très complexe avec Stimulus
À mon avis, c’est trop difficile d’aller aussi loin
Je suis moi aussi plutôt fanboy de Rails, mais l’état actuel de Stimulus et Hotwire me déçoit
Les concepts sont excellents, et l’implémentation est peut-être bonne aussi
Mais la documentation est tellement insuffisante qu’on n’ose même pas commencer, et il n’existe pas de vraies informations permettant de savoir si démarrer un projet avec ça ne va pas nous mener dans une impasse plus tard
J’ai utilisé Stimulus avec Symfony pour de petites interactions, et c’était plutôt pas mal grâce à une API petite et bien conçue
Je n’ai pas encore utilisé tout Turbo/Hotwire, et pour les pages complexes ou nécessitant de l’état, j’utilise en général Vue
De toute façon, les projets greenfield ont quasiment disparu aujourd’hui
En dehors des fondateurs, les greenfields sont rares, et si vous vendez quelque chose, dans 99 % des cas ce sera traité via un wrapper Shopify ou quelque chose du même genre
Même dans les grandes entreprises, les greenfields sont pris dans toutes sortes de contraintes et de frameworks internes, donc on ne part pas de « rails new »
Ce genre de débat n’a pas beaucoup de sens, et comme les mêmes polémiques et articles reviennent depuis 10, 15 ou 20 ans, c’est lassant et ennuyeux
J’aimerais qu’on fabrique réellement quelque chose de nouveau au lieu d’écrire encore un nouvel article
Tout à fait d’accord
J’ai travaillé 10 ans en Ruby/Rails, et même les codebases les plus « récentes » avaient déjà plus de 5 ans
Honnêtement, il m’est bien arrivé de créer une nouvelle app Rails greenfield, mais c’était un microservice API-only, donc il n’y avait pas besoin de frontend
Dans les entreprises d’une certaine taille, la solution frontend de Rails est tout simplement ignorée
Même si on ne trouve pas d’ingénieur connaissant Hotwire, on peut toujours recruter des développeurs React ou Vue sans difficulté
La stack FE de Rails change aussi trop souvent pour qu’on arrive à suivre (par exemple, je me souviens de l’époque CoffeeScript), il n’y a presque pas de documentation correcte, et dans les faits son influence est nulle
Donc ce genre de débat est déconnecté de la réalité du terrain
Je ne peux pas être d’accord avec l’affirmation selon laquelle « les projets greenfield n’existent plus en dehors des fondateurs »
Si on prend uniquement comme exemples de vieux monolithes d’entreprise ou des Fortune 500, on parle d’une infime minorité qui ne représente pas la moyenne
Au contraire, je trouve admirable le soin mis dans « rails new » pour fournir des valeurs par défaut saines et directement utilisables
Cette approche comble très bien l’écart entre Hello World et une documentation API trop simpliste
Même sans utiliser Rails, c’est un aspect dont on peut s’inspirer
C’est mignon, mais ça ne parle pas de la réalité d’une app Rails qui, au fil de son évolution, doit migrer de bundler à webpacker, puis à sprockets, Propshaft, importmaps, jsbundling, etc.
De l’autoloader à zeitwerk, de Turbo à Hotwire, il y a en réalité énormément de choses qui ont changé ainsi
Rien qu’en regardant les publicités dans les newsletters Rails, on voit déjà qu’il y en a beaucoup pour des « experts qui aident à mettre à jour les apps Rails »
Merci de mentionner cet aspect
Dire « utilisons juste du Rails vanilla », c’est facile, mais ces 5 dernières années, la manière de gérer le JS a complètement changé à chaque version de Rails
Il y a encore beaucoup de gems qui dépendent de sprockets, donc même en suivant la voie Rails, on se retrouve malgré tout avec un gros bloc JS complexe
La situation est vraiment confuse en ce moment. Ça s’améliorera peut-être un jour, mais Rails porte clairement une part de responsabilité
Il ne faut pas non plus oublier CoffeeScript
Jusqu’à récemment, l’entreprise où je travaillais repoussait encore la migration du CoffeeScript, tandis que le nouveau code était écrit en Vue
D’expérience, j’ai appris que si un projet ne mobilise pas plus de 30 développeurs avec différentes spécialisations travaillant en parallèle, la complexité qu’apporte une séparation frontend/backend n’est pas nécessaire
À l’époque où j’étais freelance, j’ai moi aussi surconçu inutilement des projets pour des équipes de 1 ou 2 personnes, mais aujourd’hui je me contente généralement de Django avec un peu de Tailwind par-dessus
Cette année, nous avons recruté des développeurs Django, et presque tous les candidats construisaient un backend API mince avec Django, puis un gros frontend React (en mettant souvent même la logique métier dans le frontend)
Quand on leur demandait pourquoi, ils étaient presque tous incapables de l’expliquer
Au final, nous n’avons retenu que les rares candidats qui utilisaient uniquement du rendu côté serveur
Il faut peut-être réfléchir à ce qu’on ferait si un frontend vraiment très interactif était nécessaire
Je suis d’accord aussi
Dans la plupart des cas, les clients se soucient peu de savoir si le projet a réellement besoin d’ultra-scalabilité et de microservices, ou si un monolithe avec PostgreSQL suffit largement
J’ai l’impression que beaucoup de gens ne poursuivent que les technologies les plus récentes et configurent tout pour une montée en charge infinie
En réalité, Rails reste extrêmement utile avec une conception simple, et il y a souvent de la sur-ingénierie simplement parce que « c’est ennuyeux » ou « pas amusant »
Pourtant Rails est vraiment un framework batteries incluses, et dès qu’on arrête l’overengineering, ça fonctionne tout simplement
À un moment, on finit par sentir que la productivité est la valeur la plus importante
C’est surtout que c’est plus complexe aujourd’hui ; ces concepts eux-mêmes n’ont rien de nouveau
Quand j’ai appris Django il y a 15 ans, les tutoriels demandaient déjà d’installer une version précise de Vagrant, VirtualBox et Chef, au point de me rendre fou
J’aime toujours Django et je l’utilise encore aujourd’hui, mais je ne me préoccupe pas de ces outils
Django Rest Framework aussi m’a plutôt dispersé qu’aidé
La « fatigue liée au tooling du développement web » est très réelle
Elle l’était déjà il y a 10 ans, et ce chaos vient souvent du fait que les développeurs importent leurs goûts de hobby dans leur travail
Et d’ailleurs, ce n’est pas seulement le frontend : côté DevOps, la situation est assez similaire
Résultat, pour postuler dans ce domaine, on a l’impression qu’il faut connaître tous les outils, avoir 10 ans d’expérience, maîtriser différents backends et SQL, ainsi que Docker
Si c’est votre spécialité, vous faites le setup une fois et c’est réglé, mais pour un projet ponctuel ou si le développement web n’est pas votre activité principale, c’est effectivement épuisant
Mais on peut aussi l’éviter de cette manière
J’ai créé un site web avec le framework Fresh(https://fresh.deno.dev/), et cela m’a largement suffi
En général, c’était bien plus simple que la combinaison Node/Webpack, tout en permettant d’utiliser Typescript et TSX
Si plusieurs personnes avaient travaillé dessus, j’aurais peut-être ajouté quelque chose comme ESLint, mais même sans cela, on pouvait démarrer très facilement