Discussion :

[NoSmoking]

Bonjour,

Je ne comprends même pas pourquoi il y a des gens prêts à perdre du temps à venir effectuer une levée de bouclier dès que l'on critique JavaScript (c'est à dire plus ou moins chaque fois que l'on aborde le sujet ...

je me demande moi pourquoi à chaque fois que l'on parle de JavaScript les détracteurs arrivent de toutes parts alors que cela n'est même pas l'objet de la news ?


Perso quand même là où je me gausse c'est quand je lis de ta part

C'est ce que j'ai fait : je n'utilise plus JS que ce pour quoi il a été conçu : ajouter des interractions simples sur une page web.
Si je veux faire une application complexe j'utilise Angular.

[Sodium]

je me demande moi pourquoi à chaque fois que l'on parle de JavaScript les détracteurs arrivent de toutes parts alors que cela n'est même pas l'objet de la news ?

Pour la 100ème fois ... parce que JS est un langage de merde. Quand une techno a autant de détracteurs, l'hypothèse la plus raisonnable est généralement qu'il y a de bonnes raisons de ne pas aimer cette techno.
Il est difficile d'être développeur web sans avoir du à un moment où l'autre acquérir une certaine expérience de JS. Partir du principe que tous ses détracteurs le critiquent à cause d'une méconnaissance est donc une très lourde erreur.

Perso quand même là où je me gausse c'est quand je lis de ta part

Quand on critique les propos d'une personne, le minimum est d'amener un minimum d'arguments ou d'expliquer au moins ce que l'on critique.
Est-ce que tu te "gausses" parce que du code TypeScript est forcément retranscrit en JavaScript (bien dégueulasse) ? Si tu pars par là, tout code finit par être transformé en binaire, donc peut-être que l'on devrait tous coder en binaire (ou au moins en assembleur) ?

[Antjac]

De mon côté, je travaille depuis une bonne dizaine d'années avec ExtJS, de la version 2 à la version 6 aujourd'hui. Je développe notament un ERP interne pour mon groupe... franchement ça fait bien le job...

ExtJS 6 est beaucoup moins permissif, surtout quand tu es en MVC ou MVVM.

[Sodium]

Tiens, un autre truc rigolo avec JavaScript c'est que quand on le critique il y a systématiquement une armée d'acharnés sectaires qui viennent hurler que l'on n'a pas compris le langage, que l'on est débile et/ou incompétent, mais jamais le moindre intervenant pour poster un lien vers un exemple de code source bien écrit pour apporter une démonstration illustrant ses propos.

Une recherche Google sur "well written JavaScript code" ne renvoie rien de concluant, juste des bonnes pratiques de programmation de base (nommage de variables et fonctions...).

Du bon code PHP ? Déjà nettement moins compliqué : https://github.com/laravel/framework...Filesystem.php

Tout est limpide, une fonction fait rarement plus de 3 lignes et surtout n'est pas pollué à 80% par du bullshit spécifique au langage qu'il faut arriver à filtrer visuellement pour comprendre la logique de ce qui s'exécute derrière du genre MachinChose.prototype.maFonction = function() {...};

[Madmac]

... est la réponse de tout fan de JavaScript qui défend ce langage.

Je vais arrêter de perdre mon temps. Si tu défends JavaScript, c'est que tu n'es pas un développeur exigeant en terme de qualité de code, car JavaScript et code de qualité sont incompatibles, et je n'ai pas envie de discuter code avec des gens pour qui la clarté et la propreté de celui-ci sont une priorité absolue.

Par le passé, j'avais le même rapport avec Javascript. Mais la dernière évolution, particulièrement du coté de la POO, c'est révélé un très net progrès. Pour un programme comme l'éditeur Atom, je comprend l'utilité d'un typage strict. Mais pour les trucs qui tiennent sur deux pages, cette obsession me fais penser aux types qui porte des bretelles avec une ceinture.

[Sodium]

Par le passé, j'avais le même rapport avec Javascript. Mais la dernière évolution, particulièrement du coté de la POO, c'est révélé un très net progrès.

Yay, JavaScript a progressé, il en arrive peu à peu au niveau du PHP d'il y a 10 ans ... à condition de le retransformer derrière pour qu'il soit compatible avec les navigateurs.

