IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Actualités Discussion :

JavaScript plus performant que Java pour le Web ?

  1. #81
    Membre averti
    Inscrit en
    Juin 2011
    Messages
    258
    Détails du profil
    Informations forums :
    Inscription : Juin 2011
    Messages : 258
    Points : 334
    Points
    334
    Par défaut
    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

  2. #82
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    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

  3. #83
    Membre habitué
    Profil pro
    Inscrit en
    Juillet 2010
    Messages
    53
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2010
    Messages : 53
    Points : 168
    Points
    168
    Par défaut
    Citation Envoyé par Lcf.vs Voir le message
    <troll>Par contre, je ne savais pas qu'il fallait des ingénieurs pour faire du développement sous Node </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

    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 ?

  4. #84
    Nouveau membre du Club

    Homme Profil pro
    Inscrit en
    Novembre 2013
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Novembre 2013
    Messages : 6
    Points : 34
    Points
    34
    Par défaut 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.

  5. #85
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 320
    Points : 3 740
    Points
    3 740
    Billets dans le blog
    12
    Par défaut
    Citation Envoyé par Dominik94 Voir le message
    ç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é) ?
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  6. #86
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    Citation Envoyé par Dominik94 Voir le message
    ...
    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

  7. #87
    Membre émérite
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Inscrit en
    Juillet 2008
    Messages
    1 468
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 468
    Points : 2 996
    Points
    2 996
    Par défaut
    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.
    Pour du HTML, CSS, JavaScript, TypeScript, JSon, Yaml, Node... dans Eclipse IDE, installe Eclipse Wild Web Developer
    Pour du Rust dans Eclipse IDE, installe Eclipse Corrosion
    Follow me on twitter

  8. #88
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    Novembre 2002
    Messages
    8 964
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2002
    Messages : 8 964
    Points : 28 430
    Points
    28 430
    Par défaut
    Citation Envoyé par Mickael_Istria Voir le message
    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.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  9. #89
    Membre extrêmement actif Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    Octobre 2007
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 676
    Points : 2 010
    Points
    2 010
    Par défaut
    Citation Envoyé par Sange844 Voir le message
    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
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  10. #90
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    Citation Envoyé par ddoumeche Voir le message
    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
    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. #91
    Membre émérite
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Inscrit en
    Juillet 2008
    Messages
    1 468
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 468
    Points : 2 996
    Points
    2 996
    Par défaut
    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
    Pour du HTML, CSS, JavaScript, TypeScript, JSon, Yaml, Node... dans Eclipse IDE, installe Eclipse Wild Web Developer
    Pour du Rust dans Eclipse IDE, installe Eclipse Corrosion
    Follow me on twitter

  12. #92
    Traductrice
    Avatar de Mishulyna
    Femme Profil pro
    Développeur Java
    Inscrit en
    Novembre 2008
    Messages
    1 504
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2008
    Messages : 1 504
    Points : 7 840
    Points
    7 840
    Par défaut
    Citation Envoyé par Pill_S Voir le message
    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 Voir le message
    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...
    Chaque fois que tu dis "je ne peux pas", n'oublie pas d'ajouter le mot "encore".

  13. #93
    Traductrice
    Avatar de Mishulyna
    Femme Profil pro
    Développeur Java
    Inscrit en
    Novembre 2008
    Messages
    1 504
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2008
    Messages : 1 504
    Points : 7 840
    Points
    7 840
    Par défaut
    Citation Envoyé par LSMetag Voir le message

    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!
    Chaque fois que tu dis "je ne peux pas", n'oublie pas d'ajouter le mot "encore".

  14. #94
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    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

  15. #95
    Membre du Club
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    34
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 34
    Points : 55
    Points
    55
    Par défaut 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...

  16. #96
    Nouveau membre du Club
    Profil pro
    Software Engineer
    Inscrit en
    Janvier 2006
    Messages
    27
    Détails du profil
    Informations personnelles :
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Software Engineer

    Informations forums :
    Inscription : Janvier 2006
    Messages : 27
    Points : 27
    Points
    27
    Par défaut
    @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 :.

  17. #97
    Membre extrêmement actif Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    Octobre 2007
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 676
    Points : 2 010
    Points
    2 010
    Par défaut
    Citation Envoyé par sekaijin Voir le message
    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
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  18. #98
    Membre émérite
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Inscrit en
    Juillet 2008
    Messages
    1 468
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 468
    Points : 2 996
    Points
    2 996
    Par défaut
    Citation Envoyé par ddoumeche Voir le message
    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.
    Pour du HTML, CSS, JavaScript, TypeScript, JSon, Yaml, Node... dans Eclipse IDE, installe Eclipse Wild Web Developer
    Pour du Rust dans Eclipse IDE, installe Eclipse Corrosion
    Follow me on twitter

  19. #99
    Invité
    Invité(e)
    Par défaut
    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.

  20. #100
    Membre à l'essai
    Profil pro
    Intégrateur
    Inscrit en
    Décembre 2008
    Messages
    111
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Intégrateur
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Décembre 2008
    Messages : 111
    Points : 18
    Points
    18
    Par défaut 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é ...

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

Discussions similaires

  1. Réponses: 31
    Dernier message: 22/04/2014, 15h55
  2. Réponses: 14
    Dernier message: 22/01/2014, 20h52
  3. Réponses: 30
    Dernier message: 20/07/2009, 16h35
  4. Réponses: 0
    Dernier message: 16/07/2009, 17h49
  5. [D7] composants plus rapides que dbExpress pour Oracle 8i
    Par Magnus dans le forum Bases de données
    Réponses: 2
    Dernier message: 10/10/2005, 13h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo