JavaScript plus performant que Java pour le Web ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

07/12/2013, 18h05
garheb

Node.js est un excellent outil, ça fonctionne très bien, c'est relativement simple à utiliser.

Par contre, AUCUN moduleque j'ai pu utiliser (parmis les plus populaires) n'ont une API à jour. Une partie non négligeable des fonctions disponibles dans un module ne sont pas connues de la documentation officielle. C'est absolument lamentable. Et ça gâche totalement node.js.

En plus de ça, le fait que le typage soit faible avec js rend l'utilisation d'un IDE complétement inutile et coder du node.js devient un cauchemar.

De l'autre coté, on a un langage connu pour être verbeux, mais dont la documentation est impeccable et le typage fort. En l'état actuel, je n'hésiterais pas une seule seconde dans le choix entre node et java.

Mais Paypal est une grande entreprise, qui codera sans doute en interne ses propres modules ou les modifiera de manière à ce que tout soit clair dans la documentation. Mais pour un projet lambda, ce n'est pas toujours possible.

NB: l'application utilisant node.js que j'ai eu à faire comportait: lodash, express, jade, knockout, d3 et cradle
07/12/2013, 18h24
sekaijin

Comme toujours on peut voir une "gerre" de chapelle.
pour ma part je regarde la démarche et le résultat m'importe peu.

tout cela pour moi confirme une chose que je pense depuis longtemps. Si on analyse sans apriori les solutions disponible sur le marché et qu'on défini des odjectifs clairs on peu choisir de façon opportune.

la question ici n'est pas de savoir si JS ou C++ ou Java est plus rapide, moins gourmand ou quoi que ce soit de ce genre.

La question est Dans ce contexte précis, avec les compétence présente, qui de Node.js et de Java est le plus adapté pour atteindre les objectif fixés.

Paypal en fonction de CES besoins à choisi Node.js.

cela ne signfi nulement que Node.js est meilleur que qui que ce soit.
cela signifi que du point de vu de Paypal pour ce besoin dans ce contexte avec ces compétences Node.js est apparu comme le plus approprié.

Pour ceux qui disent que C++ ou je ne sais quel langage serait plus rapide
posez vous la question de savoir pourquoi on écrit encore des shell scripts.

pour moi cette affaire devrait servir d'exemple et Paypal serait bien en lumière si elle publiait sa methode de choix.

je lis ici ou là que ce genre de post ou d'annonce vise à tuer Java ou je ne sais quoi d'autre.

moi ce que je lit c'est que Node.js peut être concidéré comme une alternative. non pas un remplaçant mais un outil de plus.

quand rubi à débarqué on a eu droit au même phénomene. Oui techniquement rubi était bien mais avion snous la preuve que pour une grosse app il faisait l'affaire ? puis petit a petit certains ce sont lancé et on monté que c'était viable.
ça n'a tué personne ça a juste ajouter une possibilité de plus.

Node.js est arrivé est de la même façon on a eu quelque dev ici où là mais pour un responssable choisir Node.js n'était pas facile car trop jeune. depuis il a fait petit à petit ces preuves.
aujourd'hui Paypal nous dit "Node.js est vaible pour une applie de grandes ampleur. Nous y croyons, nous avons évalué la solution, et nous l'avons retenus"

Je dis Chouette un outil de plus. lorsque nous aurons un projet pour faire notre choix nous mettrons en face des besoin et du contexte un outils de plus nous aurons donc une chance de plus d'avoir un outil adapté.

qui à parlé de tuer Java ? qui à dis que JS était plus rapide que Java, qui a dit que JS était meilleur ?

A+JYT
08/12/2013, 01h21
Dominik94

Citation:

Envoyé par Lcf.vs

<troll>Par contre, je ne savais pas qu'il fallait des ingénieurs pour faire du développement sous Node :mrgreen:</troll>

<trollbis>J'vais sûrement avoir plein de - par les défenseurs du Java... se rendant compte qu'ils ne servent plus à rien. lol</trollbis>

ça peut être un bon moyen de se séparer d'équipes qui revenaient trop cher en salaires & charges;)

Citation:

Imaginez un développeur HTML qui doit demander à un développeur Java de lier la page A et B

