C'est le seul bench sur vert.x vs node.js ? Pas sûr d'être convaincu s'il n'y en a qu'un seul mais en tout cas merci pour ce partage, je ne connaissais pas vert.x
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
C'est le seul bench sur vert.x vs node.js ? Pas sûr d'être convaincu s'il n'y en a qu'un seul mais en tout cas merci pour ce partage, je ne connaissais pas vert.x
Indépendamment de ce qu'apporte l'architecture "non-bloquante" de node.js à la vélocité générale d'une application web, le moteur Javascript V8 de Google est très performant comme le montre aisément les benchmarks. Google a fait un gros travail d'optimisation.Envoyé par Traroth2
En complément de ma remarque précédente concernant les performances du moteur javascript, le benchmark proposé est contesté à juste titre:
- Les différences de performances pour l'un des tests sont le résultat du fait que node.js utilise un appel qui fera que le fichier ne sera jamais mis en cache et donc lu à chaque fois contrairement à la version vert.x. L'auteur du Benchmark se défend de ne pas être responsable de la manière dont le "caching" est effectué et que cela souligne une faiblesse de node.js.
Certainement mais comme expliqué par "posteurs", quelqu'un un tant soit peu intéressé par les performances de son application ne laisserait pas node.js retourner des fichiers statiques sans mécanisme de cache s'il désire servir des centaines d'utilisateurs.- Pour l'autre test (qui n'implique pas de fichiers), il est impossible de limiter complètement vert.x à un seul core. Ainsi il est difficile de comparer si l'on ne tourne pas sur une machine/vm avec un seul core car vert.x utilisera automatiquement les ressources à sa disposition. Des tests on d'ailleurs été refaits et semblent indiquer que node.js offre de meilleurs performances par core.
- Les tests sont réalisés avec seulement 60 connexions simultanées ce qui n'est pas suffisant si l'on considère les problématiques de "scaling" de la jvm.
- Pas d'information sur la mémoire et l'utilisation CPU... ce qui est fondamental dans un contexte CLOUD ou la mémoire à un coût non négligeable.
Certains contradicteurs ont d'ailleurs refait le benchmark en cachant le fichier statique (car le test ne sert qu'un seul fichier) au démarrage (pour les 2 fx vert.x et node.js) montrant que node.js était nettement plus rapide (https://gist.github.com/courtneycouch/2652991). Ce test semble beaucoup plus significatif de la capacité du Framework à servir des données sans dépendre d'éléments externe.
D'une manière générale, bien que n'ayant aucun intérêt particulier avec node.js, ni rien contre vert.x, je trouve l'auteur des tests de mauvaise foi, et beaucoup moins convainquant que ses contradicteurs.
Quelques liens complémentaires qui permettront également de lire les contradicteurs:
http://vertxproject.wordpress.com/20...tp-benchmarks/
https://news.ycombinator.com/item?id=3948727
Pas un seul article n'arrive à la conclusion que Node.js est plus performant que Vert.x :
https://www.google.fr/#q=benchmark+node.js+vert.x
Bon, je reconnais que je ne suis pas allé plus loin que la deuxième page...
Tous les résultats de ces deux premières pages se basent sur le bench que tu as posté un peu avant. Du coup, cela fait toujours qu'un seul benchmark.
De toute façon, au delà de ces test "qui a la plus grosse", le plus important est de convaincre les développeurs de coder en utilisant cet outil. Est-ce qu'il y a des modules sous-jacents ? Est-il simple d'utilisation, d'installation, de maintenance ? A t il une bonne communauté derrière et un écosystème digne de ce nom ? Il n'y a que comme ça que vert.x sera utilisé. Pour le moment, node.js semble avoir une bonne longueur d'avance.
Ce n'est quand même pas très difficile. Il suffit de suivre le premier lien qui apparaît dans mon message (https://gist.github.com/courtneycouch/2652991).
Dans ce Gist, le développeur a légèrement modifié le programme du benchmark initial afin de cacher le fichier qui est délivré lors d'une requête. En exécutant cette version modifiée sur une small instance m1 EC1. Les résultats montrent:
- l'exécution du progtramme en utilisant vert.x ne montre pas d'amélioration de performances ce qui montre que, même sans cacher, le fichier, il y a un mécanisme de caching (under the Hood) qui faussait les résultats.
- Nodes.js est 50% plus rapide dans le cadre de ce test.
Il est intéressant de lire ensuite les commentaires (du Gist) où, à mon avis, celui qui a réalisé les tests n'est pas particulièrement de bonne foi (chacun pourra se faire son avis).
Le contradicteur a également pris la peine de monter un test en environnemnet multicore: https://gist.github.com/courtneycouch/2657432
où là encore, nodejs est à son avantage.
Vert.x est certainement très intéressant et a des atouts spécifiques mais la polémique s'appuyant sur un test maladroit où l'auteur s'est, selon moi, enfoncé dans des arguments vaseux plutôt que de reconnaître son erreur n'est pas une très bonne chose pour la crédibilité du Framework (l'auteur du bench/blog semble faire partie de l'équipe de développement de vert.x).
J'espère que vous avez maintenant les informations suffisantes pour mieux juger et que, si vous désirez me contredire, ou plus généralement tenir votre position initiale, vous le ferez avec des arguments ... hummm ... disons un peu plus consistants.
TypeScript : le sur-ensemble typé de JavaScript s’approche de la version 1.0
Microsoft sort la RC pour Visual Studio et les autres plateformes
TypeScript s’approche d’une version finale. Microsoft vient de publier la Release Candidate (RC) de son préprocesseur JavaScript.
Pour mémoire, TypeScript a vu le jour il y a de cela plus de trois ans dans les laboratoires de Microsoft, et son géniteur n’est autre que Anders Hejlsberg, reconnu pour être à l’origine de C#. Le langage a été dévoilé publiquement en octobre 2012. TypeScript est un sur-ensemble de JavaScript qui veut faire du langage la plateforme idéale pour des costaux projets : tout code JavaScript est un programme TypeScript valide et le code TypeScript est converti en JavaScript avant exécution.
TypeScript se démarque par rapport à JavaScript avec son typage statique et optionnel, un système de classes et d'interfaces, une division en modules, la gestion de l'importation de fichiers, la prise en charge des génériques et bien plus.
« JavaScript a été conçu pour les applications de 100 lignes de code, et non pour les applications ayant de milliers de lignes de code », estime le créateur de TypeScript. La RC du langage apporte des améliorations de performances, de la fiabilité et introduit un compilateur permettant une gestion aisée des centaines de milliers de lignes de code.
TypeScript a été développé comme un projet open source, et Microsoft promet de le faire fonctionner sur n’importe quel navigateur et OS.
La RC de TypeScript 1.0 a été intégrée par défaut dans Visual Studio 2013 Update 2 CTP 2 qui a été publié parallèlement. L’outil est également disponible comme une extension pour Visual Studio 2012, 2013, et comme un package NPM (Node.js) pour les autres plateformes. Son code source est téléchargeable sur GitHub.
La version finale de TypeScript sortira au même moment que Visual Studio 2013 Update 2, au printemps prochain.
Télécharger TypeScript
Source : Blog MSDN
Et vous ?
Vous souhaitez participer aux rubriques .NET ? Contactez-moi
Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
Mon blog, Mes articles, Me suivre sur Twitter
En posant correctement votre problème, on trouve la moitié de la solution
...et restriction du Javascript... Pour les "typages forts" j'utilise les langages conçus pour.
Sinon voilà le résultat : TypeScript -> http://jsfiddle.net/8ez4x/12/
Pour ceux qui aiment le 'typage fort"je déconseille de mixer du TypeScript avec du Javascript
[edit]L'interpréteur TypeScript effectue une bonne protection de ces problèmes, c'est l'usage de ce mécanisme en javascript qui est dangereux[/edit]
J'aime travailler avec javascript, j'aime travailler avec java; mais je n'aime pas faire des contorsions pour transformer Javascript en Java (et l'inverse serait tout aussi illogique)
C'est un langage très intéressant avec de grandes possibilités. Comme il est indiqué partout, Il ne faut pas l'aborder comme on aborde le C ou le java.
Il y a de la place pour les classes et pour les prototype
Je conseille de l'aborder avec un esprit ouvert, sans préjuger, et tu découvriras certainement des possibilités "très intéressantes"
Pourquoi est-il décrié ?
En fait, à l'origine des navigateurs le javascript accompagnait Java. Ces deux langages étaient complémentaires. Java a été supprimé. Donc Javascript est décrié car il ne fait pas ce qu'il n'est pas censé faire.
Maintenant nous découvrons des outils pour atrophier Javascript en vue d'en faire un ersatz de java.
Le problème n'est pas là. Le problème est que tu n'as pas le choix. Le web envahit tout et le web c'est forcément javascript et html. Et quelles que soient leurs qualités respectives, n'importe qui peut reconnaître que ce ne sont pas forcément les meilleurs choix ni le pinacle indépassable de l'IT. Imaginez s'il y a quelques décennies on avait imposé Algol comme le seul langage possible ! Et pourtant à l'époque c'était un "langage très intéressant avec de grandes possibilités".
L'avenir est à des abstractions d'aussi bas niveau que possible tout en restant agnostiques par rapport au matériel. Un bytecode (pNaCl ou asm.js) et des API fondamentales (stockage de données, utilisation du GPU, concurrence, etc), le tout gentiment enfermé dans un bac à sable par page. L'avenir des navigateurs, c'est d'être un OS.
Aujourd'hui sur le web, l'innovation est encadrée par le W3C. Il est temps qu'on nous redonne le pouvoir à nous. Vive le bas niveau, qu'on puisse construire par-dessus.
Effectivement. Je répondais aux critiques portées au Javascript.
Mais il est évident que la meilleure solution est : plus de liberté, dans un contexte sécurisé
Voilà que fait plaisir à lire
Oui.
Et cela me ramène à TypeScript. Je reste septique à l'idée de donner à Javascript le rôle 'bytecode'. J'ai le sentiment que c'est l'usage qu'en fait TypeScript car il déstructure le Javascript pour le plier à ses exigences.
La structure des données adoptée par TypeScript (prototype de prototype) n'est pas très usuelle. Comment être certain que les autres Navigateurs conserveront ce fonctionnement qui peut être présenté comme "à risque" (si il est utilisé sans Préprocesseur).
Faisons ce que tout responsable informatique doit faire, évaluons la pérennité d'un langage qui engagera l'avenir de la production. Ici nous détectons un risque à venir dans les navigateurs sur lesquels Microsoft n'a aucune emprise : si l'un d'entre eux supprimait le fonctionnement des 'prototypes de prototypes', TypeScript ne fonctionnerait plus sur ces navigateurs. Suppression qui serait justifiée par des raisons de sécurité pour les utilisateurs.
Avec l'espoir que les responsables de TypeScript apportent une réponse circonstanciée à ce risque.
Les navigateurs n'interprètent pas le TypeScript. Le TypeScript est compilé en Javascript; donc le code en TypeScript fonctionnera sur tout navigateur supportant le Javascript.
De plus tout code Javascript est compatible TypeScript, ce qui veut dire que tout développeur Javascript qui veut aussi faire du TypeScript peut le faire sans se retrouver limité.
Je pense que c'est une très bonne idée car les développeurs ayant l'habitude de travailler avec un compilateur et typage fort (C++, Java, C#, ...) dans des grosses équipes ne voient pas comment ils peuvent travailler efficacement en Javascript.
Alors qu'avec TypeScript, on a une facilité pour effectuer des refactoring sur des méthodes sans s'inquiéter de faire du "push & pray".
Dans mon message précédent, c'est précisément cette une affirmation que je confrontais à une analyse technique et à ses conséquences.
C'est cette affirmation que je souhaiterais voir démontrée.
----
Rappel : la structure d'héritage générée par TypeScript peut entraîner des problèmes. Voir le test http://jsfiddle.net/8ez4x/12/
Note : les concepteurs de TypeScript connaissent ces risques puisqu'ils ont programmé une vérification pour les repérer et les interdire.
Cette structure d'héritage empile des prototype directement sur d'autres prototypes. C'est une organisation bien particulière, et qui recèle des problème de comportement (présentés dans le test ci-dessus).
Comment avoir la certitude qu'aucun concurrent n'utilise cet argument de dangerosité pour interdire le traitement des "prototypes-empilés" dans leur javascript embarqué ?
Durant l'histoire des navigateurs, nous avons vu disparaître des composants pour des raisons plus futiles.
TypeScript sort en version 1.0
Microsoft dévoile son sur-ensemble typé de JavaScript
Microsoft a annoncé lors de la conférence Build la sortie de la version finale de TypeScript, son préprocesseur qui ajoute un typage statique et optionnel au langage JavaScript.
Après plus de trois ans de développement sous la direction d’Anders Hejlsberg, le père du langage C#, TypeScript atteint sa première version et s’ouvre aux contributions de la communauté de développeurs.
TypeScript est disponible comme un langage de première classe dans Visual Studio, et est supporté par l’EDI à même titre que C# ou encore VB.NET. Il est embarqué par défaut dans Visual Studio 2013 et Visual Studio Web Express 2013 Spring Update, dont la Release Candidate a été publiée parallèlement par Microsoft, et permet de bénéficier de Intellisense, des fonctions de navigation et de toute la productivité qu’offre l’éditeur de code de Visual Studio.
TypeScript en action dans Visual Studio 2013
Pour les utilisateurs d’autres environnements de développement, Microsoft met à disposition TypeScript comme un package NPM (Node.js) et son code source est disponible sur GitHub.
TypeScript en action dans Eclipse
Source : Microsoft
Et vous ?
Vous souhaitez participer aux rubriques .NET ? Contactez-moi
Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
Mon blog, Mes articles, Me suivre sur Twitter
En posant correctement votre problème, on trouve la moitié de la solution
Coté serveur javascript n'est pas très performant puisqu'il n'est jamais exécuté ^^ . Le code JS est "transpiler" en code natif qui lui est exécuté, je te renvoi à la documentation et au code source de V8. Le javascript coté serveur ça n'existe que dans ta têteOh ce troll !
Concernant le côté humain, cela dépendra du développeur et, aussi, sa façon d'appréhender / apprendre un autre paradigme de programmation que celui qu'on lui a inculqué durant sa scolarité.
Pour l'ordinateur, JavaScript n'est donc pas performant ? Côté client, cela dépend du poste de l'utilisateur, mais côté serveur, je ne crois pas que JavaScript soit si lent que ça comparé à certains autres langage. Ou alors, nous n'avons pas vu les mêmes benchmarks
Totalement inutile ces histoires de Typescript, Coffeescript, Dart (sans la VM), typage fort, etc...si c'est pour pondre du javascript au final.
Cette maladie moderne de vouloir toujours rajouter des couches par dessus les couches...
Peignez des rayures sur un âne, ça restera un âne, ça ne deviendra pas un zèbre !
Le typage fort réduit la fréquence des bogues et permet de meilleurs outils. Ceci est objectif, indiscutable et très significatif. On peut en revanche débattre de son impact sut la productivité, c'est une autre affaire, fonction de la taille et de la nature du projet, et sujette à débat. Mais qualifier le typage fort de "totalement inutile"... Tu parlais d'âneries il me semble ?
Je ne suis pas d'accord avec toi pour plusieurs raisons. De un, il est bien évidemment possible de faire des applications Web (ou autre) en Javascript pur. Le problème devient cependant la maintenabilité. Pour faire un peu d'interactivité à gauche à droite, il est probablement mieux de faire du Javascript pur, à l'aide d'une librairie telle que jQuery. Cependant, quand tu commences à faire des apps avec des framework comme Angular, Ember ou Knockout (bref, avec un pattern MVC/MVVM), on se rend compte que ça devient vite un foutoir.
C'est dans ces cas où l'utilisation de Typescript, Dart ou CoffeeScript devient intéressante, car l'application devient alors structurée comme une application en POO classique. Bref, ça devient très utile et beaucoup lisible.
Bref, une bonne nouvelle pour Typescript que j'aimais bien après l'avoir essayé. Il manquait cependant le mot-clef protected et un moyen facile de faire référence à this de manière consistante (sans passer par la technique self par exemple).
Pourquoi pas...
Mais ça n'existe pas en Javascript, alors inutile de toujours pleurer (c'est bien ce qu'il se passe chaque fois qu'il y a un article sur ce sujet) sur le fait que le langage n'est pas adapté etc...
Changez de langage s'il ne vous plait pas, ou inventez en un si vous le pouvez (aucune arrogance de ma part, moi j'en serai incapable, c'est certain...)
Il en existe plein d'autres.
Autant je peux saluer Google et Dart dans sa version VM, s'ils arrivent à se faire accepter / adopter par les autres (oui je sais, ce n'est pas gagné).
Je ne l'ai pas encore testé mais au moins c'est un nouveau langage, indépendant.
J'aurai toujours le choix de l'utiliser ou pas.
Mais Dart qui pond du Javascript, comme Coffeescript, Typescript et d'autres que je ne connais p-e pas, je trouve ça idiot et inutile.
Ce n'est pas taillant les oreilles en pointe à un âne qu'on en fait un cheval de course...et j'en ai plein d'autre des comme ça
Pour y être actuellement confronté, je ne peux qu'appuyer les propos de Greto (très fortement).
Et pourquoi tu veux absolument nous faire développer un nouveau langage puisqu'en l’occurrence TypeScript apporte des réponses à certains manquements de Javascript. Bref, que tu n'y vois aucune utilité, soit, mais je peux t'assurer que l'intérêt d'une telle "surcouche" n'est pas null pour tout le monde.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager