Loin de moi l'idée de critiquer, mais je n'ai pas vu le lien entre la liste des critères et la description du processus qui a mené à RoR.
J'ai plutôt l'impression que les critères furent :
1. Se faire plaisir avec une techo que j'aime bien.
2. Pas partir dans du folklo complet (choisir des outils qui tiennent au moins 5 ans).
C'est tout à fait honorable quand on est seul à développer.
Sinon, pour les critères annoncés, les 1, 2 et 3 ne me semblaient pas déterminants :
1. La charge.
Si j'en crois mon expérience, un système de cache (soit interne à l'appli, soit au niveau du serveur web) nivellera les performances. RoR a plutôt la réputation d'être lourd, en particulier avec son ORM/ODM, et Ruby 1.8 est franchement lent (Ror/1.9 est instable, non ?), mais ça ne devrait pas être bien important par rapport au cache.
2. Les fonctionnalités
Il faut de toutes façons les coder. Avec un CMS, certaines peuvent être fournies d'entrée, mais il faut forcément compléter.
3. La popularité et la longévité.
Django, Drupal, Symfony, ZendFramework, Ror. Tout ça garantissait 5 ans de suivi. Pour attirer des développeurs, AMHA, un framework/CMS PHP attirait 10x plus de développeurs qu'un produit Python, lui même attirant 2x plus de monde que du Ruby.
4. Le plaisir perso.
Le goût pour Ruby est respectable. D'où le choix de RoR et Ruby.
# Critéres de choix d'un environnement
Posté par rogo . En réponse au journal Pourquoi Ruby on Rails pour la réécriture de LinuxFr.org ?. Évalué à 1.
J'ai plutôt l'impression que les critères furent :
1. Se faire plaisir avec une techo que j'aime bien.
2. Pas partir dans du folklo complet (choisir des outils qui tiennent au moins 5 ans).
C'est tout à fait honorable quand on est seul à développer.
Sinon, pour les critères annoncés, les 1, 2 et 3 ne me semblaient pas déterminants :
1. La charge.
Si j'en crois mon expérience, un système de cache (soit interne à l'appli, soit au niveau du serveur web) nivellera les performances. RoR a plutôt la réputation d'être lourd, en particulier avec son ORM/ODM, et Ruby 1.8 est franchement lent (Ror/1.9 est instable, non ?), mais ça ne devrait pas être bien important par rapport au cache.
2. Les fonctionnalités
Il faut de toutes façons les coder. Avec un CMS, certaines peuvent être fournies d'entrée, mais il faut forcément compléter.
3. La popularité et la longévité.
Django, Drupal, Symfony, ZendFramework, Ror. Tout ça garantissait 5 ans de suivi. Pour attirer des développeurs, AMHA, un framework/CMS PHP attirait 10x plus de développeurs qu'un produit Python, lui même attirant 2x plus de monde que du Ruby.
4. Le plaisir perso.
Le goût pour Ruby est respectable. D'où le choix de RoR et Ruby.