Dans le cadre de mon travail chez Autrement, je bosse principalement sur du développement web en Ruby, avec l’aide du framework Ruby on Rails.

Je suis focalisé sur le développement d’une appli web (encore un eu secrète pour le moment), mais là, Autrement édite par ailleurs le site web chambresapart.fr
Le développement de ce site a commencé bien avant que je rejoigne l’équipe et il s’appuie sur le framework Symfony, basé sur PHP.

Actuellement l’équipe Chambres à Part se compose de 2,5 personnes qui sont toutes les 3 des développeurs confirmés, spécialisés sur PHP / Symfony.

Avant le lancement de la “version 1” de Chambres à Part, j’ai participé au développement de certaines fonctionnalités, mais principalement sur des aspects HTML, CSS, Javascript, cartographie Google + Maptimize…
La dernière semaine a été uniquement consacrée à du debuggage et pour ça j’ai mis un peu plus mon nez dans le code source du site et donc dans la partie “vue” (le V de MVC).

Je ne peux surtout pas prétendre connaître Symfony dans ce qu’il a de particulier par rapport à d’autres framework web (et MVC en particulier), mais je peux comparer ce que j’ai vu et ce que l’équipe raconte au quotidien avec ce que je connais et vis au quotidien depuis 3 ans avec Ruby et Rails.

De plus, j’ai développé quasi-exclusivement en PHP depuis les premiers temps du PHP3 jusqu’à PHP5, donc même si j’ai passablement oublié certains réflexes de manipulation du langage et la plupart de noms de méthodes, je pense avoir un avis assez circonstancié sur PHP.

La question

Pour le développement de la partie visible du projet sur lequel je suis mobilisé, d’autres personnes de l’équipe vont participer activement et durablement. Une question se pose donc inévitablement : Ruby on Rails ou bien Symfony ?

Notre boss comprend bien quand on lui parle de technique, avec des arguments clairs, mais il ne se sent pas (à raison) en mesure de décider lui-même d’un framework ou d’un langage plutôt qu’un autre. Il nous a donc demandé de préparer une discussion sur cette question, en apportant surtout des faits et des remarques objectives afin de tout mettre sur la table et tenter en équipe de prendre la bonne décision.

Je suis convaincu qu’il ne s’agit pas de valider ou invalider les choix des uns et des autres, mais plutôt de faire un état des lieux et s’orienter dans la meilleure décision.

Comme je suis quelqu’un de passionné, et qui ne se lance dans les choses qu’avec une forte conviction, j’ai quand même envie de convaincre que mon choix de quitter le développement en PHP pour le faire en Ruby n’est pas juste “mon choix” mais un choix lucide et cohérent.

Alors j’ai sorti un bout de papier et un crayon (ou plutôt un document “untitled.txt” et mon beau clavier) pour pondre une liste d’arguments.

Et puis je me suis dit que garder tout ça pour nous, en interne, était un peu égoïste. Pourquoi ne pas partager mes observations et mon analyse. Je ne pense pas que quiconque (au delà de notre équipe et mes copains geeks) s’intéresse à mon avis sur la question, mais un avis, ça peut donner des idées, participer à une réflexion…

Présentation factuelle de Ruby et Rails

Ici je ne présente que des points clés, du moins ceux auxquels j’ai pensé.
Je ne détaillerai pas ces points, d’autres l’ont fait bien mieux que moi.

Ruby

• 100% objet, pas de primitives
• langage concis et lisible : moins de code, moins de bugs
• langage dynamique, fortement typé
• imprégné des méthodes de tests TDD et BDD (nombreux frameworks disponibles)
• synergie avec les méthodes agiles
• Ruby en ligne de commande (IRB), pratique pour des essais…
• Rubygems : gestionnaire de paquets additionnels
• vitesse d’apprentissage
• syntaxe et idiomes riches et avancés
• meta-programmation
• inspiré des meilleurs langages reconnus : Smalltalk, Lisp, Python, Perl…
• forte implication et marques de confiance des ténors : IBM, Sun, Apple, Microsoft, SAP…
• de nombreux frameworks de premier plan : Rails, Sinatra…

J’invite à la lecture de la page de Ruby sur Wikipedia, que je trouve assez complète et claire.

Rails

• dédié au développement d’appli web
• architecture MVC
• naturellement REST
• forte incitation à DRY
• convention plutôt que configuration
• grand variété de helpers
• des outils annexes très utiles : débuggage, déploiement, monitoring…
• des environnements d’exécution bien définis et cloisonnés
• WebServices-friendly
• système strict de migration des bases de données
• framework complet accessible en ligne de commande
• variété de backend pour le cache et les sessions : mémoire, fichiers, BDD, memcached…
• I18n
• communauté très active
• documentation riche (en ligne, livres…)
• Rack middlewares => empilement de briques fonctionnelles dédiées et modulaires : cache, debug, auth…
• logging avancé et personnalisable
• fortes opinions, mais autres choix possibles : ORM, templates, framework JS…

Pour une introduction à Rails, je vous renvoie vers le le guide de démarrage pour Rails ou Rails in a Nutshell (qui est encore en beta).

Analyse subjective (mais convaincue) de Ruby & Rails vs. PHP & Symfony

Là, je sors un peu des faits indéniables pour m’aventurer dans ma propre analyse des différences entre ces 2 frameworks (et leur langage sous-jacent respectif). Cette analyse est forcément subjective et je serai ravi d’entendre des avis contraires ou complémentaires.

PHP vs. Ruby

Prenons la métaphore de la caisse à outils.

PHP est une énorme caisse, dans laquelle il y a des outils pour presque tout, tellement que ça devient difficile de tout connaître. Il n’y a qu’à voir le site de la documentation officielle où le nombre de méthodes est impressionnant, sans parler de celles des librairies standards.

Il y a souvent plusieurs outils ou variantes pour faire presque la même chose. C’est pas forcément facile de savoir lequel choisir.

Cette boîte grandi très vite, il y a régulièrement de nouveaux outils, d’autres évoluent et certains disparaissent.

Ruby est une caisse beaucoup plus modeste, qui permet de faire tout autant de chose, mais il y a très peu de doublons ou recoupements.

Les outils sont robustes, stables et surtout cohérents entre eux. Le contenu de la boîte évolue peu, rarement et uniquement en cas de forte nécessité. Même entre les versions majeures (1.8 et 1.9) il y a très forte compatibilité. Au sein de la branche 1.8 il n’y a eu presqu’aucune perte de compatibilité importante depuis plus de 3 ans (sortie de la 1.8.5 en août 2006).

Les mises à jour de Ruby, en tant que langage, sont rares (12 à 18 mois entre chaque version stable) car il n’y a pas ou extrêmement peu de bugs, elles ne concernent que des nouveautés ou améliorations de fond. La raison de ce très faible nombre de bugs et failles de sécurité sont simples : le code est soumis à des tests systématiques et poussés (c’est dans la culture de la communauté Ruby) et le code étant simple lisible et clair, il est facile de l’auditer et le comprendre et donc d’en débusquer les failles.

À l’inverse, PHP est mis à jour beaucoup plus souvent (plusieurs fois par an) et contient de nombreux correctifs de bugs en plus de nouvelles fonctionnalités. Il est reconnu que les failles de sécurité importantes ou critiques sont relativement fréquentes.

La raison d’être de PHP n’était pas d’apporter une approche nouvelle du développement mais de répondre à un besoin simple et bien identifié : traiter les données issues d’un formulaire web. La simplicité et les fonctionnalités de ce nouveau langage l’ont rendu rapidement populaire chez les développeurs web car il n’y avait plus besoin de faire des CGI en Perl pour rendre des sites dynamiques.

Face à ce gain de popularité, le langage a grandi et permis de faire de plus en plus de choses assez facilement, mais rapidement on a constaté le manque de fondations solides, en particulier sur l’aspect Objet.

PHP rivalise alors, en terme de popularité et d’audience, avec Perl, Java… et cherche alors à combler les manques et répondre aux critiques. Le résultat est plutôt efficace, mais les outils du début restent là et les mauvaises pratiques qui vont avec aussi.

Au final on a un langage riche, mais brouillon, fourre-tout, qui évolue par stratification et pas par transformation. Les fondations manquent de rigueur et de profondeur.

Ruby est un langage qui a été conçu avec une approche plus scientifique et globale. Son créateur voulait un langage moderne, plus proche des attentes de l’humain que de celles de la machine, mais qui reconnaisse et embrasse l’état de l’art, ce qui s’est fait de mieux. Il s’est donc contenté (si on peut dire) d’appliquer la parole des vieux sages dans un contexte moderne.

Ruby adopte le principe de la moindre surprise (au sens de la cohérence maximale) selon lequel le langage doit se comporter de manière à minimiser la confusion. Lorsqu’on découvre Ruby, qu’on vienne de Java, PHP ou Python, on est forcément surpris par la syntaxe, les idiomes… mais avec le temps on adopte la “manière Ruby” et plus rien n’étonne. Dans d’autres langages, même après plusieurs années d’utilisation, on est parfois étonné ou dérouté par certains fonctionnements.

La syntaxe du langage est au service de son utilisateur, en favorisant la lisibilité et la concision. La simplicité des outils de base permet d’apprendre vite et de savoir rapidement lequel utiliser.

Ruby est bâti sur des fondations robustes et très strictes ; celles du tout Objet (il n’y a pas de primitives), de la meta-programmation, du typage dynamique mais fort…

Symfony vs. Rails

Ruby on Rails est issu du développement d’une application web (Basecamp). Son créateur voulait se lancer dans le développement web et a cherché le langage avec lequel il se sentait le plus à l’aise et il s’est arrêté sur Ruby. Il a ensuite échafaudé un framework dédié au web en tirant réellement parti de ce que permet Ruby.

La démarche partait d’un objectif/besoin connu, il fallait trouver l’outil adapté pour l’atteindre.

Rails ne serait pas ce qu’il est sans Ruby. On ne peut pas recréer Rails sur un autre langage sans faire des tours de passe-passe et en perdre l’essence.

Symfony est issu du manque de bon framework web en PHP. Son créateur a voulu reprendre les bonnes idées d’autres frameworks (surtout Rails) sur d’autres langages pour les adapter sur PHP.

La démarche semble différente et partir d’un langage connu sur lequel construire en s’inspirant de références.

Pour ce que j’ai pu en voir et pour que Symfony ait le succès qu’il a, son développeur principal et la communauté qu’il a agrégée ont forcément accompli quelque chose de remarquable.

Pour autant, j’ai le sentiment que le plus grand handicap de Symfony, c’est PHP.

Conclusion

Au final, on sent que j’ai les idées bien arrêtées. J’espère ne pas avoir faire preuve de mauvaise foi ni avoir dit trop de bêtises.

Il m’arrive de dire que telle techno ou tel produit sont nuls. Mais pour le cas de PHP (et donc de Symfony), je ne dis pas que c’est nul et bon aux orties, au contraire.

Je dois certainement mon parcours de développeur web à PHP et à ce que j’ai pu faire avec. J’ai juste l’intime conviction d’avoir trouvé une évolution, une suite, qui me permet d’aller plus vite, plus loin, avec plus de plaisir/passion.

C’est un peu comme de passer de CVS ou Subversion à Git ou Mercurial. Vu de loin c’est la même chose, mais de près, ce sont 2 générations d’outils sui marquent un véritable progrès.

---

Mise à jour 1 : Au terme d’une longue réunion d’équipe, nous avons choisi une approche à 2 têtes. Le premier projet (Chambres à Part) reste évidemment développé avec Symfony (donc en PHP) mais le second sera entièrement développé avec Ruby on Rails.

Évidemment, je pense que c’est le bon choix. Pour moi, c’est surtout le bon choix technologique, pour toutes les raisons que j’ai déjà développées plus haut.

Du point de vue de la stratégie d’entreprise, je trouve que la prise de risque est modérée et ça va nous mettre dans une situation de réelle fusion et enrichissement des compétences.

Pendant les prochains mois, ceux parmi nous qui “viennent de Symfony” vont devoir apprendre de nouvelles choses en mettant à profit leurs années d’expérience en développement et particulièrement avec un framework MVC… Le challenge sera de tirer le plus profit de cette expérience proche tout en “embrassant” les particularités de Ruby et de Rails.

Quelque part, ça va me mettre en situation de formateur, ce qui est très excitant mais aussi une responsabilité forte. Mais comme je suis absolument passionné par ce que je fais et connais, je vais me régaler dans cette partie de mon boulot.

Par ailleurs, cette juxtaposition d’outils va me permettre de voir plus en détail l’univers de Symfony et les évolutions de PHP (depuis que je l’ai laissé de côté). Même si je ne vois pas mon avenir de ce côté là, ça me forcera à être un peu moins monocorde.

Enfin bon, je suis bien content que la balance ait penché, non pas de mon côté (ça serait une marque d’égo) mais du côté que j’ai choisi.

Mise à jour 2 : Vous trouverez sur le site de Ruby une courte liste des similitudes et différences à quoi s’attendre en passant de PHP à Ruby.

---

Commentaires

Bertrand 2010-04-27 09:35:07

Excellent, merci pour ce bel article même pas orienté (;-)) ! en pleine réflexion de création d’une plateforme de eCommerce la question se pose évidemment du langage à adopter et je vais continuer à prospecter même si j’ai déjà un faible pour Ruby.

mon concept étant novateur et nécessitant bcp d’interactivité web/utilisateur, je cherche une solution dynamique permettant de choisir des modifications de page sans rechargement de celle-ci (et que le code soit le plus léger possible bien sur !).

Pour le moment je tatonne, si tu as des idées je suis preneur ! Merci, je vais suivre les différents liens pour me forger une opinion plus forte !

colinux 2009-11-03 10:21:55

Tes arguments me semblent tout à fait recevables.

Les points forts que tu énumères à propos de Ruby, on les retrouve aussi dans Symfony+Doctrine. Faudrait comparer chacun d’entre eux au sein des frameworks pour avoir une réelle comparaison entre les 2 de ce point de vue là

En fin de compte dans Symfony on utilise presque plus de PHP en terme de fonctions / méthodes. C’est pour moi la preuve que Symfony sait plutôt bien masquer les gros défauts de PHP en ayant construit une API efficace au-dessus de PHP. Apprendre Symfony revient presque à apprendre un autre langage.

En revanche c’est vrai que la syntaxe et les limitations de PHP (surtout côté objet) se retrouvent forcément dans Symfony, et comme tu le dis c’est son plus gros handicap vu qu’il doit faire avec et ne peut pas non plus faire que des miracles.

NiKo 2009-11-03 11:03:10

Difficile de contrer tes arguments dans la mesure où je partage les critiques que tu adresses à PHP.

Symfony est effectivement à mon sens une sorte de gros patch en surcouche à PHP, pour obtenir une API unifiée, efficace et productive, mettant en oeuvre nombre de bonnes pratiques d’architecture souvent issue d’autres langages/frameworks comme tu le soulignes effectivement. Symfony est en quelque sorte le liant qui manque entre PHP et l’industrialisation et la gestion de la qualité (mais comme peut l’être le Zend Framework d’ailleurs).

Maintenant je pense qu’il faut que vous (et particulièrement ton patron) n’oubliez pas un point crucial à l’heure de faire un choix sur une technologie : la disponibilité des compétences adaptées sur le marché. Dans un monde idéal, les compétences en Ruby/Rails (ou Python/Django d’ailleurs) seraient pléthoriques, mais ce n’est malheureusement pas le cas (en France tout du moins).

Le PHP, dans sa version 5, est maintenant très établi en entreprise, les outils sont matures et les organismes de certifications existent et permettent de s’assurer relativement simplement de la maîtrise des concepts de base du langage par un développeur. C’est une réelle force dans les entreprises, mais aussi vis à vis de leurs clients, qui cherche bien souvent (et à juste titre) à être rassurés quand à la maintenabilité des produits qu’ils commanditent à un prestataire, et notamment la capacité de reprise du code par des équipes tierces en premier lieu. De la gestion de risque, quoi.

Je sais bien que cet aspect des choses hérisse le poil de l’architecte passionné, lui qui a à coeur de mettre en oeuvre les technologies et outils les plus adaptés à son exigence de qualité tel qu’il la perçoit intimement, mais malheureusement les données du jeu sont bien souvent plus complexes que ça à l’heure de mettre en jeu la pérennité d’un dispositif dans le temps - et de signer le chèque qui va avec.

Maintenant, nombre de petites boîtes parient sur des technologies de niche avec un certain succès et prouvent qu’il est possible de pousser une technologie en laquelle on croit et faire du business avec ; certainement un peu moins facilement qu’avec des outils ayant plus pignon sur rue comme Symfony en France aujourd’hui.

Jérémy Lecour 2009-11-03 11:15:39

@NiKo Merci de ta réponse riche.

Pour la question du choix stratégique et de la disponibilité des compétences, c’est clair que ça n’est pas forcément évident. Dans une boîte précédente, j’ai adopté Rails aussi et l’équipe a du exploser et aujourd’hui ça n’aide pas forcément. En même temps le gain de production permet aussi d’avoir atteint un niveau qui n’était pas forcément atteignable sans. Le bilan est donc partagé.

Mais en ce qui nous concerne si nous adoptons Ruby et Rails pour le sujet en question, ce sont du coup plusieurs personnes qui vont acquérir ces compétences. On aura donc moins de risque de dépendance.

Jérémy Lecour 2009-11-03 11:23:08

@Niko pour la question du recrutement et de la validation des compétences, je dirai que je juge sur pièce.

J’en vu des gens qui avaient des “certifications” et qui en réalité n’étaient pas de bons développeurs. À l’opposé, en regardant ce qui est produit, on a une vrai vision de ce dont est capable un développeur. Si quelqu’un me propose ses compétences, je lui demande s’il a un compte GitHub ou Bitbucket? est-ce qu’il a créé un projet ou une lib ? est-ce qu’il contribue à des projets connus ?

C’est un peu comme dans l’univers du BDD où on se concentre sur le comportement du code plutôt que sur son état (c’est un un thème vaste). Ça me paraît plus pragmatique et pertinent pour nos besoins.

Jérémy Lecour 2009-11-03 11:29:57

@colinux Je comprends bien que Symfony masque PHP et c’est tant mieux.

En revanche, j’ai pu voir des choses dans Symfony qui me choquent. Il y a notamment beaucoup de choses à déclarer, configurer, … alors qu’on peut dégager des comportements génériques (certes modifiables). C’est la question du DRY si chère à Ruby et à Rails.

Un autre exemple : la déclaration des routes. Il m’a semblé qu’il y avait une forte présence des classes Model dans cette partie. Je trouve ça étonnant sachant que le Routing passe la main au Controller qui prend ensuite en charge les questions de View et Model.

Je n’ai pas d’autres exemples en tête pour le moment, mais ça n’est pas tout ce qui m’a étonné/perturbé.

NiKo 2009-11-03 11:38:28

@Jérémy Lecour On est d’accord, recruter un bon profil prend de toute façon du temps, et c’est toujours une prise de risque à un moment… a fortiori s’il n’y en a pas beaucoup de compétences sur le marché ;) De plus former une équipe complète à un langage + un framework n’est pas chose aisée, et là encore, prend énormément de temps (et donc d’argent).

Dans votre cas, vous semblez déjà posséder en interne des compétences, apparemment pointues et opérationnelles, en PHP/Symfony. Pourquoi faire fi de cette richesse ?

Si j’étais vous, et si j’avais la visibilité pour le faire, je continuerai à exploiter cette compétence interne (qui fait partie du capital humain de l’entreprise, et une vraie valeur ajoutée à l’heure d’envoyer une réponse à des appels d’offres) et je mettrai en parallèle des ateliers de prise en main sur d’autres technologies, comme Rails mais aussi pourquoi pas comme Django ou d’autres. Ça permet de voir ce qui se fait ailleurs, de s’enrichir, et de changer de point de vue. Ça peut apporter un peu d’air frais, à peu de frais. Et n’empêche pas de mettre en oeuvre concrètement ces technologies sur des petits projets en production pour commencer, pour monter progressivement en puissance au fil du temps ; ça permettrait aussi de pouvoir comparer les technos sur du factuel, avec une prise de risque minimum et très contenue.

Just my two cents.

Jérémy Lecour 2009-11-03 12:21:01

@NiKo Clairement, on en est là.

On ne renoncera pas à ce qu’on a déjà fait avec PHP/Symfony, ni aux compétences qu’on a sur ces sujets. On ne renoncera pas non plus au pendant Ruby/Rails.

On n’a pas vraiment besoin de petits projets pour évaluer la pertinence de Rails. Entre autres projets livrés, j’ai mené l’équipe technique de http://neomarco.com qui est complètement développé en Rails, et je travaille sur le back-office de notre second site en Rails.

Pour les comparaisons entre les 2 produits, on le fait implicitement tous les jours en voyant comment les choses sont faites dans l’un par rapport à l’autre, …

À part la “zone d’anxiété” (qui correspond à la période où il faut se lancer d’une de la nouveauté, dont ne mesure pas immédiatement les bénéfices, toute la lecture nécessaire, …) je ne vois vraiment pas quels sont les oppositions réelles.

Et puisque tu parles de Python/Django, je les place dans le même panier que Ruby/Rails, mais pas du tout PHP/Symfony. Je n’ai jamais vraiment codé en Python, mais j’ai le sentiment que c’est un langage de la même trempe que Ruby. Ils se démarquent tous les 2 fortement de langages type PHP. Django dispose d’atouts forts et de poins faibles par rapport à Rails.

Mais je n’ai pas du tout senti ce plaisir à lire du Python comme je l’ai senti immédiatement avec Ruby et mon choix n’a tenu qu’à ça. Mais comme 3 ans plus tard, je ressens toujours autant de plaisir à coder du Ruby, je me dis que je n’ai pas fait un mauvais choix. Ça ne veut pas dire que je pense que Ruby est mieux que Python, juste que je préfère Ruby à Python.

Si je devais me lancer dans la découverte d’un nouveau langage, ça pourrait tout à fait être Python, ou bien des langages types Erlang, Clojure, … qui m’apporteraient une nouvelle vision du développement.

NiKo 2009-11-03 12:56:37

> je ne vois vraiment pas quels sont les oppositions réelles.

La disponibilité des compétences sur le marché, donc.

Maintenant, quel que soit votre choix, je vous souhaite toute la réussite possible.

Joel 2009-11-03 14:18:29

Moi je le ferais à la façon du financier.

Quel est le gain apporté par Ruby (en terme d’efficacité)? Quel est le cout de formation des équipes en places? Quel est le temps d’adaptation d’un développeur ? Quel est le cout journalier d’un développeur?

Et tu tu calcul le seuil de rentabilité: combien de jours de devpt il me faut pour rentabiliser une migration vers Ruby.

factuel

Joel 2009-11-03 14:22:57

con de clavier qui me post tout seul !!! :-)

by the way: le seul framework zero bug? papier crayon boulier,et pigeon pou s’envoyer des messages !!!

Jérémy Lecour 2009-11-03 18:04:58

@Joel

Effectivement c’est une approche, mais le risque est bien de prendre la mauvaise décision car des variables de l’équation sont mal quantifiées. Or on sait bien que les développeurs sont de très mauvais évaluateurs du temps nécessaire (trop optimistes ou pessimistes mais jamais réalistes).

Par ailleurs, je ne pense pas qu’on puisse déduire le seuil de rentabilité comme ça, car les choix techno ont des impacts directs (temps de dev pour une fonctionnalité donnée, …) mais aussi des impacts indirects, y compris comportementaux. Par exemple si une techno est fun, elle donnera plus envie à ses développeurs d’avancer, alors que si elle est casse pieds à utiliser, on va trainer les pieds et tout ça indépendamment du facteur de productivité des technos en question.

En résumé, je crois pas au choix basé uniquement sur des critères rationnels. Il ne faut pas oublier qu’au final ce sont des humains qui utilisent ça, qui en plus sont dans ce métier par passion, … donc avec des comportements et des attentes qui vont souvent au delà du rationnel.

Jérémy Lecour 2009-11-10 14:56:46

J’ai ajouté une mise à jour à l’article car nous avons tranché en faveur de Ruby on Rails.

Benoit 2009-11-18 08:49:17

Je rejoins ton point de vue sur Ruby. Ayant commencé le développement web par PHP, avec une vraie passion pour ce language, lorsque j’ai été introduit à Ruby, j’ai de suite été séduit. Ceux qui aiment le joli code devraient aimer Ruby. Un conseil à ceux qui voudraient se mettre à Ruby on Rails, apprenez d’abord Ruby… Il y a beaucoup de ressources pour apprendre Ruby “alone”. Ainsi, quand vous vous mettrez à Rails, vous discernerz aisément les composantes natives de Ruby, et saurez que si Rails est si génial, c’est principalement grâce à la puissance de Ruby!

J’ajouterais que développer en Ruby m’a ouvert à de nouveaux paradigmes de développement, notamment le “behavioral driven development” (avec des outils comme Rspec et Cucumber) qui ont considérablement changé mes méthodes de travail.

Mais ne pas se méprendre : mieux vaut maîtriser Ruby ET PHP, car on n’est pas toujours autorisé à choisir le language sur lequel on bosse…

Jérémy Lecour 2009-11-18 13:00:14

@Benoit Effectivement on est d’accord ;-)

J’ai écrit un article sur mes conseils pour apprendre Ruby et Rails

Pierre de La Celle 2010-03-13 23:58:01

bigre, c’est passionnant!

Comme je ne veux pas mourrir con, je commence tout de suite les tutos ruby (23h57, je suis chaud).

Merci à toi pour toutes ces infos, et à Nikko pour le pragmatisme.

Michel 2010-09-09 19:28:09

Bonjour,

Discussions très intéressantes…

Voici quelques réflexions personnelles qui peuvent éventuellement enrichir le débat.

Mes expériences: sur Rails version 2 et sur Django, pour développer des générateurs d’applications élémentaires, avec des couvertures fonctionnelles modestes mais comparables dans les deux environnements.

Conclusions:

1) J’ai abandonné Rails 2 au profit de Django, essentiellement pour des questions de souplesse et de philosophie de l’architecture. Tant qu’on est dans les bons ‘Rails’, tout va bien, mais très difficile quand on en sort, géné par la disparition des aspects magiques… Django est de ce point de vue beaucoup mieux architecturé et souple à mon avis… Et cela semble avoir été confirmé par l’évolution de Rails 3, qui a pris beaucoup plus de temps que prévu et qui vise justement à refondre l’architecture. Concernant Rails 3, je ne peux pas me prononcer et donc ce qu’il faut retenir de tout ça, c’est surtout cet aspect de couplage faible et souplesse de l’architecture…

2) Penser au cloud… Python/Django est très bien supporté sur google app engine…

3) J’ai bien aimé la mise en évidence de l’aspect ‘méta-programmation’, probablement plus facile avec Ruby et Python. Après un certain temps, on se rend compte que l’on ne veut pas développer une application mais en fait toute une famille d’applications, qu’il faudrait pouvoir particulariser facilement (d’où mes expérimentations…)

4) La façon dont je perçois actuellement le problème crucial est plutôt comme une question de communication… D’un côté, toutes ces réflexions architecturales sont très complexes et subtiles et d’un autre on devrait réussir à les communiquer au mieux à la grande masse du marché qui a plutôt un background de type PHP avec tout ce que cela implique… Quel besoin(s) critique(s) pouvons nous mettre en évidence pour appuyer nos arguments??? (Dans leur monde, il leur semble qu’ils peuvent tout trouver…)

Vos commentaires seront les bienvenus!

Alain Feler 2010-10-05 18:13:54

Vous dites “Son créateur [de Rails] voulait se lancer dans le développement web et a cherché le langage avec lequel il se sentait le plus à l’aise et il s’est arrêté sur Ruby.” Ce n’est pas tout à fait vrai : David Heinemeier Hansson, le créateur de Rails, était déjà un professionnel du développement web, en PHP, quand il a décidé de passer à ruby pour créer Rails. Il le dit lui-même dans une vidéo qu’on trouvait sur le site de Rails : il estimait les possibilités de PHP, en particulier les possibilités d’introspection, intrinsèquement insuffisantes pour un travail de ce type. — A part ça, j’aimerais bien savoir quel genre de cartographie vous faites avec Rails, et comment.

Jérémy Lecour 2010-10-06 06:35:35

@Alain C’est juste, j’ai fait un raccourci un peu rapide ;-)

J’ai ajouté des représentations cartographiques dans des applis Rails pour représenter la répartition géographique des points d’intérêts (correspondants aux données du site), avec des calculs de distance, … J’ai presque toujours utilisé la librairie Geokit.

Je suis même en ce moment en train de porter le “plugin” Geokit-rails (pour connecter Geokit et ActiveRecord) et le rendre compatible avec Rails 3 http://github.com/jlecour/geokit-rails

Shinigami online 2010-10-07 23:03:35

Je salut tous les personnes qui participes a cette discution je suis pas un ingenieurs en informatique ,je suis un marketeur mais je suis interessé par ce qui a été dit dans cette discution , Alors je vous pose une question critique pour moi je veux faire un super site web ou plutot un systhème d’information web beaucoup de traffic par jour des millier et des payement transaction online ainsi que la possibilité de mettre des photos video ect… et je me demandé qu’est ce qui sera le mieux adapté pour mon site un web avec du Ruby ou Bien un site web avec du PHP et le quel des deux le plus chere a faire développer et le plus performant le meilleur quoi coté rapidité de navigation ect… merci a tous de m’eclaisir ca sera très chic de votre part cordialement Marketeur Shinigami Online

Nico 2011-06-11 13:19:15

Article intéressant, mais il faudrait signaler que certains aspects ne sont plus d’actualités du fait des mises à jour.

Maintenant il y a PHP5.3, Symfony 2 et Doctrine 2 et ces 2 derniers n’ont plus rien à voir avec la version 1.

Pour PHP on attend toujours une rupture mais à cause du “clivage entre les contributeurs progressistes et les ceux très traditionalistes” (dixit Mageekblog) c’est pas pour demain.

Maxime Corson 2012-08-06 14:48:47

Nous sommes en 2012, l’article a été rédigé en 2009 et la question est quant à elle toujours d’actualité (même si le contexte à quelque peu évolué - cf. Symfony2). Article et débat très intéressants.

benoit 2013-03-23 23:48:44

