Discussion :

[Invité]

La raison principale, à mon avis, de la baisse de popularité de Ruby on Rails est le fait que ce framework se voulait la version idéale d'une démarche développement MVC côté serveur qui n'est plus d'actualité aujourd'hui.
Une grosse partie du développement est réalisée côté client (en javascript). Le développemnt côté serveur consiste essentiellement à développer un api qui sera exploitée par la partie client. Bien évidemment ces API peuvent être complexes et nécessiter des développements importants. Néanmoins, Ruby on Rails apportait essentiellement une valeur ajoutée dans le cadre d'un développement intégré (convention over configuration) et beaucoup moins pour le développement d'une API. D'autant plus qu'il semble que le langage Ruby ne soit pas nécessairement très performant (je dis cela avec des pincettes car je n'ai pas vérifié récemment les performances).
A partir du moment où une grosse partie des développements est réalisée côté client avec les outils associés, l'ajout de la stack RoR (avec ses contraintes spécifiques) est beaucoup moins excitant à moins d'être amoureux du langage Ruby.


Node.js comme environnement d'exécution javascript pour le développement de la partie serveur offre des atouts non négligeables:

• Le moteur d'exécution javascript sur lequel s'appuie node est très performant. Et on ne parle pas là du fait de l'approche asynchrone mais le performance pure des instruction, boucles, etc... Google fait un gros travail d'optimisation.
• Son event loop qui est beaucoup plus efficace que l'utilisation de threads pour gérer de nombreuses requêtes.
• L'utilisation de Javascript qui implique une démarche asynchrone au coeur du développement incite à une approche plus performante pour ce qui est IO.
• De nombreux outils utilisés pour le développement client s'appuient sur Node.js (gulp, etc...)
• Tout le monde semble l'adopter y compris Microsoft qui lui offre un support non négligeable (azure, vscode, visual studio, ...)
• De nombreuses applications nodejs sont maintenant en production et de nombreux outils de monitoring,etc ... sont en train d'éclore.

Enfin, un point très important, si l'on considère comme acquis le développement d'applications web sur la base d'un framework javascript côté client, c'est le développement du concept d'applications javascript isomorphiques. C'est à dire qui peuvent s'exécuter aussi bien côté client que côté serveur. Des avancées importantes sont faites sur le sujet. Cela fait partie des objectifs d'Angular 2.


Javascript - le langage
Oui, le langage dans sa version actuelle n'est pas nécessairement génial.
Effectivement, la volonté des différents acteurs d'imposer leur technologie, la volonté de ne pas se tirer une balle dans le pied a empêché l'éclosion d'une démarche qui ne relève pas du bricolage.
Néanmoins les choses sont en train de changer rapidement et ecmascript 6 fait enfin entrer le langage javascript dans l'ère de la modernité...

Ajourd'hui, l'expérience de développement avec node.js en utilisant typescript plutôt que que du "raw" javascript est tout à fait cohérente. Presque du c#. Au détail près qu'il est plus complexe de développer dans un environnement asynchrones où il faut utiliser des callback ou promesses (ma préférence) à longueur de temps (comme par exemple faire une récursion pour une fonction qui retourne une promesse ).

[Sodium]

Néanmoins les choses sont en train de changer rapidement et ecmascript 6 fait enfin entrer le langage javascript dans l'ère de la modernité...

Sauf que comme d'habitude lorsqu'une nouvelle amélioration survient côté clients, il faudra attendre près de 10 ans avant que le parc incompatible soit suffisamment réduit pour ne plus en tenir compte.

[Invité]

Sauf que comme d'habitude lorsqu'une nouvelle amélioration survient côté clients, il faudra attendre près de 10 ans avant que le parc incompatible soit suffisamment réduit pour ne plus en tenir compte.

D'où peut-être l'intérêt des applications javascript isomorphiques pour régler définitivement le problème.
On peut noter également que se généralise la mise à jour automatique des navigateurs; ce qui permettra de simplifier le problème.
Il existe également des librairies pour émuler les fonctionnalités qui manqueraient sur certains navigateurs.
D'une manière générale les choses vont dans le bon sens.

[abelar_s]

Pour avoir développé avec node.js ET ruby on rails, comment dire...

Il n'y a aujourd'hui aucun framework qui a le nombre de fonctionnalité et la simplicité d'utilisation de Rails.

Alors effectivement, le langage Ruby est un peu lent (et encore les perfs s'améliorent au fil des version), mais franchement:

- Pas plus lent que Python (donc Django/Rails meme combat)
- Le language est beau, et ça compte lorsqu'il s'agit de passer 8h par jour à lire du code qui n'est pas le sien et à en écrire pour les autres.
- Une empreinte mémoire < à Java
- Le framework Rails est vraiment l'un des framework les plus puissants à mon sens, pour en avoir essayé plusieurs.
- Le caching est très facile à intégrer dans RoR.

Le langage viens avec des bindings C facile à utiliser, le cas d'une recherche de performance ciblée il vous est toujours possible de coder les méthodes voulues en C.

Le framework Rails propose des surcouches sur les controlleurs etc... Qui peuvent impacter la performance. En revanche, il est possible d'attaquer le framework à un niveau plus bas (en héritant de ActionController::Metal) et peu de développeurs sont au courant de cela.

En passant, les graphs font des comparaisons un coup avec Python, un coup avec Java, un coup avec Node.js... C'est un peu bête et un non-sens.

Le vrai problème que je trouve à Ruby c'est l'absence de véritable multi-threading, mais c'est une autre histoire...

Ce post est un bon résumé, même s'il semble avoir quelques années (mais merci car le post est bien) :
- l'intérêt de faire du C en FFI n'est presque plus jamais mentionné, on n'en a que rarement besoin
- l'appel à Metal n'est quasiment plus utilisé, peu de gens en ressentent le besoin aussi
- le threading marche, Rails est thread-safe depuis pas mal de versions, et JRuby fait ça très bien.

Pour ajouter quelques autres exemples :
- Twitter n'a jamais lâché Rails entièrement, presque tout ce qui est dit là-dessus est faux
- le plus gros site de cuisine Japonais (Cookpad) est en Rails et marche bien malgré des pics de charge déments à l'heure du repas
- de nombreux succès dans plein de boîtes jeunes (Drivy, CaptainTrain), moins jeunes (AirBnB, Groupon) voire leaders (Apple, LinkedIn)

Et quelques autres tendances :
- les rubyistes ont été leader sur pas mal d'aspects, Heroku et le passage au PaaS par exemple
- un max d'outils sont en Ruby ou Rails (cap, chef, puppet, sonar, GitHub, TravisCI) et font leur chemin même hors des communautés Ruby
- la communauté va bien et les conférences et meetups en sont un bon indicateur

Après je sais très bien que je ne ferai changer d'avis à personne.
++

[air-dex]

Twitter n'a jamais lâché Rails entièrement, presque tout ce qui est dit là-dessus est faux

Je persiste et signe : Twitter a lâché RoR. Ce sont eux-mêmes qui le disent : https://blog.twitter.com/2011/twitte...-now-3x-faster.

À la fin de l'article ils disent que leur ancien serveur RoR sert encore et que la prochaine étape est de s'en débarrasser. Le billet de blog étant vieux de 4 ans, cela m'étonnerait fortement que le serveur RoR soit encore en service.

[Vadrygar]

Je persiste et signe : Twitter a lâché RoR. Ce sont eux-mêmes qui le disent : https://blog.twitter.com/2011/twitte...-now-3x-faster.

À la fin de l'article ils disent que leur ancien serveur RoR sert encore et que la prochaine étape est de s'en débarrasser. Le billet de blog étant vieux de 4 ans, cela m'étonnerait fortement que le serveur RoR soit encore en service.

De ce que j'ai pu en lire sur ce billet, c'est juste la partie recherche qui abandone RoR

[abelar_s]

Je pense que l'état de Twitter n'est pas représentatif, mais regardons.

Il y a des jobs ouverts chez Twitter en Ruby
https://about.twitter.com/fr/careers...o5k5Xfwb%2CJob

Et des contributions Ruby par la team Twitter : https://twitter.github.io/
CLI, Web, une intégration headers Rails voire ActiveRecord
https://github.com/twitter/twurl
https://github.com/twitter/spitball
https://github.com/twitter/twitter-cldr-rb
https://github.com/twitter/secureheaders
https://github.com/twitter/activerec...utation-system
Il y en a d'autres mais je ne compte que les actives depuis moins de 6 mois.
(cela dit pourquoi contribuer à ActiveRecord si tu n'utilises pas Rails ?)


Contrairement aux devs qui érigent leur langage/framework favori en religion,
il semblerait que l'ingénierie Twitter soit plutôt en mode "adapter ce qu'on peut
à nos besoins si c'est pratique et rapide".

Ça ne me dérange pas que Rails sorte d'une partie de ce besoin,
surtout sur Twitter qui est un cas ultra-particulier. Je pense que moins d'une
startup sur un million a besoin de ce genre de scaling (et pourtant Rails les
a aidés à se lancer). Si AirBnB et Groupon n'ont pas eu besoin de sortir de
Rails, c'est quand même rassurant en terme de perfs ou de skill de hosting.


Bref, je savais que je ne convaincrais personne, mais pour quelqu'un qui
prétend sortir des chiffres indubitables (de 2011) et chercher des sources,
je suis un peu déçu. Vous avez le droit de dire "je préfère mon framework
parce que j'ai des skills, que je me sens bien, et que je nourris ma famille
avec depuis quelques années", ça ne choque personne. Mais dénigrer les
autres ? Ça n'est pas super professionnel.

++

[Cheshire_Cat]

Le pékin moyen dans notre métier n'est pas capable de coder proprement et ça ne se voit pas de prime abord... Sauf lorsqu'on monte en charge.

Avant de faire des études comparées sur la vitesse de tel ou tel langage, commençons par enseigner le code correctement à l'école.

[guy_lux]

Comparer Rails et Node, un framework fullstack et un serveur... pourquoi pas dire "Nginx c'est mieux que Symfony" tant qu'on y est ? Comparer Rails et Express, à la rigueur, ou Django et Symfony, mais là, Rails vs Node : ça n'a absolument aucun sens.

Quant à ce qui est des perfs. Franchement ? Franchement, dans le monde réel: on s'en fout. Le Hardware ça coute rien, des journées d'ingé supplémentaire pendant des années, tout au long de la vie de votre produit, parce que votre code est archi complexe, pas maintenable ni évolutif, ça, ça coute cher. Au pire, vous passez un peu de temps avec Varnish + un peu cache SQL est c'est réglé.

Quant à ceux qui disent "oui mais Twitter...". Comme si tu allais chez ton garagiste avec ta Clio et que tu disais "oui mais chez Ferrari en F1 ils font comme ça...".

Si on commence à comparer ce qui est comparable, Rails reste et demeure un outil aussi efficace que versatile et "rock solid" pour gagner du temps dans un environnement Startup. A moins que ES6 et/ou Meteor (et/ou... mettez ici vos idées sur les prochaine évolutions) suivi de près par une révolution des usages bousculent la donne, tant que ça reste "du Web" tel qu'on le connait aujourd'hui, je ne vois pas de raison pour que ça change.

[Pierre Louis Chevalier]

Quant à ce qui est des perfs. Franchement ? Franchement, dans le monde réel: on s'en fout. Le Hardware ça coute rien, des journées d'ingé supplémentaire pendant des années, tout au long de la vie de votre produit, parce que votre code est archi complexe, pas maintenable ni évolutif, ça, ça coute cher. Au pire, vous passez un peu de temps avec Varnish + un peu cache SQL est c'est réglé.

Pour les applications web qui ont du trafic c'est faux, parce que meme si tu es amateur si tu doit louer un dédié au lieu d'un mutualisé PHP ça fait une sacré différence. Quand aux grosses sociétés n'en parlons pas : au lieu de devoir payer 20 dédiés pour héberger des applications PHP pour de gros sites en RoR c'est 100 qu'il faut pour héberger la même chose. Si RoR est en baisse une fois l'effet mode passé c'est qu'il y à de vrais raisons...

[abelar_s]

Encore du FUD, encore des rumeurs infondées. La vérité :
1. Rails marche
2. les projets mal gérés ratent (Rails ou non)
3. si votre techno marche pour vous, profitez-en, gardez-la comme ça, je ne viendrai pas cracher dans votre soupe
4. tout "avantage" de Rails n'est pas une "attaque" sur votre travail ou votre compétence, alors détendons-nous


J'ai déjà donné des preuves mais s'il vous en faut encore : les applis Rails gérées correctement peuvent monter à 2000 requêtes par seconde sans souci (Basecamp) voire 17000 (Shopify, un excellent business), etc.
https://twitter.com/tobi/status/649289332587692032

Je pourrais vous envoyer des chiffres de dev et de hosting sur des projets catastrophiques sur des technos non-Rails. Est-ce que ça ajoute au débat ? Non. Donc je n'en parle pas.