Je pense que RoR est dépassé et que Node.js est le successeur idéal
Je pense que RoR est dépassé, mais Node.js n’est pas l'option idéale
Je pense que RoR n’est pas dépassé
Je n’ai pas d’avis
Oui mais MS comment dire "ça bouge trop" et finalement beaucoup de choses passent à la trappe car c'est une black box et les développeurs commencent à voir clair lol.
Ca fait pratiquement 20 ans que je développe en MS (.NET...).
Rappelez-vous du vbscript => finalement JS a gagné
IE => les browsers alternatifs continuent d'exister
VB => VB .NET => C#
Access => SqlServer
Les contrôles: datagrid, grid32, gridview...
Silverlight => xaml, html5
Dans tout cela le seul produit MS qui tient c'est SqlServer mais la concurrence est rude avec Oracle, MySql, MariaDb.
Et pourtant il y a du bon ailleurs, seulement ils n'en font pas la pub.
Non mais si on suivait tous les super conseils du type "faut changer de langage, le langage xxx est dépassé" ou autres fadaises du même genre, on réécrirait tout tous les deux ans. Ou même tous les six mois. Si cela en amuse certains...
Faut bien que les technos évoluent...Rappelez-vous du vbscript => finalement JS a gagné
IE => les browsers alternatifs continuent d'exister
VB => VB .NET => C#
Access => SqlServer
Les contrôles: datagrid, grid32, gridview...
Silverlight => xaml, html5
C'est de moins en moins une blackbox... maintenant la plupart des technos MS sont open-source (.NET Core, CoreCLR, ASP.NET, Roslyn...)
Et qui s'en plaindra ? Pas moi... VBScript n'a jamais été supporté par d'autres navigateurs que IE, et sur le web, tout ce qui n'est pas standard est voué à disparaitre.
Encore heureux ! Après tous les procès qu'il y a eu contre MS pour abus de position dominante avec IE, on ne va pas maintenant se plaindre d'avoir des alternatives...
C# n'est pas un remplaçant de VB.NET, les 2 coexistent
Et en quoi c'est un problème de remplacer un vieux langage (VB) par un plus moderne (VB.NET) et mieux conçu ? (bon, dans le cas de VB.NET, disons moins mal conçu)
Si tout changement était une mauvaise chose, on coderait encore en COBOL, sinon en assembleur ou en binaire...
N'importe quoi
Tu compares des choses qui ne sont pas du tout comparables. Access est fait pour la bureautique, SQL Server pour des grosses applications métier et/ou web. D'ailleurs SQL Server n'a pas remplacé Access...
Encore une fois tu mélanges les pommes et les carottes. GridView, c'est un contrôle ASP.NET, donc pour le web. Grid32 est un contrôle Win32. Tu m'expliques comment on pourrait utiliser un contrôle Win32 sur un site web ?
XAML n'est pas le nom d'une plateforme, juste une techno utilisée par un ensemble de plateformes (dont Silverlight)
Et HTML5 n'est pas une techno Microsoft, pour autant que je sache... Ce n'est pas MS qui a remplacé Silverlight par HTML5, c'est HTML5 qui est en train de remplacer tous les plugins propriétaires type Flash ou Silverlight. Alors oui, MS a laissé mourir Silverlight, mais je ne vois pas très bien ce qu'il y avait d'autre à faire... c'était un combat perdu d'avance.
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
Moi je dirais une Pub pour Node.js![]()
Bonjour.
Je suis un développeur ASP.NET de jour, et de soir, j'ai commencé à me mettre au NodeJS. L'avantage que je peux voir au Node.js est surtout l'introduction d'une boucle d'événements au coeur du Framework. Ce n'est pas nouveau, certes, mais c'est très différent. Ça axe le développement autour de l'asynchronisme et ça permet de scaler horizontalement très facilement. Bref, c'est différent et ça répond à des besoins bien spécifiques. N'utilisez pas du Node pour du travail CPU, vous serez déçus.
Maintenant, est-ce que Ruby On Rails est mort? J'aurais tendance à penser que oui, simplement à cause des performances. Je pense que c'est un aspect très important d'une application Web. Il fait qu'elle soit snappy et que le CPU puisse dormir la plupart du temps. Cela va permettre de gérer un bien plus haut nombre de requêtes. Heureusement, c'est un problème qui est adressable selon moi.
Donc le monsieur juge la qualité d'un framework en se basant sur le nombre de recherches Google. Suis-je le seul à trouver ça débile?!
C'est ce qu'il à écrit ?
Et puis il y à pas que ça comme chiffres, tiens un autre : Sondage Web 2010 (RoR 4,18%) vs sondage web 2013 (RoR 2,73%).
La grande mode de RoR c'était en 2010, après ça n’a fait que s'écrouler...Donc RoR c'est ringard depuis déjà plus de 5 ans...
Tu peut décider qu'une technologie est géniale, et cette technologie tomber en désuétude, et à l'inverse penser qu'une technologie est une pure m... pourtant ça monte en flèche... C'est justement l'objet du débat, entre autres.
Une anecdote : il y à quelques années, sur ce forum même, une personne s'est égosillée pendant quelques mois à vouloir expliquer à tous que le langage Eiffel était purement génial et qu'il allait tout écraser, et que tous le monde devait abandonner les autres langages pour faire du Eiffel, et ça en est ou aujourd'hui ? nulle part : Eiffel est toujours totalement inconnu et les gens utilisent toujours massivement Java, C#, Javascript et PHP...
Indépendamment de l'aspect technique, le fait de savoir si une technologie est à la hausse ou à la baisse est très important pour les décisionnaires, pour connaitre la pérennité des choix techniques. Une technologie à la baisse risque d'avoir moins de produits tierces disponibles, moins de développeurs qualifiés, voir peu se retrouver totalement abandonnée par les développeurs qui travaillent dessus.
Donc faire des choix de produits pour raison technologique : oui, mais pas seulement...
Sur ce si tu es développeur Ruby pas de panique, même si la technologie risque être de moins en moins utilisée ça t’empêchera pas d'avoir des contrats et d'être très bien payé (voir par exemple les développeurs Cobol qui s'en mettent plein les fouilles). Tu sera juste un développeur sur technologie ringarde, ça à son charme aussi![]()
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...Mais bien sûr. D'ailleurs PHP ne signifiait pas Personal Home Page tools et n'est pas un "hack" créé par un gars au fond de son garage.
Et tous les développeurs python maitrisent parfaitement les fermetures et le typage dynamique, qui ne sont pas du tout des "opportunités de merder".
En tout cas, çà a l'air cool d'avoir la science infuse. Tu l'as eu où, en solde chez carrouf ou d'occase sur ebay ?
Google a utilisé massivement les pages dynamiques, et devant le constat des performances misérables de la seule techno qu’il y avait a dispo, il a pondu chrome, et sa VM Javascript ultra performante. Si on avait appliqué la même techno à n’importe quelle autre langage, on aurait obtenu 10 fois cette vitesse.
C’est quand Google a enfin pu donner des perfs décentes – c’est à dire celles qu’ont d’autres langage depuis une décennie – à Javascript que les gens ont envisagé de l’utiliser sur le serveur. Encore une fois, pas parce que Javascript était une techno dont ils étaient fondamentalement amoureux.
C'est toujours étonnant de voir pris comme une attaque personnelle les critiques légitimes d'une techno.Mais bien sûr. D'ailleurs PHP ne signifiait pas Personal Home Page tools et n'est pas un "hack" créé par un gars au fond de son garage.
Et tous les développeurs python maitrisent parfaitement les fermetures et le typage dynamique, qui ne sont pas du tout des "opportunités de merder".
En tout cas, çà a l'air cool d'avoir la science infuse. Tu l'as eu où, en solde chez carrouf ou d'occase sur ebay ?
JavaScript est un langage mal fichu au développement chaotique, né par hasard, développé au petit bonheur la chance et manquant totalement de cohérence dans son implémentation.
Ca ne veut pas dire qu'on ne vaut rien en tant que développeur parce que l'on travaille en JavaScript et qu'on ne peut pas faire de grandes choses grâce à lui (tout comme on peut faire des trucs très bien sous Internet Explorer 6, en ActionScript 2 ou avec une calculatrice Casio), ça veut juste dire que l'on fait de son mieux pour tirer un maximum d'une technologie désuète mais trop présente pour que l'on puisse s'en passer.
Tous les mois apparaissent de nouveaux langages censés remplacer JavaScript, que ce soit avec un moteur d'interprétation inclus dans le navigateur ou en le compilant. Est-ce le signe d'une technologie qui va bien techniquement ?
Cà n'a rien de personnel : ce ne sont pas les langages que j'utilise au quotidien et je me fiche complètement de leur vie ou de leur mort.
Par contre quand on lance des affirmations au nom de google ou de tous les développeurs de la planète, çà me parait légimite qu'on présente quelques preuves ou arguments
A bon entendeur.
J'adore les graphiques sans légendes !
Alors dans la 1e image, le coeur se RoR s'est arrêtée, malgré les massages cardiaques. A partir de 2011, Node.js a été installé dans une région fortement sysmique.
Dans la 3e, on découvre que les développeurs JS préfèrent le bleu. Par contre les dévs Ruby débordent quand ils colorient en rouge et jaune, ils maitrisent mieux le feutre bleu. Les dévs C++ et Perl, eux, n'ont pas compris la question.
Il est naturel que certains aient un lien affectif avec un ou plusieurs langages et donc que des réactions épidermiques se retrouvent sur ce fil quand on attaque leurs langages préférés.
Il semble assez consensuel de s’accorder à dire que ROR est en fin de vie, la vraie question serait de savoir qu’elles sont les solutions coté serveur pour le développement web.
les server-side JavaScript (node en particulier) sont des solutions légères focalisées uniquement sur la dimension développement. En effet le développeur crée un server les sockets ….
En revanche les solution type JEE ou PHP avec Framework (zend symphony2 ..) sont orienté infrastructure avec un charge importante d’administration (surtout pour Java). En effet, il faut gerer un apache et un JBoss, mais le développeur peut se concentrer sur le développement des objets métier dans son conteneur (EJB par exemple)
A mon avis dans cet univers, node correspond bien à des applications de petites dimension rapide et à faible durée de vie développées par des start-up à effectifs réduit tandis que les systèmes d’information métier à long cycle de vie restent plus éligibles aux technos JAVA PHP .NET
Et ça laisse la place à tous de développer son art
Développeur Java
Site Web
Nous utilisons NodeJS en production depuis 2011 pour des grands comptes sans aucun soucis. LinkedIn, Walmart, Paypal utilisent aussi NodeJS en production.
Cela fonctionne extrêmement bien et nos clients choisissent notre application souvent pour les performances.
Rubyon Railsest 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.
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.
Non. Twitter est sous Java depuis 2011, lorsqu'ils ont quitté Ruby.
+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
).
+ 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.
+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.
webAssembly pourrait remplacer JS, sa m'a l'air prometteur puisque tous les acteurs (google, mozilla, microsoft...) y travail justement.
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...
Partager