Article intéressant, mais très téméraire je trouve d’opter pour une techno très différente quasiment du jour au lendemain, avec en plus la nécessité de former une équipe entière ! Sinon maintenant on est en 2013 (votre article date de 2009), php a continué a évoluer, on est à sa version 5.3.4, même si le langage garde ses défauts de jeunesse, il a beaucoup évolué et niveau objet il commence à être très bon, de plus couplé avec un framework tel que Zend Framework 2 , il y a de quoi faire du bon travail. Mais je l’avoue, découvrant tout juste Ruby, ce dernier semble infiniment plus élégant et donne vraiment envie de s’y mettre…

Jérémy Lecour 2013-03-24 01:19:44

Salut Benoît et merci pour le compliment.

Ça fait effectivement plus de 3 ans que cet article a été écrit et que la décision a été prise chez nous. À l’époque déjà nous n’étions pas des débutants dans notre métier, ni dans PHP et Ruby. J’avais moi-même à l’époque plus de lignes de PHP derrière moi que de Ruby.

Je conviens que beaucoup de choses ont évolué dans l’écosystème PHP et certainement pour le mieux. Je suis encore aujourd’hui totalement convaincu qu’on peut faire de belles choses en PHP. Symfony 2 est un très bel exemple. D’ailleurs, pour un des développeurs de l’équipe, trop attaché au PHP, la greffe n’a pas prise et après presque 2 ans d’efforts, il est parti pour refaire du PHP, pour son plus grand plaisir et avec beaucoup de succès semble-t-il.

L’écosystème Ruby a également continué d’évoluer, pour le mieux, et nous avec. Depuis cet article, nous avons grandi, continué d’écrire du code sur les bases d’origine, écrit beaucoup de code sur des bases nouvelles, mais toujours en Ruby. À ce jour, nous pouvons dire que nous ne regrettons pas ce choix. Ça ne veut pas dire que nous n’y serions pas arrivé avec un choix basé sur du PHP, mais nous avons choisi Ruby et nous en sommes ravis.

Nous sommes même sur le point d’hériter une grosse quantité de code (du PHP, mais pas dans un beau framework !) et nous savons déjà qu’à terme il sera transformé en Ruby pour s’intégrer au mieux dans nos compétences, nos habitudes, nos processus et notre système.

Jérémy Lecour 2013-03-24 01:21:36

Maxime,

Je viens (tardivement) de répondre à ta question, dans mon commentaire à Benoît.

En gros : la question n’est plus d’actualité, on ne regrette pas le choix de Ruby et on en est plus convaincu chaque jour.

Olivier C 2015-01-22 07:24:47

Bonjour. Je tiens à vous remercier pour votre article. Je n’ai pas encore choisi de faire le pas vers RoR plutôt que vers Symfony2, surtout pour une question de support et de documentation en français. Mais je dois dire que j’ai trouvé vos arguments en faveur de Ruby très pertinents. Après bien sûr, comme alternative à php pour le web, on entend de plus en plus parler de Node.js. Mais en attendant…

Julien Breux 2014-06-30 23:08:31

Personnellement, si j’ai le choix, je fais du R[oR]. Si je n’ai pas le choix, et si je fais du PHP, je fais du Symfony2.

Par contre, @Aurélien Lequoy, pour contribuer au langage PHP, je ne suis pas d’accord avec toi. Une POO dont les natifs types ne sont pas objets… comment travailler efficacement… En développent sa propre classe “String” pour utiliser des “fonctions globales” du langage pour compter le nombre de caractères et autres :/.

PHP a de très beaux jours devant lui, c’est certain… mais laissons-le continuer sa prise de maturité.

Aurélien LEQUOY 2014-05-03 12:23:25

Pour l’histoire symphony existait vant rails, les premières inspirations ont été dans le sens inverse.

Après cette article est maintenant outdated sur pas mal de point et le modèle objet de PHP n’a plus rien à envier à n’importe quelle langages.

Duchamps 2016-04-19 12:54:38

Merci pour cet article. Moi j’ai opté pour le Symfony 3 car j’ai assez de connaissance sur ce type de Framework. Cependant, j’ai été aidé par un tutoriel en vidéo sur http://www.alphorm.com/tutoriel/formation-en-ligne-symfony-3-les-fondamentaux pour sa manipulation. Merci pour le partage.

Offensive Digital - Agence Digitale 2016-01-02 10:48:20

Je suis pas sur qu’il est de bon ou de mauvais choix. Toutefois je rejoint de @niko et je me demande 6 ans prés ou est-ce que vous en êtes ?

Jérémy Lecour 2016-01-05 14:09:41

6 ans après, on est toujours 100% Ruby. Il est difficile de faire une retrospective complètement objective, mais on n’a jamais regretté notre choix.