Pour un programme comme l'éditeur Atom, je comprend l'utilité d'un typage strict. Mais pour les trucs qui tiennent sur deux pages, cette obsession me fais penser aux types qui porte des bretelles avec une ceinture.

La question n'est pas pourquoi utiliser un typage strict mais pourquoi s'en passer.
Avec un typage strict :
- tu sais ce qu'attend une classe ou fonction et ce qu'elle renvoie juste en lisant sa déclaration, la doc devient dans la majorité des cas superflue.
- l'IDE affiche les erreurs et éventuellement bloque à la compilation si une fonction reçoit une mauvaise valeur ou ne renvoie pas ce qu'elle devrait, évitant des tests inutiles et d'éventuels plantages de l'application en production
- l'iDE permet peut afficher directement les fonctions et variables d'une classe ainsi que ce qu'elle attend et renvoie

Le typage strict force également à de bonnes pratiques de programmation, ce qui donne au final un code plus simple et plus clair et d'éviter des trucs illisibles et inmaintables du genre "var data = unNombre; data = data.toString(); data = faisDiversesOpératiionsSurMaVariable(data); ...".

Et sérieusement, c'est tant de boulot que ça que de déclarer le type d'une variable ? Ca justifie d'obliger celui qui relira le code dans 6 mois (souvent soi-même) à relire le contenu d'une fonction pour comprendre ce qu'elle attend, fait et renvoie ?

Il en va de même pour l'encapsulation : on ne déclare pas une variable comme privée juste pour le fun, se taper du travail en plus ou faire plus "pro" mais pour s'assurer qu'elle ne pourra pas être modifiée ailleurs, compromettant le fonctionnement de l'application.

[Beginner.]

Si tu défends JavaScript, c'est que tu n'es pas un développeur exigeant en terme de qualité de code, car JavaScript et code de qualité sont incompatibles, et je n'ai pas envie de discuter code avec des gens pour qui la clarté et la propreté de celui-ci sont une priorité absolue.

J'aimerais bien savoir pourquoi il serait impossible de faire un code de qualité avec du JS alors que ce serait possible avec du TypeScript (puisqu'au final on produit du JS à partir de ce dernier) ? Si c'est parce que JS est trop permissif alors qu'est-ce qui empêche de s'imposer quelques "contraintes" ou plutôt "règles" ?

Par exemple pour le typage il y a quand même quelques moyens/outils dont on peut se servir, je pense à la JSDoc qui peut être prise en compte par certains outils d'assistance et il y a même un linter qui signale les erreurs liées à cela...

Mais peut-être que j'ai mal compris le problème ?

[Sodium]

J'aimerais bien savoir pourquoi il serait impossible de faire un code de qualité avec du JS alors que ce serait possible avec du TypeScript (puisqu'au final on produit du JS à partir de ce dernier) ? Si c'est parce que JS est trop permissif alors qu'est-ce qui empêche se s'imposer quelques "contraires" ou plutôt "règles"...

Il est impossible de faire du code de qualité parce que la syntaxe est dégueulasse dans tous les cas.
Pour ce qui est du code JS qui résulte du TypeScript, on en revient à ce que l'on disait : au final, on fait toujours du binaire, le langage de programmation n'est là que pour l'organiser.
S'imposer des contraintes ne sert à rien si le langage n'apporte aucune aide derrière. Exemple là en une ligne je sais ce que ma fonction fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public function doSomething(string variable): void { ... };

Pas besoin de commentaires ni de tests à l'intérieur de la fonction pour vérifier que la qu'elle ne reçoit pas des données de type incorrect.

Par exemple pour le typage il y a quand même quelques moyens/outils dont on peut se servir, je pense à la JSDoc qui peut être prise en compte par certains outils d'assistance et il y a même un linter qui signale les erreurs liées à cela...

Comme le disait l'oncle Bob, les commentaires sont en général de la pollution : un code clair n'a besoin que de très peu de documentation et encore faut-il penser à mettre à jour la doc lorsque l'on met à jour le code, ce qui est loin d'être évident même en étant attentif...

http://www.kyleblaney.com/software-b...a-failure.html

Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation.

Comments are not like Schindler's List. They are not "pure good." Indeed, comments are, at best, a necessary evil. If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much -- perhaps not at all.

[Marco46]

Une recherche Google sur "well written JavaScript code" ne renvoie rien de concluant, juste des bonnes pratiques de programmation de base (nommage de variables et fonctions...).

Quand je tape "Sodium" et "cerveau", le premier résultat qu'on obtient c'est "Le Sodium : une solution efficace contre le cerveau ...".

Coïncidence ?

Trêve de plaisanteries, on a compris ton message : Tu n'aimes pas le JavaScript parce qu'il n'y a pas de typage statique natif.

il y a systématiquement une armée d'acharnés sectaires qui viennent hurler que l'on n'a pas compris le langage, que l'on est débile et/ou incompétent

Pour le moment c'est toi l'acharné sectaire qui vient hurler que JavaScript c'est "de la merde" pour reprendre ton argumentaire.

Si ça te saoule tant que ça qu'est ce que tu fais sur cette partie du forum et sur ce fil de discussion ? Ça fait du bien quand ça fait mal c'est ça ton truc ?

[nhugodot]

Pour info, le créateur de JS, Brendan Eich, avait voulu prendre Scheme, un des deux LISP de l'époque, pour langage de script pour navigateur... Sa hiérarchie lui a demandé de prendre/pondre au contraire un langage de script proche de la syntaxe ultra habituelle de C/C++/Java, choix marketing mais pas des plus heureux, et lui a même imposé de le nommer JavaScript pour coller à Java... Le monde en eut été totalement autrement, si le choix de Eich, Scheme, avait été réalisé, avec un langage solide, extensible (macros) par nature, et surtout fonctionnel! On aurait pas perdu 20 ans et plus (les FP revenant enfin)..., autant de trous de sécurité, le parallélisme (CPU ARM multicores sur nos smartphones), etc. Sic!

"JavaScript est une merde": j'acquiesce non parce que ça l'est (et ça l'est...) mais parce que ça a détourné le monde des dev de vrais langages beaucoup, beaucoup mieux pensés, académiques, propres, puissants, lisibles, etc. Que SmallTalk et Lisp aient eu si peu de succès est triste... Mais le monde est rempli de succès de bricolages (de génies), à commencer par le PC et DOS/Windows... Et que même Linux, initié par un jeune étudiant et non pas une vraie organisation solide, ai tué les Unix et NT me laisse pantois sur cette industrie: bordel ou génie, ou les deux...

Pour revenir au sujet, après avoir tâté divers frameworks avec mes collègues, la messe est dite: chacun a ses forces et faiblesses, et mieux vaut fouiner la faiblesse que la force, et trouver là où le bat blessera: pour le mobile, je ne parie plus que sur React Native tant nous nous sommes cassé les dents sur les autres frameworks sur une fonctionnalité ou une autre, telle que les badges de notification pour une app iOS par exemple, ce que d'autres FW faisaient mal ou pas. Sans parler des motifs interactives, etc.: là, seul un FW vraiment mature ayant essuyé TOUS les plâtres récents (upgrade d'iOS, pour ne pas le nommer, Apple se foutant vraiment bien des dev hors de ceux qui ont mangé leur pomme...) est fiable. Et je connais nombre d'agences web, en France ou ailleurs, qui me l'ont aussi dit, après avoir testé d'autres FW pour le mobile...

(Cela dit, si j'avais le choix, sur seulement mobile, je prendrais Dart/Flutter... plus de JS ou TS ou... ni d'API native à binder, tout se fait dans Flutter même les composants graphiques, et c'est compilé, bref, c'est propre, loin de ces bricolages aussi géniaux soient-ils... mais ce n'est pas le sujet ici, pardon.)

Hors mobile, juste sur Web desktop, React vs Angular, c'est "le bazar vs la cathédrale" (voir ce que ça signifie sur wikipédia, instructif) , c'est "petite équipe stable" (agence web, start-up) versus "grande entreprise et équipe mouvante", de l'avis d'experts et formateurs sur les deux: Angular, en imposant ses choix et en étant très complet, permet à des nouveaux venus d'autres entreprises où ils l'utilisaient d'arriver en terrain connu et très balisé, d'être opérationnel rapidement. React permet trop de choix d'outils de son écosystème à la demande, mais inversement permet aussi de choisir ce qu'on veut selon le besoin.

Tout ça me fait penser aux OS, les distros GNU/Linux (comparables à la demande pour coller au plus près du besoin, optimales) vs Windows ("je fais tout pareil, partout, je suis gros mais facile, c'est pareil partout"...), non?

Vive WASM, j'attends que Python y passe... enfin quelque chose de lisible... (oups, ok, troll inside, je sors...)

ps:regardez ReactXP de Microsoft avec lequel ils ont fait leur Skype, et les initiatives équivalentes React Native for Web et React DOM (et https://platform.uno), ça serait cocasse que ce soient les langages mobile natifs qui aillent sur le Web grâce à WASM, et tuent JS, in fine, plutôt que le contraire comme avec React Native, non?

[Beginner.]

Il est impossible de faire du code de qualité parce que la syntaxe est dégueulasse dans tous les cas.
Pour ce qui est du code JS qui résulte du TypeScript, on en revient à ce que l'on disait : au final, on fait toujours du binaire, le langage de programmation n'est là que pour l'organiser.
S'imposer des contraintes ne sert à rien si le langage n'apporte aucune aide derrière. Exemple là en une ligne je sais ce que ma fonction fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public function doSomething(string variable): void { ... };

Pas besoin de commentaires ni de tests à l'intérieur de la fonction pour vérifier que la qu'elle ne reçoit pas des données de type incorrect.

Je ne suis pas sûr de te suivre parce que je ne connais pas TypeScript alors : tu veux dire que la vérification comme quoi on passe bien une string en argument est faite automatiquement, c'est ça ? Si oui ben apparemment il faut quand même ajouter le mot "string", non ? Bon je t'accorde que c'est plus concis que de mettre une ligne de JSDoc (oui parce que comme déjà dit il y a des outils qui prennent en compte la JSDoc, c'est-à-dire tu peux préciser le type des paramètres et c'est pris en compte par le linter par exemple) mais en fait il y a même des outils qui sont capables de deviner le type du/des paramètre(s) de la fonction (et même celui de la valeur retournée) et ils peuvent même écrire la JSDoc automatiquement...

Après la JSDoc (qui indique le type des paramètres et celui de l'éventuel valeur retournée, une description,...) on aime ou on n'aime pas, mais cela peut être très utile et elle est très utilisée en Java malgré que Java soit un langage typé et moins permissif d'ailleurs j'ai l'impression que TypeScript ressemble à Java...

Comme le disait l'oncle Bob, les commentaires sont en général de la pollution : un code clair n'a besoin que de très peu de documentation et encore faut-il penser à mettre à jour la doc lorsque l'on met à jour le code, ce qui est loin d'être évident même en étant attentif...

Qu'on soit d'accord ou pas de toute façon il me semble que ce qu'il dit ne vise pas spécifiquement JS, non ? A moins que tu penses qu'un code écrit en JS ne peut en aucun cas être clair et nécessiterait donc forcément beaucoup de documentation pour être clarifié ???

Franchement parfois le code aura beau être clair il n’empêche qu'il peut être difficile (sans documentation) de comprendre ce que font certains algorithmes...

[Madmac]

Yay, JavaScript a progressé, il en arrive peu à peu au niveau du PHP d'il y a 10 ans ... à condition de le retransformer derrière pour qu'il soit compatible avec les navigateurs.



La question n'est pas pourquoi utiliser un typage strict mais pourquoi s'en passer.
Avec un typage strict :
- tu sais ce qu'attend une classe ou fonction et ce qu'elle renvoie juste en lisant sa déclaration, la doc devient dans la majorité des cas superflue.
- l'IDE affiche les erreurs et éventuellement bloque à la compilation si une fonction reçoit une mauvaise valeur ou ne renvoie pas ce qu'elle devrait, évitant des tests inutiles et d'éventuels plantages de l'application en production
- l'iDE permet peut afficher directement les fonctions et variables d'une classe ainsi que ce qu'elle attend et renvoie

Le typage strict force également à de bonnes pratiques de programmation, ce qui donne au final un code plus simple et plus clair et d'éviter des trucs illisibles et inmaintables du genre "var data = unNombre; data = data.toString(); data = faisDiversesOpératiionsSurMaVariable(data); ...".

Et sérieusement, c'est tant de boulot que ça que de déclarer le type d'une variable ? Ca justifie d'obliger celui qui relira le code dans 6 mois (souvent soi-même) à relire le contenu d'une fonction pour comprendre ce qu'elle attend, fait et renvoie ?

Il en va de même pour l'encapsulation : on ne déclare pas une variable comme privée juste pour le fun, se taper du travail en plus ou faire plus "pro" mais pour s'assurer qu'elle ne pourra pas être modifiée ailleurs, compromettant le fonctionnement de l'application.

Je te répondrais: Est-ce si difficile de lire la documentation ?

Je ce n'est pas parce qu'un langage n'est pas typé qu'il n'y a pas de contrôle des valeurs pour autant. Autrement comment voudrais-tu faire des tests ? Beaucoup de programmeurs ont du mal à comprendre que Ruby soit un langage strictement typé malgré le fait qu'il n'y a de déclaration de type. Une assignation de variable avec une valeur est une méthode efficace de remplacer les déclarations de type. Que ce sois Ruby ou JavaScript. Après une première assignation de valeur une variable devient typée d'une façon définitive. Il en va de même pour les paramètres de fonction et de méthode.

Tu as peut-être entendu l'expression garbage-in garbage-out. Qui se traduirait par merde à l'entrée, merde la sortie. C'est vrai, mais ce que le concept doit rappeler au programmeur, est que seulement les entrées nécessité une vérification. SI tu as des tomates à l'entrée, les chances d'avoir du jus de pommes à la sortie sont nulles. Et c'est un point important, car un programmeur peut limiter les contrôles de types au strict minimum, alors que la majorité de compilateur n'y arrive pas. Donc avec le typage, tu as également une réduction de performance. Et pour un langage interprété, l'impact est encore plus prononcé. Parce qu'un langage interprété ne fait pas de multiple passe pour trouvé des façons d'optimiser.

JavaScript n'a pas été bricolé. Il a été fabriqué à une époque ou les ordinateurs n'étaient pas très performants.

[Sodium]

Je ne suis pas sûr de te suivre parce que je ne connais pas TypeScript alors : tu veux dire que la vérification comme quoi on passe bien une string en argument est faite automatiquement, c'est ça ? Si oui ben apparemment il faut quand même ajouter le mot "string", non ?

Ce n'est pas une syntaxe spécifique à TypeScript mais plutôt commune à la majorité des langages orientés objet dérivés du C. Par ton ignorance, tu prouves assez bien mon propos : les défenseurs de JavaScript sont en majorité des développeurs peu expérimentés qui n'ont pas acquis de bonnes pratiques de programmation.

Qu'on soit d'accord ou pas de toute façon il me semble que ce qu'il dit ne vise pas spécifiquement JS, non ? A moins que tu penses qu'un code écrit en JS ne peut en aucun cas être clair et nécessiterait donc forcément beaucoup de documentation pour être clarifié ???

De un oui, c'est ce que je pense, de deux en plus de ça la syntaxe de JavaScript est merdique, bourrée de mots-clés qui polluent la lecture du code.

Je te répondrais: Est-ce si difficile de lire la documentation ?

Si je dois lire la documentation, c'est dans la majorité des cas que le programmeur n'a pas fait son boulot correctement.

JavaScript n'a pas été bricolé. Il a été fabriqué à une époque ou les ordinateurs n'étaient pas très performants.

Tu ne connais visiblement pas bien l'histoire de JavaScript, et la fin de ton message est juste stupide : C++ ou Java existaient déjà depuis longtemps lorsque JavaScript a débarqué.

[melka one]

tu n'aime pas la poo ? voir la programmation tout court ?

(Cela dit, si j'avais le choix, sur seulement mobile, je prendrais Dart/Flutter... plus de JS ou TS ou... ni d'API native à binder, tout se fait dans Flutter même les composants graphiques, et c'est compilé, bref, c'est propre, loin de ces bricolages aussi géniaux soient-ils... mais ce n'est pas le sujet ici, pardon.)

peut pas mieux faire

[blbird]

Javascript est un excellent langage. Il suffit de s'y intéresser un peu, de ne pas être bloqué comme beaucoup sur le langage actuel qu'on vénère (Java, C#, Php, Python, C/C++ ou autre).

Chaque langage a ses avantages et ses inconvénients.

Mais on ne peut pas laisser dire que JS est un mauvais langage parce que :

• il n'est pas multithread : on voit bien NodeJS monothread qui a éclaté en perf (surtout en montée en charge...!!) d'autres serveurs web très connus et utilisés. Le créateur de NodeJS l'explique très bien d'ailleurs ici :
• il n'y a pas de typage fort : ici on est dans le cadre des capacités des développeurs à définir des contrats et à les respecter sans qu'on leur tienne la main, rien d'autre
• il n'y a pas de POO : JS est en POP, qui, une fois qu'on l'a compris, est tout aussi intéressant (voir plus pour moi) que la POO

Les exemples d'applications grands publics ayant un succès phénoménale existent bien :

• Discord : 50 MILLIONS de users toute plateforme confondue, 90% de code identique sur toutes les platesformes : Web, PC, Linux, Mobiles
• Visual Studio Code : un excellent éditeur
• Beaucoup des sites webs les plus utilisés

Bref, comme souvent, les détracteurs d'un langage communément utilisé n'ont tout simplement pas compris l'intérêt du langage et encore moins ses principes et son fonctionnement. Ils s'arrêtent à la comparaison de leur langage ou concepts favoris, sans chercher à sortir de leur zone de confort. Triste.

[Beginner.]

Ce n'est pas une syntaxe spécifique à TypeScript mais plutôt commune à la majorité des langages orientés objet dérivés du C.

Ouais mais là on ne parle pas des autres langages, dans ce contexte tu critiques JS et tu défends TypeScript alors si maintenant tu compares JS aux autres langages, on ne vas pas s'en sortir, tu aimes bien te disperser apparemment...

Par ton ignorance, tu prouves assez bien mon propos : les défenseurs de JavaScript sont en majorité des développeurs peu expérimentés qui n'ont pas acquis de bonnes pratiques de programmation.

Tu me fait rire des fois, tu as pleins de préjugés... D'abord je ne défends pas spécialement JS (j'ai moi aussi trouvé certains codes déroutants à cause de ce que permet la syntaxe du JS) ensuite je suis passé par le C/C++/Java avant JS et c'est vrai qu'une des choses qui m'avait troublé c'est qu'au début je m'attendais à retrouver avec JS toute l'assistance à laquelle j'étais habitué avec Java, j'ai mis du temps à trouver des outils qui s'en approchaient mais ils existent...

De un oui, c'est ce que je pense, de deux en plus de ça la syntaxe de JavaScript est merdique, bourrée de mots-clés qui polluent la lecture du code.

J'ai vraiment du mal à te suivre, je crois que tu vas me pousser à jeter un œil à TypeScript car quelques choses me dit que ce que tu reproches là à JS se retrouve aussi avec TypeScript. Par exemple les mots-clés du JS qui polluent la lecture du code comme tu dis ne se retrouvent-ils pas dans TypeScript ? Quelque chose me dit qu'il y en a même plus dans TypeScript...

Enfin bref...

[Sodium]

il n'y a pas de typage fort : ici on est dans le cadre des capacités des développeurs à définir des contrats et à les respecter sans qu'on leur tienne la main, rien d'autre

Non, encore une fois le typage fort n'est pas qu'une question de fiabilité du code, c'est aussi une question de lisibilité...

il n'y a pas de POO : JS est en POP, qui, une fois qu'on l'a compris, est tout aussi intéressant (voir plus pour moi) que la POO

Tu te trompes toi-même... JS est totalement orienté objet, il n'est pas orienté classes... bref même les afficionados du langage ne le comprennent pas visiblement.
Et non, la programmation que ce soit par prototype ou par fonctions qui contiennent d'autres fonctions (qui est probablement l'un des concepts les plus stupides que j'ai jamais connus) n'est ni intéressante, ni lisible, c'est juste de la pollution inutile.

Les exemples d'applications grands publics ayant un succès phénoménale existent bien :

Discord : 50 MILLIONS de users toute plateforme confondue, 90% de code identique sur toutes les platesformes : Web, PC, Linux, Mobiles
Visual Studio Code : un excellent éditeur
Beaucoup des sites webs les plus utilisés

Je n'ai pas dit qu'on ne pouvait pas faire des applications à succès, j'ai dit qu'on ne pouvais pas faire du code propre, maintenable et lisible.
Et Visual Studio Code est codé en TypeScript...

Ouais mais là on ne parle pas des autres langages, dans ce contexte tu critiques JS et tu défends TypeScript alors si maintenant tu compares JS aux autres langages, on ne vas pas s'en sortir, tu aimes bien te disperser apparemment...

Je critique JS en tant que langage de programmation et je lui oppose son "concurrent" principal sur son terrain de chasse, je ne vois pas bien la contradiction.
Moi faire du TypeScript, du Java, du PHP ou du C++ je m'en fous, je veux juste avoir du code propre.

D'abord je ne défends pas spécialement JS (j'ai moi aussi trouvé certains codes déroutants à cause de ce que permet la syntaxe du JS) ensuite je suis passé par le C/C++/Java avant JS et c'est vrai qu'une des choses qui m'avait troublé c'est qu'au début je m'attendais à retrouver avec JS toute l'assistance à laquelle j'étais habitué avec Java, j'ai mis du temps à trouver des outils qui s'en approchaient mais ils existent...

Oui tu soulèves bien le problème ... JavaScript est tellement un mauvais langage que tout le monde en fait parce qu'il est populaire mais presque personne ne l'utilise sans un ou plusieurs frameworks / librairies / pseudos-langages par dessus ...

J'ai vraiment du mal à te suivre, je crois que tu vas me pousser à jeter un œil à TypeScript car quelques choses me dit que ce que tu reproches là à JS se retrouve aussi avec TypeScript. Par exemple les mots-clés du JS qui polluent la lecture du code comme tu dis ne se retrouvent-ils pas dans TypeScript ? Quelque chose me dit qu'il y en a même plus dans TypeScript...

Eh bien penches-toi sur TypeScript.
Par mots-clés je parle de la manière de déclarer les prototypes, fonctions dans des fonctions, variables dans des fonctions, etc.
Dans l'exemple "var machin.prototype.maFonction = function() => { .. }" tu as 3 bons quarts du code qui ne servent à rien par rapport à "function maFonction() { };" ou même "maFonction() { };" dans les langages "normaux".

[Marco46]

Et Visual Studio Code est codé en TypeScript...

TypeScript c'est un superset du JavaScript. 95% de ce que tu utilises quand tu écris ton appli Angular c'est pas les fonctionnalités ajoutées par TypeScript c'est du js vanilla.

Je n'ai pas dit qu'on ne pouvait pas faire des applications à succès, j'ai dit qu'on ne pouvais pas faire du code propre, maintenable et lisible.

Et c'est faux. Si tu étais honnête avec toi-même tu dirais que tu as des difficultés à lire un programme écrit avec un paradigme fonctionnel sans typage statique.

[blbird]

Non, encore une fois le typage fort n'est pas qu'une question de fiabilité du code, c'est aussi une question de lisibilité...

Le fait de rendre un code lisibile ou non a peu à voir avec le langage lui-même, mais avec le développeur : à condition d'avoir compris le langage, condition première évidemment, ce qui n'est clairement pas ton cas. Il est tout à fait possible de produire du code intelligible dans n'importe quel langage. La notion de contrats ainsi que la documentation associée sont là exactement pour ca.

Tu te trompes toi-même... JS est totalement orienté objet, il n'est pas orienté classes... bref même les afficionados du langage ne le comprennent pas visiblement.
Et non, la programmation que ce soit par prototype ou par fonctions qui contiennent d'autres fonctions (qui est probablement l'un des concepts les plus stupides que j'ai jamais connus) n'est ni intéressante, ni lisible, c'est juste de la pollution inutile.

Déjà, se tromper soi-même : drôle d'expression qui ne veut rien dire. En fait, t'es juste un petit troll qui pense être meilleur que les autres, mais qui n'a juste rien compris aux concepts dont tu parles. Et en plus tu montres continuellement ton incompétence en agressant les autres, ainsi que le langage que tu cibles par ton ignorance. Allez une petite aide sur la différence et l'intérêt, pourtant d'une évidence crasse, de la composition sur l'héritage :

Je n'ai pas dit qu'on ne pouvait pas faire des applications à succès, j'ai dit qu'on ne pouvais pas faire du code propre, maintenable et lisible.

Tiens donc. Et explique-moi comment on peut faire des applications aussi importantes par exemple que Discord, avec 90% de code commun sur toutes les plateformes, utilisé par 50 millions de personnes à travers le monde, avec un langage avec lequel on ne pourrait soit-disant par faire de code propre, maintenable et lisible? Rigolo va.

Oui tu soulèves bien le problème ... JavaScript est tellement un mauvais langage que tout le monde en fait parce qu'il est populaire mais presque personne ne l'utilise sans un ou plusieurs frameworks / librairies / pseudos-langages par dessus ...

Comme tout les langages dès que tu veux faire du code découplé, maintenable, et en plus forcément lisible, des frameworks structurants voient le jour. Rien d'étonnant, à part si on ne sait pas de quoi on parle...

Eh bien penches-toi sur TypeScript.
Par mots-clés je parle de la manière de déclarer les prototypes, fonctions dans des fonctions, variables dans des fonctions, etc.
Dans l'exemple "var machin.prototype.maFonction = function() => { .. }" tu as 3 bons quarts du code qui ne servent à rien par rapport à "function maFonction() { };" ou même "maFonction() { };" dans les langages "normaux".

Tu n'as effectivement rien compris au prototypage objet. Ca te semble illisible parce que tu es mauvais, alors tu décides de traiter le langage de mauvais pour excuser ton incompétence. Rigolo #2.

Pas besoin de répondre, tu passes en ignore list directe.

Ce genre de troll déconsidère fortement le forum, tout en empêchant de discuter du sujet. Il ne discute pas, il affiche son incompétence et aggresse les autres qui eux, ont pour la plupart pris la peine de comprendre. C'est dommage, sur un forum orienté entre-aide.

Et c'est faux. Si tu étais honnête avec toi-même tu dirais que tu as des difficultés à lire un programme écrit avec un paradigme fonctionnel sans typage statique.

C'est exactement ca!

[Sodium]

TypeScript c'est un superset du JavaScript. 95% de ce que tu utilises quand tu écris ton appli Angular c'est pas les fonctionnalités ajoutées par TypeScript c'est du js vanilla.

Pour la centième fois cet argument n'a aucune pertinence. On s'en fout de en quoi le code est transformé au final, ce qui importe au programmeur c'est le langage dans lequel il code. Après ça peut bien être transformé en JavaScript, en ActionScript, en C ou en ook je n'en ai absolument rien à foutre, c'est le job du transcompilateur, pas le miens, et personne (à moins d'être masochiste) n'ira jamais lire le code final en JavaScript.

Et c'est faux. Si tu étais honnête avec toi-même tu dirais que tu as des difficultés à lire un programme écrit avec un paradigme fonctionnel sans typage statique.

Euh je n'ai commencé à utiliser le typage statique qu'il y a 2-3 ans... L'absence de typage statique n'est qu'un problème parmi d'autres.

En fait, t'es juste un petit troll qui pense être meilleur que les autres, mais qui n'a juste rien compris aux concepts dont tu parles

I'm rubber you're glue...

Allez une petite aide sur la différence et l'intérêt, pourtant d'une évidence crasse, de la composition sur l'héritage

Je ne vois pas bien le rapport, on peut très bien faire de la composition en PHP ...
https://r.je/you-do-not-need-inheritance-oop.html
Bref, encore une preuve d'ignorance.

Tiens donc. Et explique-moi comment on peut faire des applications aussi importantes par exemple que Discord, avec 90% de code commun sur toutes les plateformes, utilisé par 50 millions de personnes à travers le monde, avec un langage avec lequel on ne pourrait soit-disant par faire de code propre, maintenable et lisible? Rigolo va.

De la même manière que des mecs ont érigé des temples et des pyramides majestueux il y a 5000 ans avec des rondins.
On peut faire n'importe quoi avec n'importe quoi à condition d'y consacrer suffisamment d'efforts. On le fera juste moins vite et bien. Si tu aimes travailler avec des rondins tant mieux pour toi, perso je préfère utiliser une grue...

Ca te semble illisible parce que tu es mauvais, alors tu décides de traiter le langage de mauvais pour excuser ton incompétence.

C'est illisible parce que c'est illisible. Quand je lis du code, je ne devrais pas avoir à filtrer visuellement près de 3/4 d'éléments inutiles pour comprendre la logique.