Le devenir de Rails

Récemment Patrick m’interpellait à propos d’un article sur le devenir de Rails.

Plutôt que de lui répondre en privé, j’en profite pour livrer mon opinion.

Note: cet avis est purement personnel.

Si j’ai vraiment le sentiment que l’auteur cherche à faire un peu de buzz en lançant un gros troll, cela ne signifie pas que je n’ai rien à reprocher à Ruby on Rails.

La courbe d’apprentissage de Rails

L’auteur nous signale qu’en venant de PHP la courbe d’apprentissage est complexe, et encore plus dans les dernières versions de Rails (il cite la 3 et la 3.1).

Je ne suis absolument pas d’accord. D’une part on ne peut pas mettre sur la même ligne un framework et un langage. Forcément si vous venez de PHP il sera plus simple d’appréhender un framework basé sur PHP, que sur Ruby.

D’autre part, je n’ai jamais entendu personne me dire que Ruby était plus complexe que PHP.

D’un côté on a un langage lisible, à l’API claire et réellement objet, de l’autre rien de tout ça. Si vous pensez que j’exagère, je vous invite à lire quelques citations de l’auteur de PHP.

Je ne crois pas que l’apprentissage de Rails 3 soit plus compliqué que celui de Rails 2. Par contre je conçois très clairement que passer de la version 2 à la 3 nécessite un investissement important.

C’est pour cela que lors de mes présentations j’insiste sur Ruby on Rails 2.x car la majorité des développeurs Rails à venir aura certainement à travailler sur des applications Rails 2.3 existantes.

S’ils n’en ont jamais vu, car uniquement formés sur Rails 3, cela risque d’être la douche froide.

Dans tous les cas une expérience sur Ruby on Rails ne s’improvise pas.

Commencer avec Ruby on Rails c’est l’utiliser, maitriser Ruby on Rails c’est le comprendre.

L’absence de route par défaut

Je crois que c’est le plus mauvais argument que j’ai pu lire. Rails est bâti sur un certain nombre de conventions (conventions over configuration), n’importe quel bon développeur sait qu’il est préférable de designer une application restful, c’est à dire basée sur une approche ressources.

L’idée est d’exploiter pleinement le potentiel du protocole HTTP en mappant (ou en émulant) les verbes HTTP sur les actions de CRUD (post pour le create, get pour le read, put pour l’update et delete pour le destroy).

Les helpers javascript

Leur disparition ne peut qu’améliorer la base de code de Rails. C’était très clairement une très mauvaise idée, qui avait privilégié la simplicité au dépend de la qualité.

La couche javascript ne doit pas et n’aurait jamais dû être présente dans les vues. La gestion événementielle doit être déportée dans des fichiers séparés, qui pourront être minifiés et cachés.

Les choix par défaut de Rails

Rails, à l’instar de Freebsd ou Linux sont gérés, désolé pour l’oxymore, par des “dictateurs bienveillants”. Cela confère des avantages et des inconvénients. D’une part le projet évolue rapidement avec une certaine ligne directrice, d’autre part on peut se retrouver en opposition avec un choix.

Dans le cas de coffeescript je rejoins l’auteur. Je ne suis pas gêné par ce choix, car nous utilisons de toute façon coffeescript, mais je ne vois pas l’utilité d’imposer une surcouche dans la stack par défaut de Rails.

Il en va de même pour haml / sass. Ce sont des choix très personnels, qui devraient le rester.

Nombreux sont ceux qui reprochent à Rails de vouloir être trop tendance en incluant les libs ou surcouche à la mode. Je ne crois pas que ce soit l’idée. La core team Rails fait le choix d’introduire certains éléments parce qu’elle les considèrent comme facilitant le développement, productifs, plus adaptés ou répandus (par exemple pour le remplacement de prototype par jquery par défaut).

Chaque choix est discutable mais l’essentiel à mon sens reste d’avoir le choix.

C’est l’un des principaux atouts de Rails 3, être indépendant à un grand nombre de niveaux, que ce soit dans le choix du mapping objet relationnel, de la bibliothèque js, du système de tests…

De même on peut maintenant configurer son framework aux petits oignons et charger uniquement les composants requis ; permettant à Rails de développer aussi bien des petites que des grosses applications.

La documentation

Forcément si on utilise la version edge de Rails pour essayer d’écrire un livre cela risque d’être compliqué.

Je pense qu’il s’agit vraiment d’un faux procès car on a quand même beaucoup de documentation pour Rails. Si on regroupe les guides, l’api, les screencasts, les tutoriaux, et tous les éléments d’informations qu’on peut trouver via Rubyflow cela donne une source d’information considérable.

Reproche: l’aspect performance

Loin de moi l’idée de vouer un culte à Rails. D’ailleurs il y a vraiment une chose qui m’irrite: les régressions de performance.

Quand je vois ce tweet de Thomas Fuchs, cela me fait bondir. Clairement, un framework qui se veut professionnel devrait intégrer un certain nombre de tests de performances et une release ne devrait pas pouvoir sortir s’il elle ne remplit pas ces critères.

On ne peut pas transiger là dessus.

Conclusion

La volonté de Rails est, il me semble, de simplifier la vie du développeur. Parfois il s’agit aussi de pousser les bonnes pratiques (par exemple pour la minification en 3.1).

Sa force a toujours été d’avoir une approche pragmatique, donc basée sur des usages réels, et je continuerai à l’utiliser tant que son développement ira dans ce sens.

L’équipe Synbioz.

Libres d’être ensemble.