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

JavaScript Discussion :

Quel est l'intérêt d'écrire ou réécrire un logiciel en JavaScript ?


Sujet :

JavaScript

  1. #41
    Membre expérimenté
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 817
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 817
    Points : 1 539
    Points
    1 539
    Par défaut
    Citation Envoyé par Mrsky Voir le message
    Question pour les gens qui font du Node, c'est jouable d'intégrer un appel asynchrone à un module codé en C/C++ sans bloquer l'event loop ?
    Yep ! NodeJS peut communiquer avec du natif, le tout en asynchrone. Ainsi si tu as besoin de puissance, de calculs, de MT, tu le fais en C/C++ et avec 2/3 pauvres bindings tu pilotes dans du JS, en callback ou promesse, pour ma part j'ai choisit les promesse. Ça va aussi pour réexploiter les bibliothèques natives.

    Deux cas d'exploitation dans ma boîte :
    - On taffe dans la logistique, qui demande des calculs complexes et beaucoup de puissance. Le moteur on l'a fait en C/C++, le reste en JS (parce que la plomberie en C/C++, non merci, on s'est trop pété les dents et au bout d'un moment ça suffit)
    - Y'a peut de temps on a dû communiquer avec IBM MQ Series, version 7.5, imposé par l'hébergeur, version qui ne propose qu'une API en C. Pas de problème, en 1 jour les bindings étaient faits pour Linux, 3 jours pour les différentes archis visées (arm, arm64, x86, x64 etc.)

    Et encore, c'est parce que personne n'avait poussé le truc sur npmjs, sinon on se serait encore moins emmerdé.

    Du coup plus besoin d'un machin ultra lourd tel que JAVA, des compétences rares et hors de prix pour C/C++ et le TTM s'est vu grandement amélioré, donc les sous sous aussi, même si le coeur et la VA de ce que l'on produit est fait en C/C++.

    C'est juste excellent ce couplage devenu possible, très simplement, très légèrement
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

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

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 4 184
    Points : 9 089
    Points
    9 089
    Par défaut
    Je ne suis pas tout à fait d'accord avec l'analyse qui est faite.

    Je ne sais pas comment on peut dire qu'un langage est plus "puissant" qu'un autre. pour moi il n'ont pas la même couverture expressive.

    JavaScript a dans cette affaire une caractéristique qui est particulièrement utile. le fait de gérer nativement la programmation événementielle (réagir à des événements peut importe les noms qu'on donne à la chose).

    on peut très bien implémenter une telle programmation en C et même en assembleur. Alors Passer de C/C++ à Javascript pour une application essentiellement événementielle
    c'est juste choisir un langage qui porte nativement cette fonctionnalité à la place de l'implémentater.
    dans ce sens c'est passer à un langage plus "puissant".

    ReactiveC++ aurait été n choix tout aussi pertinent. et bien d'autre aussi.

    Il y a aussi dans cette affaire le passage du compilé statique au compilé à la volée. (Aujourd'hui tous les langages interprétés ou presque utilisent un compilateur à la volé et une machine virtuelle). qu'on soit d'accord où pas il est une chose qui est certaine c'est que les deux ont des avantages et des inconvénients.

    La question à se poser dans le choix est "quelle utilité ?" Si c'est utile pour l'application dans quelle mesure. (il est bien plus facile de faire de l'auto-programmation avec un langage interprété) pour répondre il suffit de mettre les avantages et les inconvénients de tous les langages candidats de pondérer le critère en fonction de absolument nécéssaire, nécessaire, un plus, pas nécessaire. et ça aide à y voir clair.

    le dernier point est la nature des objets (en tant que structure) manipulés. Si on manipule des objets à la définition stricte peu ou pas évolutive les langages fortement structurés ont été pensé pour ça. Si on manipule des structures au contours vague et changeant les langages portant nativement de telles définitions de structures seront mieux adapté. là encore les deux ont des avantages et des inconvénients et il convient de les évaluer pour faire un choix pertinent.


    Et pour finir il y a un facteur que je pense on oubli un peu trop. Les compétences. Mieux vaut utiliser un langage maitrisé et moins bien adapté qu'un langage parfaitement adapté mais inconnu. La disponibilité des compétences sur le marché sont aussi un facteur qui doit entrer dans le choix. aujourd'hui où tout va très vite on oublie un peut trop que certaines applications fonctionnent depuis 40 ans. et je sais par expérience que ce qu'on pensait pérenne sont porte depuis longtemps et d'autre qu'on disait provisoire sont là depuis des décennies. Alors choisir un langages ésotériques connu d'une poignée d'aficionados, c'est prendre le risque de devoir dépenser des sommes astronomique pour maintenir la chose. Même en choisissant des langages répandus, le temps fait que les compétences disparaissent. (on cherche des développeur COBOL aujourd'hui).

    Alors plus que le fait d'avoir réécrit git ce qui serait intéressant c'est d'avoir l'analyse qui a mené à ce choix.
    A+JYT

  3. #43
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    359
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 359
    Points : 1 248
    Points
    1 248
    Par défaut
    Selon les stats Github, l'intérêt porté dans les projets javascript est fortement à la baisse ces 5 dernières années (bien qu'il reste le plus "tendance"):

    Nom : 2018-05-21-195714_1367x396_scrot.png
Affichages : 1763
Taille : 79,1 Ko

    https://madnight.github.io/githut/#/stars/2018/1

  4. #44
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    février 2004
    Messages
    718
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : février 2004
    Messages : 718
    Points : 1 831
    Points
    1 831
    Par défaut
    Une "tendance"? Il fait plus que tous les autres cumulés. Sacré tendance tu me diras dit-donc!

  5. #45
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    359
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 359
    Points : 1 248
    Points
    1 248
    Par défaut
    Je trouvais ce graphique pas mal par rapport au sujet ^^

    En 2012 JS avait plus de 50% de l'attention sur github, c'est vrai que c'est impressionnant !

  6. #46
    Invité
    Invité(e)
    Par défaut
    S'il vous plait arrêtez de citer nodejs et electron pour "prouver" les qualités de javascript. Nodejs c'est essentiellement v8 (60% en C++) + libuv (95% en C). Pareil pour electron (70% en C++).

    Quant aux nombreux packages JS sur github ce n'est pas du tout un avantage mais une conséquence de l'absence de lib standard.

  7. #47
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    février 2004
    Messages
    718
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : février 2004
    Messages : 718
    Points : 1 831
    Points
    1 831
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    S'il vous plait arrêtez de citer nodejs et electron pour "prouver" les qualités de javascript. Nodejs c'est essentiellement v8 (60% en C++) + libuv (95% en C). Pareil pour electron (70% en C++).

    Quant aux nombreux packages JS sur github ce n'est pas du tout un avantage mais une conséquence de l'absence de lib standard.
    C++ doit être écrit en grande partie en C et en assembleur, et le C lui-même doit bien être écrit en assembleur. Ca n'enlève en rien l'intérêt du C++ ou du C en comparaison de l'assembleur, heureusement.

    Je doute qu'il existe un seul langage qui ait toutes les librairies Github disponibles nativement, ni en quoi avoir beaucoup de librairies, qu'elles soient natives ou non, est un problème? Cela montre bien que l'intérêt et les développeurs sont là.

  8. #48
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 216
    Points : 5 154
    Points
    5 154
    Par défaut
    Citation Envoyé par blbird Voir le message
    C++ doit être écrit en grande partie en C et en assembleur, et le C lui-même doit bien être écrit en assembleur.
    C et C++ ne sont ni des logiciels, ni des bibliothèques, mais des normes écrites en anglais.
    Les trois compilateurs C++ les plus connus sont GCC, MSVC et Clang. Ils sont tous les trois codés en C++ et savent compiler à la fois du C et du C++.

  9. #49
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    février 2004
    Messages
    718
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : février 2004
    Messages : 718
    Points : 1 831
    Points
    1 831
    Par défaut
    Je ne vois vraiment pas ce que cela change, et encore moins l'intérêt de venir nous dire que le JS tourne sous un navigateur (ou un moteur de navigateur) qui est codé en C/C++.

    Chrome, Electron et Node utilisent le "Google V8 JavaScript Engine", qui est codé en C/C++, oui et alors? Derrière, on développe en JS, et il faut bien un moteur pour faire tourner le langage, comme tous les autres langages. De même, tout code JS qui tourne sous un navigateur, utilise le moteur JS du-dit navigateur qui est lui-même certainement à la base codé aussi en C++ (Firefox et autres), qu'est-ce que ca change?

    Et pour les compilateurs C/C++, d'ailleurs comme la plupart de tous les autres langages importants, le premier compilateur simple est bien souvent en assembleur. Ensuite seulement, le langage réécrit les versions de compilateur suivantes avec son propre nouveau langage basé sur ce premier compilateur.

    On est dans un système de fonctionnement par couches, c'est le même principe avec "Google V8 JavaScript Engine" ou avec n'importe quel autre langage ou compilateur. Ils proviennent tous, à la base, de l'assembleur. Et presque tous, ensuite, de code C/C++. Ce qui n'enlève rien aux qualités des moteurs de compilation/exécution de JS, du langage JS en lui-même, d'Electron, de Node ou de n'importe quel moteur/framework/librairie JS.

  10. #50
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 413
    Points : 19 363
    Points
    19 363
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    S'il vous plait arrêtez de citer nodejs et electron pour "prouver" les qualités de javascript. Nodejs c'est essentiellement v8 (60% en C++) + libuv (95% en C). Pareil pour electron (70% en C++).
    En quoi c'est un argument ça ? Quel autre langage de haut niveau est écrit avec autre chose que du C/C++ ?!?

    Si tu pouvais développer cet argument stp ...

    Citation Envoyé par SimonDecoline Voir le message
    Quant aux nombreux packages JS sur github ce n'est pas du tout un avantage mais une conséquence de l'absence de lib standard.
    Ce n'est pas comparable. Le développement web évolue plus vite et est plus jeune que le développement système et il est contraint par l'évolution des navigateurs qui sont les verrous des nouveautés (il faut 2 implémentations d'une nouvelle feature du langage en prod pour la valider définitivement). Il ne peut pas y avoir un équivalent ce n'est pas le même sujet.

    Et je ne crois pas qu'on puisse encore répondre à la question de savoir si cette vitesse d'évolution est due à la jeunesse ou bien est structurelle du fait du sujet (le web).

    Ton problème c'est que tu prends la grille de lecture du développement système pour lire le développement sur le web. C'est une erreur.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  11. #51
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 216
    Points : 5 154
    Points
    5 154
    Par défaut
    Citation Envoyé par blbird Voir le message
    Et pour les compilateurs C/C++, d'ailleurs comme la plupart de tous les autres langages importants, le premier compilateur simple est bien souvent en assembleur. Ensuite seulement, le langage réécrit les versions de compilateur suivantes avec son propre nouveau langage basé sur ce premier compilateur.
    De nos jours, coder un compilateur en assembleur serait une idée farfelue. Pourquoi programmer un compilateur en assembleur alors que ce serait beaucoup plus pratique de le coder en C, en C++, en D ou n'importe quel autre langage de plus haut niveau que l'assembleur et qui permet d'écrire un programme qui a une bonne vitesse d'exécution ?

    Quand un compilateur compile du langage X vers le langage machine, si un tel compilateur est capable de générer un programme qui s'exécute relativement vite, alors le code source peut être entièrement réécrit en X. Sinon, le code source reste dans un langage comme C ou C++.

  12. #52
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    février 2004
    Messages
    718
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : février 2004
    Messages : 718
    Points : 1 831
    Points
    1 831
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    De nos jours, coder un compilateur en assembleur serait une idée farfelue. Pourquoi programmer un compilateur en assembleur alors que ce serait beaucoup plus pratique de le coder en C, en C++, en D ou n'importe quel autre langage de plus haut niveau que l'assembleur et qui permet d'écrire un programme qui a une bonne vitesse d'exécution ?
    Complètement d'accord avec toi.

    Mais ce n'est pas parce que la plupart des compilateurs JS, ou même que certaines librairies sont écrites dans un autre langage que le Javascript, que c'est un problème. C'est plus ou moins le cas pour tous les langages. Et ce n'est pas pour ca que ces langages ne sont pas des langages de "qualité".

  13. #53
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    Quel autre langage de haut niveau est écrit avec autre chose que du C/C++ ?!?
    Beaucoup en fait : crystal, go, haskell, java, python, perl6, rust, scala... (https://en.wikipedia.org/wiki/Bootstrapping_(compilers))

    Ce n'est pas la qualité de JS qui l'a rendu populaire. JS a d'abord été populaire avec le web frontend et c'est ensuite que sont apparus les normes et outils de qualité.

  14. #54
    Expert confirmé Avatar de psychadelic
    Profil pro
    Inscrit en
    mai 2010
    Messages
    2 529
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2010
    Messages : 2 529
    Points : 4 607
    Points
    4 607
    Par défaut
    La question n’est pas de démontrer une quelconque supériorité dans la syntaxe ou je ne sais quoi du langage JavaScript, cela n’a aucun intérêt.
    S'il vous plait arrêtez de citer nodejs et electron pour "prouver" les qualités de javascript. Nodejs c'est essentiellement v8 (60% en C++) + libuv (95% en C). Pareil pour electron (70% en C++).
    Quant aux nombreux packages JS sur github ce n'est pas du tout un avantage mais une conséquence de l'absence de lib standard.
    Parler de NodeJS ou d’Electron est juste utile pour montrer que le JavaScript ne se cantonne pas à de petits scripts présents sur des pages html, parce qu’évidement, il existe encore des irréductibles pour jeter un regard dédaigneux sur ces possibilités, vu qu’ils ont l’air plutôt agacé de voir toute cette agitation autour de ce Langage.

    Quand aux librairies, c’est vrai qu’il y en a pléthore, avec tout de même quelques ténors comme Angular ou de React qui fédèrent un peu les pratiques.

    Le gros avantage, c’est qu'au moins on à l’embarras du choix*; j’ai travaillé avec des librairies C++ «*maison*» ou même «*corporate*» dans le milieu de la finance, et tout n’est pas forcément formidable, loin de la, quand à changé une virgule quelque part, c’est aller au suicide professionnel*; alors que c’est l’inverse dans les librairies open source*: il y a toute une émulation, et s’il y a critique, elle est faite par des pairs et ne sont pas noyautés par une hiérarchie frileuse et incompétente.

    Et bien sur, cerise sur le gâteau de JavaScript, il est beaucoup plus souple et plus économique à déployer et à maintenir sur Mainframe, et quand on parle d’argent, forcément…

    Alors il y a eu un effet de raz de marée coté outre-Atlantique, et qui arrive, en décalage, comme une grosse vague aujourd’hui en Europe.
    Bien sur il y a eu d’abord des excès car la maturité prend du temps, les millions de modules dans NPM finiront par s’autoréguler et il ne restera que les meilleurs, mais en attendant ç’a été, ( c’est encore) une formidable pépinière de talents, d’inventivité et de créativité tout azimuts, car il ne faut pas oublier non plus l’arrivée de la robotique dont les circuits Arduino en sont l’étendard, ainsi que celle de l’Internet des Objets*; et La JavaScript s’y révèle comme incontournable, alors que les systèmes en C ou C++ y sont vraiment à la ramasse.

    Au final, derrière le "sigle" JavaScript, on à affaire à un nouvel univers informatique, sans doute le plus vaste de tous et dont la croissance est loin d'être achevée.
    «La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode

  15. #55
    Membre extrêmement actif
    Profil pro
    Inscrit en
    décembre 2003
    Messages
    1 616
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 616
    Points : 3 830
    Points
    3 830
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    C et C++ ne sont ni des logiciels, ni des bibliothèques, mais des normes écrites en anglais.
    https://www.ecma-international.org/p...s/Ecma-262.htm
    Étonnamment ECMAScript est un langage normé supporté par une organisation internationale.
    Des moteurs, interpréteurs comme V8, Rhino ou Spidermonkey,... n'ont pas d'autre but que de rendre fonctionnels les éléments de cette norme.
    Émotion
    Infantilisation
    Culpabilisation

    Christophe Alévèque - 18 Mars 2021

  16. #56
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 413
    Points : 19 363
    Points
    19 363
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Beaucoup en fait : crystal, go, haskell, java, python, perl6, rust, scala... (https://en.wikipedia.org/wiki/Bootstrapping_(compilers))

    Ce n'est pas la qualité de JS qui l'a rendu populaire.
    Donc ton argument c'est de dire que le JavaScript n'est pas de bonne qualité parce que ses moteurs ne sont pas écrits avec JavaScript ?

    Citation Envoyé par SimonDecoline Voir le message
    JS a d'abord été populaire avec le web frontend et c'est ensuite que sont apparus les normes et outils de qualité.
    Non le point de bascule c'est Node.js en 2009 (sortie concomitante avec ES5) qui a permis l'éclosion d'un écosystème et la création de tous les outils autour. Avant ça on était vraiment dans la bidouille.

    Comme quelqu'un d'autre l'a rappelé, les normes existent depuis presque le début de l'existence du langage. Après vérif la première version de JavaScript (version Netscape par Brendan Eich) c'est fin 1995, la première version de la norme ECMA-262 c'est juin 1997. Donc bon ... Ça fait un bail que c'est normé.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  17. #57
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    Donc ton argument c'est de dire que le JavaScript n'est pas de bonne qualité parce que ses moteurs ne sont pas écrits avec JavaScript ?
    S'il te plait, lis les messages au lieu de t'auto-enflammer : je n'ai jamais dit que JS n'est pas de bonne qualité.

    Et pareil pour les normes : personne n'a dit que JS n'avait pas de norme. Pyramidev a juste dit que C++ est une norme de langage et non un logiciel.

  18. #58
    Membre extrêmement actif
    Profil pro
    Inscrit en
    décembre 2003
    Messages
    1 616
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 616
    Points : 3 830
    Points
    3 830
    Par défaut
    bah à mes débuts, on faisait du Javascript aussi coté serveur avec l'ASP classic (Jscript). Pas très couru en face de VBscript, mais moi ça me sert encore aujourd'hui.

    Et Je crois que Netscape avait aussi un produit coté serveur qui tournait en Javascript.

    Coté bidouille je veux bien mais déjà en 2000, j’étais support technique chez HP Grenoble pour l'installation d'un produit dénommé Backweb sales accelerator, qui implémentait déjà les principes d'une SPA, et où le DOM était entièrement manipulé en Javascript pour la construction de l'interface.

    Mais c'est vrai qu'à cette époque les clients lourds et les langages qui allaient avec étaient la norme.
    Émotion
    Infantilisation
    Culpabilisation

    Christophe Alévèque - 18 Mars 2021

  19. #59
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    181
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 181
    Points : 450
    Points
    450
    Par défaut
    Tant qu'on fera du soft jetable, du front pour l'essentiel en Javascript le principe de Tim Berners Lee sera appliqué à bon escient car plus personne ne fait évoluer un soft écrit en JS, le plus souvent après quelques années on jette et on recommence, éventuellement avec le nouveau framework js tendance du moment !

  20. #60
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 413
    Points : 19 363
    Points
    19 363
    Par défaut
    Encore un commentaire qui n'a aucun rapport avec le js. On peut faire n'importe quoi n'importe comment avec n'importe quel langage ou outil. Si des gens ont le pognon pour coder n'importe comment, ne pas investir dans leurs tests et réécrire tout à chaque changement de techno majeure ou évol fonctionnelle majeure c'est leur problème mais je ne pense pas que ça soit la majorité des cas, il y a globalement peu d'entreprises qui ont ce genre de moyens.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

Discussions similaires

  1. Quel est l'intérêt des mots clé get et set ?
    Par verbose dans le forum ActionScript 3
    Réponses: 2
    Dernier message: 30/09/2008, 16h19
  2. Signature des assemblies : quel est l'intérêt?
    Par AdamReith dans le forum Général Dotnet
    Réponses: 4
    Dernier message: 30/04/2008, 18h20
  3. Réponses: 3
    Dernier message: 16/01/2006, 19h53
  4. Mais quel est l'intérêt de XML ?
    Par darkbauer dans le forum XML/XSL et SOAP
    Réponses: 7
    Dernier message: 01/06/2004, 18h03
  5. Quel est l'intérêt des Services Web ??
    Par silvermoon dans le forum Débats sur le développement - Le Best Of
    Réponses: 19
    Dernier message: 12/02/2003, 22h28

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