euh, si je ne m'abuse, le html c'est juste du texte à insérer, quelque soit le langage. Même si tu n'as pas un vrai MVC

et si ce n'était qu'un simple buzz, du genre de celui d'amazon parlant de livrer, d'ici peu, en drone depuis ses entrepôts ?
En plein dans la période des cadeaux de noël, c'est pas mal de faire parler de sa solution de paiement en ligne, non ?
08/12/2013, 12h43
sparkyXI

Réécriture de code

D'un autre côté ce n'est pas étonnant: en le réécrivant complètement en js ils ont pu optimiser leurs code, éliminer ce qui n'était pas utile, mieux penser les algo.

S'ils l'avaient réécrit en java, ils auraient aussi eu des gains de performance,

D.
08/12/2013, 13h55
Gugelhupf

Citation:

Envoyé par Dominik94

ça peut être un bon moyen de se séparer d'équipes qui revenaient trop cher en salaires & charges;)

Dois-je en déduire qu'un développeur Java coute plus cher qu'un développeur JavaScript ?
Ou bien une manière de remettre à zéro le compteur des augmentations (l'ancienneté) ?
08/12/2013, 15h28
sekaijin

Citation:

Envoyé par Dominik94

...
euh, si je ne m'abuse, le html c'est juste du texte à insérer, quelque soit le langage. Même si tu n'as pas un vrai MVC

NON on fais aussi des application zero HTML.
plus exactement HTML5 ce n'est pas un langage de balise
HTML5 normalise le DOM le langage de balise n'est qu'une sérialisation par défaut du DOM.
On fais donc des applis qui utilise le DOM et n'on aucune ligne de HTML en tant que langage de balise.

Dans ce cas tu fais menu = new Menu(...); ou graph = new MultiSeries3DBar(...); il n'y a pas de balise HTML dans ce code.

A+JYT
09/12/2013, 08h59
Mickael_Istria

Je pense qu'adopter JavaScript cote serveur, c'est se tirer une balle dans le pied en terme de maintenance compare a Java. Java est quand meme ultra-robuste et bien que certains frameworks soient lourds, la plupart sont clairement des solutions de tres bonne qualite a des problemes concrets de l'industrie informatique (persistence, queuing, messaging, securite...). Toutes ces problematiques ont un cout sur les performances, qui vaut souvent le coup d'etre paye.
En JavaScript, il n'y a (a ma connaissance) rien d'aussi mature pour l'instant, on est en train de tout reinventer, pour s'en plaindre dans 10 ans de la meme maniere que certains se plaignent de JEE maintenant. Quel aura ete le benefice au final? Je suis plutot pessimiste a ce sujet...

Ok, il y a un gain de performance sur certaines applis, mais au final ce gain est peut-etre plutot lie au fait qu'au lieu de consommer plus de perf cote server et d'y faire plus de calcul, on met de plus en plus de dynamicite cote client. C'est un peu facile de dire "on est plus performant" alors que la verite est "on fait moins de chose cote serveur pour les faire faire au client".
Au final, dans bien des cas, on a du contenu quasi-statique (un application) qui est envoye au client, et c'est le client qui se debrouille. Niveau serveur, ca demande pas beaucoup plus que de faire un Hello World.

Bref, je suis peut-etre ultra pessimiste, mais je pense que la mode du tout JavaScript a vraiment du mal a etre justifiee techniquement. Des applis dynamiques en JavaScript dans des navigateurs, ok; mais mettre en place des services et servir des donnees en JavaScript, je vois pas ce qu'on peut en attendre de mieux qu'en Java.
09/12/2013, 11h07
Paul TOTH

Citation:

Envoyé par Mickael_Istria

Je pense qu'adopter JavaScript cote serveur, c'est se tirer une balle dans le pied en terme de maintenance compare a Java. Java est quand meme ultra-robuste et bien que certains frameworks soient lourds, la plupart sont clairement des solutions de tres bonne qualite a des problemes concrets de l'industrie informatique (persistence, queuing, messaging, securite...). Toutes ces problematiques ont un cout sur les performances, qui vaut souvent le coup d'etre paye.
En JavaScript, il n'y a (a ma connaissance) rien d'aussi mature pour l'instant, on est en train de tout reinventer, pour s'en plaindre dans 10 ans de la meme maniere que certains se plaignent de JEE maintenant. Quel aura ete le benefice au final? Je suis plutot pessimiste a ce sujet...

Ok, il y a un gain de performance sur certaines applis, mais au final ce gain est peut-etre plutot lie au fait qu'au lieu de consommer plus de perf cote server et d'y faire plus de calcul, on met de plus en plus de dynamicite cote client. C'est un peu facile de dire "on est plus performant" alors que la verite est "on fait moins de chose cote serveur pour les faire faire au client".
Au final, dans bien des cas, on a du contenu quasi-statique (un application) qui est envoye au client, et c'est le client qui se debrouille. Niveau serveur, ca demande pas beaucoup plus que de faire un Hello World.

Bref, je suis peut-etre ultra pessimiste, mais je pense que la mode du tout JavaScript a vraiment du mal a etre justifiee techniquement. Des applis dynamiques en JavaScript dans des navigateurs, ok; mais mettre en place des services et servir des donnees en JavaScript, je vois pas ce qu'on peut en attendre de mieux qu'en Java.

autant sur la maintenabilité je dis pas, autant je ne vois pas le mal à déporter sur le client une partie du traitement...C'est d'ailleurs ce qu'on fait depuis des années en fonction des technologie, on part d'un terminal avec tout sur le serveur et on déporte sur le client en modèle client/serveur puis en remet tout sur le serveur (TSE, HTML) avant d'en remettre un bout sur le client (Flash, Silverlight, Javascript), c'est un va et vient incessant.

ceci dit, dans le cas de Paypal je ne pense pas qu'il y ai grand chose à déporter.
10/12/2013, 14h13
ddoumeche

Citation:

Envoyé par Sange844

1 La comparaison faite par Paypal aurait eût beaucoup d'intérêt avec GWT

2 Sauf que le code exécuté par NodeJS est interprété et qu'en perfs brutes JS<Java généralement. Et puis la JVM n'est pas codée en Java.

3 Là par contre, je dois avouer que J2EE est une sacrée usine à gaz que j'évite autant que possible.

2> Le moteur V8 de Node.js compile le code Javascript en code machine dès lors qu'il y a un nombre suffisant d'itérations. Mécanisme inspiré d'HotSpot d'ailleurs. Cela n'a donc rien à voir avec le langage utilisé pour coder Node.js

Sur le fond du problème, Twitter est passé de RoR à Java avec un gain de performance x3 (je ne pense pas que RoR bénéficie des mêmes mécanismes d'optimisation que les jvm). Mais ca n'a pas fait un tel foin sur développer.com.

Il me semble donc que les consultants envisagent de réécrire les anciennes applis Java. De toutes manières, de nombreuses arrivent en fin de vie, à commencer par les plus mal fichues, les utilisateurs s'en plaignent.

De la à constater que Node.js est 2x plus rapide ? C'est possible car il utilise un mécanisme asynchrone (que l'ont retrouve aussi sur Play! framework).
Mais par contre on perd énormément de choses : typage fort, débugage, tests unitaires, profiling, etc
Et on en arrive sur une plateforme immature, dont on fait les frais. Personnellement, j'ai donné pour ce genre de délire adolescent.

Mais après tout pourquoi pas, il faudra bien les refaire dans 10 ans parce que immaintenable. C'est bien cela le métier de consultant :mrgreen:
10/12/2013, 20h05
sekaijin

Citation:

Envoyé par ddoumeche

2> Le moteur V8 de Node.js compile le code Javascript en code machine dès lors qu'il y a un nombre suffisant d'itérations. Mécanisme inspiré d'HotSpot d'ailleurs. Cela n'a donc rien à voir avec le langage utilisé pour coder Node.js

Sur le fond du problème, Twitter est passé de RoR à Java avec un gain de performance x3 (je ne pense pas que RoR bénéficie des mêmes mécanismes d'optimisation que les jvm). Mais ca n'a pas fait un tel foin sur développer.com.

Il me semble donc que les consultants envisagent de réécrire les anciennes applis Java. De toutes manières, de nombreuses arrivent en fin de vie, à commencer par les plus mal fichues, les utilisateurs s'en plaignent.

De la à constater que Node.js est 2x plus rapide ? C'est possible car il utilise un mécanisme asynchrone (que l'ont retrouve aussi sur Play! framework).
Mais par contre on perd énormément de choses : typage fort, débugage, tests unitaires, profiling, etc
Et on en arrive sur une plateforme immature, dont on fait les frais. Personnellement, j'ai donné pour ce genre de délire adolescent.

Mais après tout pourquoi pas, il faudra bien les refaire dans 10 ans parce que immaintenable. C'est bien cela le métier de consultant :mrgreen:

Je suis d'accord pour dire que JS n'est pas encore mature dans ce genre de contexte. mais c'est justement parce que certain font ce genre de portage et d'annonce qu'on avance vers plus de maturité.

S'il vous plait arrêté de dire qu'on perd énormément en citant le déboggage
On debugue très bien avec JS debugueur pas à pas, jsunit et tout ce qu'il faut pour faire di code de qualité comme dans tous les langage.

quant au typage fort autant je suis d'accord pour dire qu'on ne l'a pas avec JS autant je me demande en quoi c'est une perte.
quand je vois la quantité de code produit dans les langage à typage fort pour palier le manque de souplesse du typage je me dis que PARFOIS le typage dynamique à du bon.

par contre pense qu'il manque encore des outils de profiling à la hauteur des grosse applications.

Je suis toujours étonné de voir depuis des années fleurir au sein même de domain ou on prone le typage fort et la poo à base de classe, divers langage qui introduise du typage dynamique du typage faible etc.
que dire des capacité runtime de objective-c de c# que dire de langage comme scala et bien d'autres. tous introduise à des doses plus ou moins importantes des notion qui assouplissent les contraintes du typage fort.

ce phénomène général (on le vois partout) montre pour moi que parfois les langage au typage trop fort sont des contraintes.

JS est effectivement à l'opposé cela fait peut être peur. mais pour moi ce n'est pas une tatre c'est une caractéristique à exploiter. c'est sur qu'il faut penser autrement. mais il n'est rien de pire que la pensé unique.

A+JYT
11/12/2013, 11h19
Mickael_Istria

L'avis d'un admin de wikipedia sur le Web et le client-side scripting en general: http://tommorris.org/posts/8677

Mais bon, je reconnais que JavaScript est maintenant plus que ca, c'est aussi et surtout le langage le plus multi-plateforme qui soit (merci a ceux qui ont banni Flash et Java par peur du manque de controle, maintenant, on sait quoi re-faire pendant 10 ans).
Au final, quand on voit Cordova et PhoneGap, JavaScript est en train de devenir le langage pour les applications riches sur mobile. Il prend dans le mobile la place que Java a sur le desktop, ce qui n'est pas vraiment un progres puisqu'il aurait surement ete plus simple/economique de choisir Java ME ou une autre techno deja eprouvee et d'eviter a tout reimplementer
14/12/2013, 22h12
Mishulyna

Citation:

Envoyé par Pill_S

Moi ce que je me demande, avec tous les topics chaque semaine qui cherchent à tuer java, c'est: pourquoi developpez.com cherche à tout prix à faire passer ce qui est clairement l'une des meilleures technos pour la pire de toutes?? ...

De mon point de vue c'est un peu comme [ame="http://vimeo.com/18178016"]chacun son truc[/ame].

Citation:

Envoyé par Pill_S

Pour chaque topic faisant l'éloge de Java, une bonne dizaine sont ouverts pour dire que c'est de la bouze, et que n'importe quoi d'autre est mieux...

C'est avec ce genre d'attitude qu'on va bien finir par éloigner tous les nouveaux de cette techno... et finalement réussir à tuer réellement la communauté et la plateforme!! et tous se retrouver dans la m**** et devoir programmer en javascript partout... c'est dépitant...

Mais non, chacun son truc...:ccool:
14/12/2013, 22h49
Mishulyna

Citation:

Envoyé par LSMetag

Java est justement devenu trop mature et rigide, et quand tu as 20/30 ans, t'as pas trop envie d'une femme de 50/60 ans ridée, ménopausée et moins dynamique, qui ne sait pas se lifter aussi bien que Madonna ou Cher.

Ben, justement, quand t'es une "jeune" diplômée de 51 ans (et blonde en plus) tu n'as pas envie de System.Collection.Specific et encore moins de System.Collection.Generic du C#!

Et Microsoft SQL Serveur c'est un blasphème! Si jamais Oracle a pondu quelque chose de bien, c'est SQL: là on ne risque pas se retrouver avec un alias d'une table sur un nom de colonne si l'on a oublié de mettre une bête virgule.

Comme je l'ai déjà dit: chacun son truc. Libre à vous de préférer des Lady Gaga ou Rihanna ou encore des plus jeunes, faites gaffe néanmoins à la pédophilie!:P
15/12/2013, 14h32
sekaijin

bonjour.
dans la vie de développeur il y a des moment ou avoir un outils qui analyse contraint cadre... le travail du développeur est quelque chose de bon.
et plus les outils ont une sémantique claire mieux c'est. la POO à base de classes est de cela c'est une approche à la sémantique bien définie et à outillage bien développé. elle permet de bien cadre son développement et de bénéficier d'outil d'aide au développent qui sont éprouvés. Mais cela à un cout. dans certain cas ou la situaion est très mouvante le contraintes de classes deviennent un frein. on met alors en oeuvre des techniques complexe qui en fait ne sont rien d'autre que défaire les cadres que nous apprécions habituellement tant.
aini voyons nous apparaitre de l'injection de byte code en java des mecanismes qui passent outre les protections des classes. genre introspection avec des methodes qui permettent d'invoquer une méthode ou d'accéder à un membre protégé. ou encre des méthodes de swizzling.
si les développeur de language de systemes de lib de compilateur de runtime etc on inventé ces moyens c'est pour répondre à un besoin.

je pense que nous sommes tous d'accord que si ce genre de chose existe dans les compilateurs et non dans les méthodes de polymorphisme, d'héritage etc c'est bien parce que le modèle de POO à base de classes en théorie ne le permets pas.

à l'opposé de cette approche existe des langages aui ont eux aussi leur outils et leur methode de dev qui mise sur l'aspect dynamique. dans cette approche de la programmation on de contraint pas à la avance un objet à rester dans un cadre rigide, on ne vérifie pas qu'une variable appartient à une classe on vérifie dynamiquement que l'objet est capable de faire ce qu'on lui demande. les problématiques de swizzling et de mutation ne sont plus d'actualité car intrinsectes au develeppement. en contre partite il appartien au developpeur de faire le necessaire pour garder la cohérence de sont dev.

Les deux approche n'ont pas à sopposer elle travaillent sur des terrains différents. ainsi il ne viendrait à personne l'idée d'avoir un shell qui ne peut être utilisé qu'apprès avoir compilé sont script.

La question qui se pose c'est dans les zones de recouvrement des deux approches. pour une application web l'aspect dynamique est-elle interressante ? Certain diront oui d'autre dirront que ça n'apporte rien.

ce qui semble être apprecié dans node.js c'est son approche asynchrone. pour tout ce qui pense que la POO à base de prototypes et trops dificile à maitriser et prefère la POO à base de classes ont peut très bien faire du des asynchrone en POO à base de classes. Node.JS à choisi JS. mais il semble claire que l'asynchrone dans CE contexte soit une solution à envisager. même si on ne la retient pas.

et laissons de la place à tout les paradigmes
en voici une petite liste. lorsqu'on mets en place une Appli MVC on a besoin de réagir aux modifications internevues dans la vue pour prendre en compte des action de l'utilisateur. pour ça on utilise le Design Pattern Observable. en programation réactive il n'est pas besoin de mettre n place un pattern cela fait partit du langage. de la même façons les langages à agent ou acteur permettent de mettre en place des techniques qui necessitent dans d'autre langage des patterns plus ou moins complexes.

Types de programmation impérative (et dérivés)

Programmation impérative, paradigme originel et le plus courant
Programmation structurée, visant à structurer les programmes impératifs pour en supprimer les instructions goto
Programmation procédurale, à comparer à la programmation fonctionnelle
Types de programmation orientée objet (et dérivés)

Programmation orientée objet, consistant en la définition et l’assemblage de briques logicielles appelées objets (comme en Smalltalk)

Programmation orientée prototype, qui simplifie et rend plus flexible la programmation orientée objet
Programmation orientée classe, à comparer à la Programmation orientée prototype (dans le contexte de la programmation orientée objet)
Programmation orientée composant (comme en OLE)
Types de programmation déclarative (et dérivés)

Programmation déclarative, consistant à déclarer les données du problème, puis à demander au programme de le résoudre
Programmation descriptive, à l'expressivité réduite, qui permet de décrire des structures de données (par exemple, HTML, XML ou LaTeX)
Programmation fonctionnelle, avec laquelle un programme est une fonction au sens mathématique du terme
Programmation logique, consistant à exprimer les problèmes et les algorithmes sous forme de prédicats (comme en Prolog)
Programmation par contraintes, à comparer à la programmation logique
Autres types

Programmation événementielle, consistant à répondre à des événements
Programmation séquentielle
Programmation interruptible, à comparer à la programmation événementielle
Programmation concurrente, où l’on tient compte de l’exécution en parallèle de plusieurs piles sémantiques
Programmation orientée aspect (comme en AspectJ)
Programmation par contrat, dans lequel le déroulement des traitements est régi par des règles (comme en Eiffel)
Programmation chimique, où les programmes sont vus comme des solutions chimiques abstraites. Les données sont des molécules dont les réactions chimiques représentent les opérations.
Programmation orientée agent, souvent basée sur la programmation orientée objet, qui simplifie le développement d’agents logiciels
Programmation orientée concept
Programmation orientée pile (comme en Forth)
Programmation orientée principes
Programmation orientée flux de données, souvent utilisée pour les solutions de communication client/serveur, elle permet d'abstraire les différents plateformes en se concentrant sur l'échange et le traitement des données. Elle est généralement représentée sous forme de diagrammes ou de graphes (voir Diagramme de flux de données) (comme dans un Tableur)
Programmation non-déterministe
Programmation orientée sujet
Programmation réactive
Programmation synchrone
Programmation par annotations (comme en langage Flare)
Programmation par attributs (comme avec les annotations Java, pré-traitées par la classe XDoclet, ou avec les attributs C#)
Programmation sur flux, à comparer à la Programmation sur événement
Programmation par messages, à comparer à la programmation impérative
Programmation orientée processus, pour la programmation parallèle
Programmation récursive, à comparer à la programmation itérative
Programmation réflexive
Programmation scalaire, à comparer à la programmation par tableaux
Programmation au niveau valeur, à comparer à la programmation au niveau fonction

A+JYT
18/12/2013, 01h28
AlexRutny

Bidon

Les développeurs de Paypal se font de la pub à peu de frais (merci à qui?). Il est vrai que l'on est jamais mieux servi que par soi-même. Pour avoir des benchs un peu sérieux et surtout reproductibles (les codes sources sont accessibles), je vous recommande le site : http://www.techempower.com/benchmarks/ (je n'ai pas d'actions chez eux!).

En conclusion node.js a encore qq progrès à faire pour concurrencer les meilleurs frameworks en terme de performances...
03/01/2014, 12h26
sovop

@Paul TOTH:
moi je ne pense pas que l'équipe JS du Paypal est plus compétent que celui Java, mais au contraire je pense le Team-Backend est le le plus compétent et peux imaginer aussi que c'est ce dernière qui a fait le refactoring ou re-dévélopment total en JS.

La raison pour ce point de vue est que dans pas mal des cas (je ne généralisent pas) les Frontendlers ont des problèmes à comprendre et appliquer les design patterns et les concepts OO même les plus simples comme l'héritage. En plus il y a le risque qu'ils implementent un spagetti-code ::calim2:.
08/01/2014, 20h27
ddoumeche

Citation:

Envoyé par sekaijin

Je suis d'accord pour dire que JS n'est pas encore mature dans ce genre de contexte. mais c'est justement parce que certain font ce genre de portage et d'annonce qu'on avance vers plus de maturité.

S'il vous plait arrêté de dire qu'on perd énormément en citant le débogage
On debugue très bien avec JS debugueur pas à pas, jsunit et tout ce qu'il faut pour faire du code de qualité comme dans tous les langage.

quant au typage fort autant je suis d'accord pour dire qu'on ne l'a pas avec JS autant je me demande en quoi c'est une perte.
quand je vois la quantité de code produit dans les langage à typage fort pour palier le manque de souplesse du typage je me dis que PARFOIS le typage dynamique à du bon.

par contre pense qu'il manque encore des outils de profiling à la hauteur des grosse applications.

Je suis toujours étonné de voir depuis des années fleurir au sein même de domain ou on prone le typage fort et la poo à base de classe, divers langage qui introduise du typage dynamique du typage faible etc.
que dire des capacité runtime de objective-c de c# que dire de langage comme scala et bien d'autres. tous introduise à des doses plus ou moins importantes des notion qui assouplissent les contraintes du typage fort.

Ce phénomène général (on le vois partout) montre pour moi que parfois les langage au typage trop fort sont des contraintes.

JS est effectivement à l'opposé cela fait peut être peur. mais pour moi ce n'est pas une tatre c'est une caractéristique à exploiter. c'est sur qu'il faut penser autrement. mais il n'est rien de pire que la pensé unique.

A+JYT

Même si je suis en désaccord sur certains points exposés ci après, je rejoins une partie de ton analyse : JavaScript est immature, mais s'améliore.
Non pas que je méprise ce langage, je l'utilisais même couramment il y a 10ans, même coté serveur via jscript sur asp (pour la mutualisation des librairies entre contexte serveur et client).
Mais comme d'autres, je me suis rendu compte des multiples problèmes de telles solutions.

Déja, au pur niveau développement, on ne débogue pas du code hébergé sur Node.Js avec JS debugueur. Existe-t'il un déboggeur pour ca d'ailleurs ? Aptana Studio ? nous en sommes rendu au niveau du php il y a 10 ans.
Et tu relèves le problème du profiling: faisable dans les browsers, pas encore faisable dans NJS.

Certes il y a JSUnit si l'on fait du code modulaire, mais cela ne peut détecter que des problèmes sur le code testé et une couverture de test à 100% est illusoire. Or js est un langage interprété: si quelqu'un committe du code qui ne compile pas, ce ne sera probablement pas relevé par l'usine logicielle, mais par les collègues.

Au final, je ne vois pas le gain de temps sur le développement
09/01/2014, 16h02
Mickael_Istria

Citation:

Envoyé par ddoumeche

Déja, au pur niveau développement, on ne débogue pas du code hébergé sur Node.Js avec JS debugueur. Existe-t'il un déboggeur pour ca d'ailleurs ?

Je pense qu'il faut plutot chercher du cote de Chrome Dev Tools, Firebugs et compagnie pour pouvoir debugger du JS deploye.
Sinon, dans le dev, en utilisant une combinaison de live-deploy, live-reload et compagnie pour redeployer le bout de JS a chaque changement, on arrive a peu pres a un environnement convenable, mais comme tu le fais remarquer, c'est du meme acabit que PHP.
14/07/2015, 14h12
Invité

Bonjour

AngularJs > Java pour toutes les petites applications d'ingénierie, voir les grosses.
gain de productivité = AngularJs
Java = juste bon à gérer la base de donnée

Cordialement.
23/04/2019, 14h21
moustic98

C'est Google qui demande ce genre de Buzz ?!!

Pour être clair et arrêter de prendre les gens pour des pigeons, il restera éternellement vrai que un langage compilé est plus performant qu'un langage s’exécutant dans une JVM qui restera plus préformant qu'un langage interpréter, exemple : C est plus Rapide que Java qui est plus rapide que JavaScript, et c'est une évidence, une tautologie, une réalité ... :lol:

Voici un petit aperçu d'un comparatif de différent algorithme implémenté en Java et en JS exécuté sous Node, jamais NodeJs ne surpasse Java en terme de performance, une simple implémentation de mandelbrot s’exécute presque 4 fois plus vite en java ...

https://benchmarksgame-team.pages.de...avascript.html

Et contrairement au billet de Paypal, ici nous avons les sources pour tous les langages cité, comme quoi on peux raconter n'importe quoi sans être précis du moment que le public est novice :aie::aie::aie: Pauvre Paypal ...

Voir 40 message(s) de cette discussion en une page