2 points par GN⁺ 2026-03-13 | 4 commentaires | Partager sur WhatsApp
  • En créant une application de gestion de setlists (setlist.rocks) pour son groupe, l’auteur a redécouvert avec plaisir le développement en Ruby on Rails
  • Le récent Rails 8 conserve la structure MVC traditionnelle tout en se modernisant avec un frontend “no-build” basé sur Hotwire (Stimulus·Turbo), ainsi que Solid Cache/Queue/Cable
  • SQLite a été suffisamment optimisé pour convenir à un service en production avec la configuration par défaut, et l’outil de déploiement Kamal simplifie les déploiements sans interruption basés sur des conteneurs
  • Grâce à la philosophie “la convention plutôt que la configuration” de Rails et à son riche écosystème de gems, il est possible de passer rapidement de l’idée au prototype
  • La popularité de Ruby et Rails a diminué par rapport à autrefois, mais ils restent un framework OSS mature et cohérent qui procure toujours du plaisir à développer

Projet annexe et retour à Rails

  • Afin de gérer les setlists et les notes de morceaux de son groupe, l’auteur a développé lui-même une web app, cherchant une approche plus efficace que les feuilles de calcul ou le chat
  • Au cours du développement, il a de nouveau ressenti la simplicité et la productivité de Rails, et explique avoir retrouvé un “plaisir pur de développer” face à la complexité récente de l’écosystème web
  • Ruby est toujours considéré comme un langage à la syntaxe naturelle et expressive, qui facilite la traduction de la pensée en code
  • Selon l’enquête Stack Overflow 2025, la popularité de Ruby et Rails a baissé, mais ils restent appréciés pour les projets personnels

Évolutions de Rails 8 et frontend

  • Rails 8 conserve la structure MVC existante tout en proposant une intégration frontend basée sur Hotwire (Stimulus·Turbo)
    • Turbo intercepte les clics sur les liens et les soumissions de formulaires pour offrir une réactivité de niveau SPA
    • Stimulus ajoute du comportement JS uniquement là où c’est nécessaire, ce qui permet de créer une UI interactive avec un minimum de JavaScript
  • Avec Importmap, il est possible de charger directement des bibliothèques JS depuis un CDN sans Webpack ni npm
  • L’auteur a utilisé des outils d’IA pour générer l’UI, tout en exprimant ses interrogations sur le rapport entre création et dimension artistique du code

Workflow de développement et productivité

  • La philosophie “la convention plutôt que la configuration (Convention over Configuration)” de Rails permet de mettre rapidement en place modèles, routage, contrôleurs et vues
    • L’exemple montre la génération d’un modèle Tag, l’automatisation du routage RESTful et le traitement des réponses JSON
  • Les templates ERB et le live reload permettent un prototypage rapide
  • Le riche écosystème de gems permet d’intégrer facilement diverses fonctionnalités comme le CSV ou le PDF

Améliorations backend : série Solid* et SQLite

  • Solid Cache/Queue/Cable est inclus par défaut dans Rails 8, ce qui permet de gérer cache, file de jobs et WebSocket sans Redis
    • Solid Cache utilise un cache basé sur la base de données pour économiser la RAM et simplifier l’architecture
    • Solid Queue gère les tâches en arrière-plan via la base de données, avec une exécution possible via le seul réglage SOLID_QUEUE_IN_PUMA=1
    • Solid Cable fournit un adaptateur Action Cable basé sur la base de données pour les fonctionnalités temps réel
  • SQLite applique par défaut des optimisations comme le mode WAL et la synchronisation NORMAL via le réglage pragmas: dans database.yml
    • Il peut ainsi être utilisé de manière pratique dans de petits environnements de production sans serveur de base de données séparé

Automatisation du déploiement et Kamal

  • En rappelant la complexité des déploiements passés basés sur Capistrano et Ansible, l’article présente Kamal comme l’outil de déploiement par défaut de Rails 8
    • Il automatise la séquence construction de conteneur → push → déploiement sur serveur → health check → bascule sans interruption
    • kamal-proxy prend en charge la bascule du trafic et le traitement SSL
    • Le fichier .kamal/secrets permet une gestion sécurisée des secrets fondée sur des variables d’environnement
  • Intégré à GitLab CI, le déploiement peut se faire avec un simple git push, retrouvant la simplicité d’Heroku d’autrefois

Authentification et autres fonctionnalités

  • Rails 8 fournit un générateur d’authentification intégré (auth generator), permettant de construire un système d’authentification plus simple que Devise
  • Devise reste utile grâce à ses fonctionnalités riches et à sa documentation, mais la simplicité de l’authentification native de Rails est également présentée comme séduisante

État actuel et durabilité de l’écosystème Rails

  • La popularité de Ruby et Rails a diminué, mais des services majeurs comme Shopify·Basecamp·SoundCloud·GitHub les utilisent toujours
  • De nombreuses gems sont entrées dans une phase de maintenance, mais Rails conserve un cycle de publication régulier chaque année
  • L’article le décrit comme “un framework dans lequel il est toujours agréable de développer”, même si l’arrivée de nouvelles générations de développeurs a ralenti

Conclusion

  • Rails s’est tenu à l’écart des tendances les plus récentes, mais il est mis en avant comme un outil qui redonne le plaisir de développer et la simplicité
  • En privilégiant le plaisir de créer et la créativité plutôt que la popularité, l’article se conclut sur un message simple : “essayez Rails à nouveau”

4 commentaires

 
joyfui 2026-03-14

Si c’est Rails, il me semble que c’était « la convention plutôt que la configuration », pas « la configuration plutôt que la convention »...

 
savvykang 2026-03-14

> most of the web frameworks I’d (...) required endless amounts of XML boilerplate and other configuration to wire things up. Rails a balayé tout cela et a introduit l’idée de la « convention plutôt que de la configuration »

Il semble que le LLM ait reproduit l’entrée telle quelle, dans le même ordre, sans modifier l’ordre des mots. Dans le texte original, c’est correct.

 
xguru 2026-03-14

Le LLM se trompe là-dessus. J’ai corrigé. Merci.

 
GN⁺ 2026-03-13
Commentaires sur Hacker News
  • J’aime vraiment Rails, mais après avoir travaillé sur de grandes bases de code non typées statiquement, il m’est difficile d’y revenir en dehors de projets personnels
    Une grosse base de code sans types est un cauchemar à maintenir, même avec un IDE puissant comme RubyMine
    Je me demande à quel point Sorbet a progressé ces derniers temps, surtout dans son intégration avec RoR

    • En ce moment, je trouve que Rust/Loco est le framework le plus intéressant
      Il suit bien la philosophie de Rails tout en rendant l’apprentissage de Rust plus accessible
    • IHP est un framework inspiré de Rails, basé sur Haskell, qui essaie de combiner le meilleur des deux mondes
      Ça vaut le coup d’essayer un week-end
    • Le problème n’est pas seulement l’absence de types, mais aussi la structure où des fonctions ou des propriétés sont définies à l’exécution, ce qui rend le débogage presque impossible
      Il faut soit répliquer les vraies données de production en local, soit se connecter en SSH au serveur pour inspecter l’état via un REPL
      Déboguer dans l’IDE était une expérience infernale
      J’ai vraiment aimé Ruby, mais après avoir vécu le débogage en temps réel, c’est devenu difficile
    • Je me demande pourquoi les grandes bases de code non statiques sont à ce point cauchemardesques
    • Aujourd’hui, avec le codage agentique (agentic coding), l’importance du langage ou du framework diminue de plus en plus
      Il n’y a plus vraiment de raison de choisir Ruby ou Python
      Python tiendra peut-être un peu plus longtemps grâce au ML, mais j’ai l’impression qu’il finira par disparaître
  • Je suis content que quelqu’un dise aussi ça publiquement
    En ce moment, je suis fatigué des architectures microservices excessives
    Le soir, je travaille sur des projets qui résolvent simplement des problèmes, sans structure inutile
    Avant, je manipulais beaucoup de structures PHP, mais Rails comme PHP ne sont au fond que des outils de résolution de problèmes

    • J’utilise RoR pour un nouveau projet depuis le début de l’année, et c’est vraiment une bouffée d’air frais
      On a l’impression que tout fonctionne « dans une boîte », comme au temps du développement avec des IDE desktop
      J’ai le sentiment de retrouver une simplicité centrée sur la productivité, loin de la gestion des composants complexes du développement web
      Et en plus, je n’ai pas besoin d’utiliser TypeScript, ce qui est un vrai bonheur. Je trouve que TypeScript est verbeux et bourré de boilerplate inutile
    • Je me demande ce que signifie STOA
    • J’ai l’impression que l’expression « la traduction entre la pensée et le code est minimale » décrit très bien l’essence de Ruby
  • Nous faisons tourner des applications Rails en production sans interruption depuis 2007
    Le secret de la longévité de Rails ne tient pas à son âge, mais à sa stabilité et à son pragmatisme
    L’idée qu’utiliser JavaScript côté back-end améliore l’efficacité a déjà été réfutée
    La plupart des changements de stack technique relèvent de l’optimisation de CV ou de l’angoisse de rater une tendance, pas de véritables besoins d’ingénierie
    Rails a continué à faire tourner de vraies entreprises en toute discrétion
    Personne ne pense sérieusement que les 3,1 millions de packages de NPM offrent forcément plus de fonctionnalités que les 190 000 de RubyGems

    • Nous aussi, nous utilisons Rails en production depuis 2011 dans deux entreprises
      Nous migrons vers Inertia + Vue.js, une combinaison si puissante qu’elle ne demande presque aucun changement côté back-end
      Le gain de productivité compense même la difficulté de recrutement
    • Le grand nombre de packages sur NPM signifie qu’il y a plus d’utilisateurs
      Et plus il y a d’utilisateurs, plus l’écosystème est sain
      Mais RubyGems contient aussi beaucoup d’anciens packages, donc la comparaison simple me paraît difficile
  • La philosophie « batteries incluses » de RoR ou Django est appréciable, mais la maintenance de vieux projets prend beaucoup de temps
    Mettre à jour un projet vieux de 5 à 6 ans rend la gestion des dépendances très lourde
    C’est pourquoi, ces temps-ci, je préfère utiliser un framework simple en Go, voire aucun framework du tout

    • Je gère une base de code Django de plus de 300 000 lignes, et je n’ai que 32 dépendances directes
      Si on n’utilise que les bibliothèques vraiment nécessaires, la maintenance reste facile
    • Le vrai problème semble être le churn, c’est-à-dire les changements permanents
      En dehors des correctifs de sécurité, je me demande vraiment pourquoi il faudrait mettre à jour
    • Avec Laravel, je rencontre rarement ce genre de problème
      J’ai monté de 5 versions majeures au cours des 18 derniers mois, et ça a été relativement simple
    • Au final, la difficulté de maintenance dépend surtout de la stratégie de gestion des dépendances
      Si on conçoit prudemment dès le départ, il y a très peu de choses à retoucher pendant longtemps
    • Je me demande si le côté « batteries incluses » ne rend pas au contraire les mises à niveau plus difficiles. J’aurais plutôt tendance à penser l’inverse
  • Je pense que l’expérience de mise à niveau est sous-estimée
    Next.js change complètement de structure à chaque version majeure, alors que Rails est bien plus stable grâce à un cycle de dépréciation progressif plus lent
    Lorsqu’on livre un produit en continu, la stabilité des interfaces compte bien davantage que le dernier paradigme à la mode

    • Seules les personnes qui ont exploité Rails sur la durée comprennent vraiment ce point
      La transition de pages vers app router dans Next.js a en pratique ressemblé à une replatforming complète
      À l’inverse, Rails propose un chemin de mise à niveau documenté et un cycle de dépréciation prévisible
      La gestion des versions de Ruby via rbenv/asdf élimine presque totalement les problèmes de décalage d’environnement
    • Le passage de Next vers app router est un bouleversement structurel si profond qu’à ce stade, cela vaut la peine d’envisager une alternative moins prescriptive comme TanStack Start
  • Cela fait plus de 10 ans que je fais tout avec Rails, du DevOps au développeur web solo, et si c’était à refaire, je ferais le même choix
    Rails est un framework propre et productif qui offre tout ce qu’il faut
    Dans l’enquête Stack Overflow, il figure toujours dans le Top 5 des stacks « qu’on voudrait utiliser pour le prochain projet »

    • Le côté « framework pour une seule personne » de Rails est vraiment séduisant
      Il n’y a presque pas besoin de se soucier de l’infrastructure, et le déploiement est simple
    • Les gens qui travaillent réellement avec Rails n’ont peut-être même pas envie de répondre à des sondages
      Au fond, ce qui compte, ce n’est pas le regard des autres, mais d’utiliser les outils qui vous conviennent
    • Rails est sorti en 2004, c’est donc maintenant un framework de plus de 20 ans
      Il est apparu un an avant Django
    • Dans l’enquête Stack Overflow 2025, Rails arrive à la 10e place dans la catégorie web frameworks « Admired vs Desired »
      Lien vers l’enquête
  • Autrefois, je pensais que Ruby/Rails était la meilleure réponse à la plupart des problèmes, et je le pense toujours aujourd’hui

  • Je n’ai jamais utilisé Rails, mais je comprends très bien la confusion de l’environnement actuel du développement web
    C’est pour ça que j’ai choisi Elixir et Phoenix en regardant vers l’avenir

    • Ces derniers jours, cinq personnes m’ont recommandé Elixir quand j’ai dit que je faisais un projet en Ruby
      Je compte absolument l’essayer pour mon prochain projet
      Qu’est-ce qui rend Elixir si attrayant, et quels points faut-il regarder en priorité quand on le découvre ?
  • Il y a 10 ans, j’ai construit le front-end de streaming d’un grand diffuseur suédois avec Rails
    Sur Heroku, on a géré plus d’un million d’utilisateurs simultanés, et ça a très bien fonctionné
    Ensuite, je suis passé à d’autres domaines comme l’infrastructure de streaming, les API, l’IA/ML, non pas parce que Rails avait échoué, mais parce que la nature des problèmes avait changé
    Rails convient aux problèmes centrés sur les modèles de données et la logique métier, tandis que d’autres langages sont plus adaptés aux problèmes centrés sur la concurrence ou l’infrastructure
    Ruby reste un langage magnifique et expressif qui me manque beaucoup

    • Moi aussi, j’adhère à l’idée de choisir l’outil adapté au problème
      Mais j’ai l’impression qu’il est difficile de se débarrasser complètement de son biais personnel envers les langages qu’on aime
      Je me demande dans quel langage tu as réalisé ton projet suivant
  • Pour ceux qui regrettent l’absence de typage statique, il existe d’excellentes solutions comme Sorbet
    On peut profiter à la fois de la productivité de Ruby, du typage statique et de l’intégration LSP
    Grâce à Shopify, le support de Sorbet est bon aussi dans Rails
    J’aime tellement cet écosystème que j’aimerais toujours travailler avec Rails
    Avec les progrès des outils d’IA, j’ai l’impression que la seule limite désormais, c’est la taille de l’imagination

    • En ce moment, le plus gros sujet dans l’IA, c’est OpenClaw
      J’ai construit à partir de là un agent e-commerce qui surveille une boutique 24 h/24 et envoie des alertes sur Slack
      Si vous faites des projets liés à l’IA, cela vaut vraiment le coup de jeter un œil à selzee.com/openclaw