Discussion :

[tomlev]

La moindre des choses, quand on reprend intégralement un texte sans en modifier le moindre mot, c'est de mentionner son auteur. Sinon ça s'appelle du plagiat.

http://sametmax.com/un-gros-troll-de...r-javacscript/

C'est d'autant plus frustrant que l'article en question vaut le coup d'être lu dans sa totalité, et que les articles connexes de ce blog sur node.js sont intéressants aussi et dans le thème de ce débat.

Je me disais aussi... j'étais surpris que sazearte ait fait si vite de tels progrès en orthographe

[air-dex]

Ruby on Rails est en train de rejoindre Perl au rayon des gloires passées du Web. Après est-ce pour autant qu'il faut obligatoirement passer à Node.js ? Je ne pense pas. On ne pourra vraiment le faire que si Node.js survit à sa propre mode. En attendant le mieux reste PHP, un langage mature et qui va connaître un énorme bond de performances avec sa version 7 qui arrive. Ce qui nous attend dans l'immédiat c'est plus la consécration de PHP avec PHP 7 que Node.js.

Les offres d'emploi ne veulent rien dire ici. Oui c'est un fait que les offres sur Node.js ont bondi de 120 %. Mais c'est aussi 120 % de zéro, donc pas grand chose.

Cette grande popularité du framework a incité dès ses débuts les ingénieurs du site de partage de fichiers Scribd pour le développement de cette plateforme.

[...]

Selon lui, Ruby a besoin d’un sponsor pour booster ses performances à l’instar de JavaScript qui a connu un fort attrait depuis l’implémentation du compilateur à la volée par Google. PHP a connu également des améliorations significatives avec l’investissement effectué par Facebook, ce qui a contribué à attirer les développeurs vers cette plateforme.

Incité à quoi ? Il n'est pas interdit de se relire. Et puis il y a peut-être mieux que le "sponsor" probablement proposé par Google Translate.

Justement, Node.js a été adopté par des gros du web. Ca permet d'avoir un peu plus confiance en la techno. De mémoire Twitter et Paypal ont migré sous node.js

Non. Twitter est sous Java depuis 2011, lorsqu'ils ont quitté Ruby.

Le facteur performances, contrairement a ce que l'on a voulu nous faire croire, est déterminant en informatique. Même si les performances des processeurs / mémoires ne cessent de progresser, les besoins explose et ne pas avoir besoin de puissance limite les coûts a tous les niveaux : matériel, humain et complexité (et donc fiabilité).

+1. Mais ce critère là n'est pas important là où on pense qu'il est important. Comme tu le sous-entends, les performances sont avant tout déterminées par les choix technologiques initiaux et non notre code. On n'est plus dans les années 70-80 où tout était codé from scratch et où le choix de telle ou telle instruction au moment de l'écriture du code était déterminante en termes de performances. Maintenant les perfs de nos programmes sont avant tout celles de nos choix technologiques. Point de perfs si on base nos programmes sur des usines à gaz. On ne peut alors que limiter la casse, le mal étant déjà fait.

Après il est toujours possible de faire quelque chose de non performant avec des composants performants , et c'est bien le seul cas où les perfs de notre code ont un peu d'importance. Il est important de coder en pensant performances, mais ne nous leurrons pas, ce n'est pas ça qui améliorera de plusieurs dizaines de pourcents les performances de nos programmes (sauf si on part d'une usine à gaz ).

Choisir node.js est encore un peu prématuré bien que cela constitue un très bon choix surtout pour une start-up dont le but est de développer rapidement une base fiable. Pour une PME il manque encore de perspectives a long terme et pourrait se faire balayer par des Coffee-script ou autre.
Les valeurs sure sont C/C++, Php (Hack), Python et Java ou pour des besoins très spécifiques Erlang et Awk.
Les 3 alternatives crédibles sont Javascript (node.js), Google Go voire Rust.

+ C#/.NET qui est solidement installé depuis bien des années. C#/.NET existe depuis une quinzaine d'années et est solidement installé depuis 5 à 10 ans.

Javascript est juste là par hasard.

+1. La chance de JavaScript est surtout d'avoir été au bon endroit au bon moment, seul bien au chaud dans son moteur d'exécution quand tous les plugins du Web (Flash, Java, Silverlight...) ont été déclarés persona non grata par les bien-pensants du Web.

Pire, si JavaScript dure c'est aussi que les géants du Web sont justes incapables de travailler ensemble sur quelque chose de mieux. Entre Mozilla qui persiste et signe avec le JS, Microsoft qui fait sa surcouche "TypeScript", CoffeeScript, j'en passe et des meilleurs, tout le monde est divisé et JavaScript ne peut que mieux régner. Ce qu'il faut c'est un langage avec son propre moteur d'exécution dans le navigateur à l'instar de ce que possède JavaScript. Il aurait les perfs du JS tout en étant plus appréciable. Le beurre, l'argent du beurre et le tablier de la crémière. Mais on me signale actuellement dans l'oreillette que Dart n'intéresse personne et que Google a carrément fini par jeter l'éponge. Dommage.

Gageons qu'ES6 et les prochaines normes ECMA Script aident JavaScript à faire taire ses détracteurs.

[RyzenOC]

webAssembly pourrait remplacer JS, sa m'a l'air prometteur puisque tous les acteurs (google, mozilla, microsoft...) y travail justement.

[anykeyh]

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...

[Frédéric Latour]

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.

[Frédéric Latour]

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.

[frfancha]

Il faut bien comprendre que PERSONNE ne s’intéresse à Javascript directement. Les gens s’intéressent passionnément à la programmation Web. Et il se trouve que, concernant la programmation côté client, il y a QUE Javascript de disponible...

Complètement faux, Javascript avec ses fonctions comme objet de premier niveau et son prototypae est extrêment intéressant.
Et en plus oui cela fonctione client et serveur donc on prend.

[frfancha]

la vraie question serait de savoir qu’elles sont les solutions coté serveur pour le développement web

Web API, et ce dans le language de son choix