Discussion :

[Invité]

justement pour encore faciliter le full fonctionnel. ^^'

JavaScript permet un style vaguement fonctionnel mais de là à parler de "full fonctionel", il ne faut pas exagérer. Et d'ailleurs combien d'entre vous ont fait des projets un peu sérieux avec des langages comme Elm ou Scala ? Et combien ensuite ont continué à apprécier JavaScript de la même façon ?

[Beginner.]

Par curiosité j'ai jeté un œil à TypeSrcipt, en particulier j'ai voulu savoir ce qu'il en était des variables privées eh bien le résultat de la compilation nous donne un code JS où les variables (déclarées privées en TS) ne sont pas "privées" du tout, ce sont des variables "normales"... Pourtant en JS on peut faire quelque chose qui se rapproche d'une variable privée (au sens de "non accessible" par une instance) en utilisant le scope d'une fonction...

Ca a très peu d'importance. L'utilité d'un propriété ou méthode privée, c'est d'empêcher qu'elle puisse être utilisée pour de mauvaises raison par les codeurs sur l'application.
Si après, lors de l'exécution, quelqu'un veut s'amuser à bidouiller dans les outils de développement pour accéder ce à quoi il ne devrait pas... eh bien tu ne peux pas faire grand-chose, c'est le principe même des langages interprétés par le navigateur.

Oui je connais l’intérêt des données privée et je répète qu'en JS tu peux avoir des données qui soient réellement privées (privé au sens de "non accessible" par une instance) donc là pour le coup* c'est JS qui peut faire une chose que TS ne fait pas apparemment (mais franchement il pourrait le faire je pense)...

* Je te rappelle quand même tes propos où tu te moquais de JS sur ce point (variables privées) :

De deux habon, JavaScript a du typage statique, du typage des valeurs de retour, de l'injection de dépendances, les interfaces, la notion de variables privées maintenant ? Des déclarations de propriétés en dehors des fonctions d'une classe ? Whaou il faut absolument que tu me montres ça !

Ensuite j'ai testé le compilateur TS ici : http://www.typescriptlang.org/play avec le code ci-après :

Code javascript :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class MaClass {
    private maVar: string = "je suis privée...";   
    constructor(message: string) {
        this.maVar += message;
    }
    display() {
        console.log("display : ", this.maVar);
    }
}
 
var obj = new MaClass("En théorie !")
obj.display(); // affiche : "je suis privée...En théorie !"
obj.maVar = "le compilateur signale que maVar est privée mais il compile quand même !!!";
console.log(obj.maVar); // affiche bien le nouveau contenu (la phrase ci-dessus) !
 
var str = "maVar";
obj[str] = "Là j'accéde à la variable maVar et le compilateur ne signale rien !"
 
obj.display(); // // affiche bien le nouveau contenu (la phrase ci-dessus) !

Eh bien contrairement à ce que tu as l'air de croire on peut accéder à la variable "maVar" dans le code (pas besoin des "outils de développement" comme tu dis)...

Je l'ai fait de deux manières :

1-la première de façon classique : obj.maVar = "...", là le compilateur me signale que "maVar" est privée mais il compile quand même !
2-La deuxième avec l'opérateur [] : var str = "maVar"; obj[str] = "...", Là j’accède à la variable maVar et le compilateur ne signale rien !

Le compilateur n’empêche donc rien, il avertit dans le premier cas et ne voit rien dans le second...

On en revient aux bonnes pratiques qu'il faut adopter...

Dans la déclaration de fonction suivante :

Code :

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

anticore.fetcher = function (element) {

Tu as une moitié du code qui ne sert à rien. Du code qui ne sert à rien, c'est de la pollution qui nuit à la compréhension du code.

La syntaxe suivante est beaucoup plus claire et concise, ce n'est donc que du bon sens de l'adopter :

Code :

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

1
2
3
4
 
class Anticore {
    fetcher(element) {}
}

Dans l'autre fil tu avais donné un meilleur exemple (malgré l'erreur) et là je ne comprend pas l'analogie :

- Si par exemple anticore est un objet (une instance) alors anticore.fetcher = function (element) { ajoute juste une fonction à cet objet, rien à voir avec une classe...

- Si par exemple anticore est un constructeur alors ton instruction ajoute une méthode statique et là il faut ajouter le mot clé "static" dans la classe et il faut une majuscule "Anticore"...

Je pense que tu voulais plutôt comparer avec Anticore.prototype.fetcher = function (element) { }; et justement par rapport à ça tu disais :

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".

Alors je répète qu'en ES6 tu as aussi les class si tu ne veux pas utiliser les prototypes et tu peux faire exactement le genre de chose que tu as écrit :

Code javascript :

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

1
2
3
4
5
 
class Anticore {
    constructor() { };
    fetcher(element) { };
}

Au lieu de par exemple :

Code javascript :

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

1
2
3
4
5
6
 
var Anticore =  (function () {
    function Anticore() { } ;
    Anticore.prototype.fetcher = function (element) { };
    return Anticore;
}());

PS : Ceci dit c'est vrai que je trouve qu'il y a des choses intéressantes avec TypeScript et d'ailleurs il semble qu'on puisse utiliser l’assistance aussi pour du code JS ce qui est intéressant...

[Lcf.vs]

@Beginner : Il ne s'agit pas d'un constructeur mais d'une simple API (objet proposant des méthodes). Si t'es curieux : https://github.com/Lcfvs/anticore

Au passage, si tu cherches un bon IDE JS, j'connais pas mieux que WebStorm.

[Beginner.]

@Lcf.vs :

Ok merci. En fait pour le nom je pense qu'il l'a juste pris comme exemple et qu'il voulait parler d'une manière générale...

Et oui je connais WebStorm, Sylvain nous en avait parlé...

En gratuit il y a VS Code qui est bien et Eclipse avec Tern (mis au point par un membre de ce forum).

[Invité]

On en revient aux bonnes pratiques qu'il faut adopter...

Ou utiliser un vrai langage fonctionnel avec un vrai typage, comme Elm ou Scala...

[youtpout978]

Si les sites sont devenus si lourd et lent c’est parce qu’on a voulu porter des appli bureau dans le web, de la spa de partout, déchargeant le rendu côté client et non plus côté serveur, je dev sur le web depuis quelques années j’ai vécu cette période de transition où on faisait le rendu pratiquement que côté serveur avec très peu d’ajax, au site rendu côté clien full ajax.
On a voulu aussi porter des applications bureautiques dans le web, parce qu’on perd la contrainte de déploiement poste par poste, sauf qu’au final ton application demande plus de ressources pour fonctionner.
Et oui le js n’avait pas été inventé à l’origine pour ceux que l’on en fait aujourd’hui, obligeant l’ajout de surcouche ou bibliothèque tierce/framework, heureusement ecmascript a bien évolué ces derniers temps mais pas forcément supporter par tous les navigateurs, au final notre salut viendra de webassembly nous faisant oublier à certain quel «*merde*» c’était le js.

[Invité]

au final notre salut viendra de webassembly nous faisant oublier à certain quel «*merde*» c’était le js.

Tu as déjà fait du webassembly ? Parce moi oui, et pour l'instant je n'appellerais vraiment pas ça un salut.

[Sodium]

Le saviez-tu ?
La première version de JavaScript a été codée par une seule personne en 10 jours et le choix d'utiliser des prototypes plutôt que des classes ainsi que le typage faible sont uniquement le résultat de contraintes de temps.

https://thenewstack.io/brendan-eich-...erently-today/

Dans l'autre fil tu avais donné un meilleur exemple (malgré l'erreur) et là je ne comprend pas l'analogie :

- Si par exemple anticore est un objet (une instance) alors anticore.fetcher = function (element) { ajoute juste une fonction à cet objet, rien à voir avec une classe...

- Si par exemple anticore est un constructeur alors ton instruction ajoute une méthode statique et là il faut ajouter le mot clé "static" dans la classe et il faut une majuscule "Anticore"...

Je pense que tu voulais plutôt comparer avec Anticore.prototype.fetcher = function (element) { }; et justement par rapport à ça tu disais :

Tu voudras bien m'excuser de faire des erreurs sur une syntaxe merdique que je n'utilise plus depuis 2-3 ans. Il fallait bien évidemment lire Anticore avec une majuscule et le var était superflu sur l'autre topic. Je n'ai pas honte d'avoir fait des erreurs, ce n'est qu'une preuve supplémentaire du fait que la syntaxe très verbeuse et remplie de termes redondants de JavaScript mène plus facilement à des problèmes.

[youtpout978]

Tu as déjà fait du webassembly ? Parce moi oui, et pour l'instant je n'appellerais vraiment pas ça un salut.

On parle d’une technologie récente et en cours de développement si je me trompe pas, donc bosser sur du bêta je pense pas que ça soit génial pour le moment mais j’espère que d’ici 2020 on pourra vraiment faire des sites avec.

Et après webassembly peut être compilé depuis n’importe quel langage si tu veux rester sur js tu pourras sûrement, mon but étant de faire du C# de mon côté et MS bosse actuellement sur Blazor qui semble être un bon projet.
L’intérêt de cette technologie sera quand même de contenter un maximum de dev et d’avoir quelques chose de bien performant par rapport a du js interprété classique.

Je ne sais pas sur quoi tu as bossé dessus c’est assez vague au final ta critique pour un truc en bêta en plus.

[fredoche]

Sodium

Le saviez-tu ?
La première version de JavaScript a été codée par une seule personne en 10 jours et le choix d'utiliser des prototypes plutôt que des classes ainsi que le typage faible sont uniquement le résultat de contraintes de temps.

https://thenewstack.io/brendan-eich-...erently-today/

Je sais pas où c'est que tu as appris à lire l'anglais Sodium mais je ne lis rien de cela dans le texte que tu donnes en lien.
Faut arrêter de fantasmer, et prendre vos désirs d'autres choses pour des réalités.

L'une des choses importantes qui est dite et qui rend compte de la réalité d'aujourd'hui :

“It was also an incredible rush job, so there were mistakes in it. Something that I think is important about it is that I knew there would be mistakes, and there would be gaps, so I made it very malleable as a language.”

Et bon dieu s'il y a bien un langage multiforme, c'est le javascript, puisque vous en êtes à parler de typescript, classes et POO, webassembly, programmation fonctionnelle... Tout ça dans ce pauvre langage de script pour amateurs codeurs de pages web

Le regret exprimé rend compte d'une demande d'un de ses collègues sur la capacité de comparer un nombre avec une string, ce quyi a obligé l'introduction d'un deuxième opérateur de comparaison d'égalité incluant le type : le fameux "==="

Pour le reste je sais pas où tu vois cité typage fort ou faible ni prototypes versus classes.

[Sodium]

Je sais pas où c'est que tu as appris à lire l'anglais Sodium mais je ne lis rien de cela dans le texte que tu donnes en lien.
Faut arrêter de fantasmer, et prendre vos désirs d'autres choses pour des réalités.

C'était sur une autre source que j'ai eu la flemme de retrouver.
Cela coule de toute manière de source car JavaScript devait à la base être calqué sur Java, c'est donc bien par manque de temps que nombre de ses features n'ont pas pu être implémentées.
Rappelons également que le seul but de JavaScript a ses débuts était d'ajouter des interactions très simples à une page web. Le fait qu'il soit aujourd'hui utilisé pour des applications complexes est un accident industriel.

Le fantasme, c'est bel et bien de penser que JavaScript est une solution élégante aux problématiques du web d'aujourd'hui. Soutenir que :

Code :

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

1
2
3
4
5
6
 
var MonObjet = function() {}
 
MonObjet.prototype.fonction1 = function() {}
MonObjet.prototype.fonction2 = function() {}
MonObjet.prototype.fonction3 = function() {}

est plus lisible et plus instinctif que

Code :

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

1
2
3
4
5
6
 
class MaClasse {
fonction1() {}
fonction2() {}
fonction3() {}
}

est tout simplement de la mauvaise foi et de l'aveuglement.

[fredoche]

Retrouve donc cette source qui dit cela explicitement, je suis curieux, parce que le "ça coule de source", permets-moi d'en douter

[melka one]

je me répète si l’accumulation du mot prototype t’irrite les yeux fait de cette façon

Code :

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

1
2
3
4
5
6
7
8
9
10
 
var MonObjet = function() {}
 
MonObjet.prototype={
 
fonction1 : function() {},
fonction2 : function() {},
fonction3 : function() {}
 
}

[Lcf.vs]

La première version de JavaScript a été codée par une seule personne en 10 jours...

Alors, perso, je ne vois pas trop en quoi le nombre de personnes ou le temps nécessaires à l'impulsion initiale d'un projet influe sur ce qu'apporte le langage. C'est le cas de presque tout ce qu'on utilise.

... et le choix d'utiliser des prototypes plutôt que des classes ainsi que le typage faible sont uniquement le résultat de contraintes de temps.

Fake news, ce n'est pas une question de contraintes de temps mais une volonté de vouloir avoir un langage inspiré du Java... mais plus facile à apprendre, pour les débutants... je pense qu'il a d'ailleurs sacrément bien accompli sa mission.

Rappelons également que le seul but de JavaScript a ses débuts était d'ajouter des interactions très simples à une page web. Le fait qu'il soit aujourd'hui utilisé pour des applications complexes est un accident industriel.

Alors, là aussi, tu ne sais pas de quoi tu parles, à l'origine, le JS (à l'époque, LiveScript) était conçu pour un usage système... l'usage web client n'est qu'un détournement de technologie.

[Sodium]

Alors, perso, je ne vois pas trop en quoi le nombre de personnes ou le temps nécessaires à l'impulsion initiale d'un projet influe sur ce qu'apporte le langage. C'est le cas de presque tout ce qu'on utilise.

Mais bien entendu, il est connu que l'on obtient toujours le meilleur résultat en rushant un projet avec une bonne dose de stress et de manque de sommeil

Fake news, ce n'est pas une question de contraintes de temps mais une volonté de vouloir avoir un langage inspiré du Java... mais plus facile à apprendre, pour les débutants... je pense qu'il a d'ailleurs sacrément bien accompli sa mission.

La facilité d'apprentissage d'un langage n'a aucun rapport avec le fait d'utiliser ou non des classes. Le système de classes est bien plus logique et compréhensible pour un débutant que le prototypage car il est encré dans le réel : une classe représente généralement un concept de la vie courante avec des propriétés et actions possibles.

Alors, là aussi, tu ne sais pas de quoi tu parles, à l'origine, le JS (à l'époque, LiveScript) était conçu pour un usage système... l'usage web client n'est qu'un détournement de technologie.

Je n'ai lu cela nulle part ...

https://auth0.com/blog/a-brief-history-of-javascript/

The prototype of Mocha was integrated into Netscape Communicator in May 1995. In short time, it was renamed to LiveScript. At the moment, the word "live" was convenient from a marketing point of view. In December 1995, Netscape Communications and Sun closed the deal: Mocha/LiveScript would be renamed JavaScript, and it would be presented as a scripting language for small client-side tasks in the browser, while Java would be promoted as a bigger, professional tool to develop rich web components.

[Lcf.vs]

Mais bien entendu, il est connu que l'on obtient toujours le meilleur résultat en rushant un projet avec une bonne dose de stress et de manque de sommeil

Tu ne lis que ce qui t'arrange, toi... j'ai pourtant bien précisé l'impulsion de départ d'un projet, qui, oui, généralement démarre d'une seule personne et d'une simple POC.

La facilité d'apprentissage d'un langage n'a aucun rapport avec le fait d'utiliser ou non des classes. Le système de classes est bien plus logique et compréhensible pour un débutant que le prototypage car il est encré dans le réel : une classe représente généralement un concept de la vie courante avec des propriétés et actions possibles.

Mais bien-sûr, c'est sans doute pour cela que les débutants ont autant de mal à passer le cap d'un apprentissage des bases du langages, vers le modèle orienté objet.

Je n'ai lu cela nulle part ...

Comme dit précédemment, tu ne lis que ce que tu veux bien... il te suffit de chercher, à tout hasard, après la page Wikipedia, sur le JavaScript, ou plein d'autres sources.

Le langage a été créé en dix jours en mai 1995 pour le compte de la Netscape Communications Corporation par Brendan Eich, qui s'est inspiré de nombreux langages, notamment de Java mais en simplifiant la syntaxe pour les débutants.

Brendan Eich a initialement développé un langage de script côté serveur, appelé LiveScript, pour renforcer l'offre commerciale de serveur HTTP de Mosaic Communications Corporation. La sortie de LiveScript intervient à l'époque où le NCSA force Mosaic Communications Corporation à changer de nom pour devenir Netscape Communications Corporation.

Netscape travaille alors au développement d'une version orientée client de LiveScript. Quelques jours avant sa sortie, Netscape change le nom de LiveScript pour JavaScript. Sun Microsystems et Netscape étaient partenaires, et la machine virtuelle Java de plus en plus populaire. Ce changement de nom servait les intérêts des deux sociétés.

Comme tout au long de ce fil, tu ne fais qu'illustrer ta mauvaise foi, ton ignorance, ton arrogance, ton manque d'expérience, ...

Petite indication, juste en passant, une des premières choses à savoir faire, quand on est développeur, c'est rechercher l'information.

[Sodium]

Tu ne lis que ce qui t'arrange, toi... j'ai pourtant bien précisé l'impulsion de départ d'un projet, qui, oui, généralement démarre d'une seule personne et d'une simple POC.

Sauf que cette "impulsion de départ" a bien constitué la première release du langage et en a posé les racines qui empoisonnent encore aujourd'hui son utilisation, car une fois que l'on a commencé à utiliser une techno et que des développeurs l'utilisent, il devient très compliqué d'y apporter des changements majeurs.

Mais bien-sûr, c'est sans doute pour cela que les débutants ont autant de mal à passer le cap d'un apprentissage des bases du langages, vers le modèle orienté objet.

Tu confonds l'utilisation d'objets et la conception orientée objet. L'utilisation d'objets est enfantine car elle se rapproche de la vision du monde réelle : une voiture est un objet qui des propriétés (marque, couleur, vitesse...) et qui peut exécuter des actions (accélérer, tourner...). Et les classes sont un moyens très simple et intuitifs de créer des objets, contrairement au prototypage ou pire, par fonctions : JavaScript avait le don d'avoir deux manières de créer des objets, une sale et peu intuitive et une très sale et totalement fantaisiste. Sans même parler de ses nombreuses incohérences qui sont toujours en place aujourd'hui :

Code :

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

1
2
3
4
5
6
 
typeof("test");
string
 
typeof(new String("test"));
object

Une vraie conception objet est bien plus complexe à appréhender et c'est le cas aussi bien en JavaScript qu'en Java, en PHP ou encore en C++.

Comme dit précédemment, tu ne lis que ce que tu veux bien... il te suffit de chercher, à tout hasard, après la page Wikipedia, sur le JavaScript, ou plein d'autres sources.
Petite indication, juste en passant, une des premières choses à savoir faire, quand on est développeur, c'est rechercher l'information.

Alors déjà, quand on veut de l'information fiable sur Internet, on la cherche en anglais, les versions françaises n'étant généralement au mieux que des traductions approximatives.
Et voilà ce que dit la version anglaise de Wikipedia sur JavaScript :

Although it was developed under the name Mocha, the language was officially called LiveScript when it first shipped in beta releases of Netscape Navigator 2.0 in September 1995, but it was renamed JavaScript[2] when it was deployed in the Netscape Navigator 2.0 beta 3 in December.[13] The final choice of name caused confusion, giving the impression that the language was a spin-off of the Java programming language, and the choice has been characterized[14] as a marketing ploy by Netscape to give JavaScript the cachet of what was then the hot new Web programming language.

[Invité]

On parle d’une technologie récente et en cours de développement si je me trompe pas, donc bosser sur du bêta je pense pas que ça soit génial pour le moment mais j’espère que d’ici 2020 on pourra vraiment faire des sites avec.

Et après webassembly peut être compilé depuis n’importe quel langage si tu veux rester sur js tu pourras sûrement, mon but étant de faire du C# de mon côté et MS bosse actuellement sur Blazor qui semble être un bon projet.
L’intérêt de cette technologie sera quand même de contenter un maximum de dev et d’avoir quelques chose de bien performant par rapport a du js interprété classique.

Je ne sais pas sur quoi tu as bossé dessus c’est assez vague au final ta critique pour un truc en bêta en plus.

Oui, alors que quand tu dis que le salut est dans webassembly, c'est une vérité démontrée par A+B.

Webassembly est dispo dans les navigateurs depuis quasiment deux ans et emscripten existe depuis le début de l'asmjs, il y a plus de 5 ans. Donc non, ce n'est pas de la beta. En C ou C++, Webassembly est assez contraignant à utiliser car chaque lib que tu veux utiliser doit être portée et ça peut être très compliqué. Enfin, les performances ne sont pas du tout exceptionnelles : tu peux t'estimer heureux si tu es "seulement" deux fois plus lent que le code natif.
Bref, avoir un OS dans le navigateur en plus lent et plus contraignant c'est peut-être le salut pour toi mais pour moi non.

[Invité]

Sans rentrer en profondeur dans le débat, je trouve quand même un peu domage de cracher sur un langage et de chercher à déformer la réalité et à contre-argumenter à outrance pour soutenir une thèse. C'est juste la définition de la mauvaise foi.
Que tu n'aimes pas JS, c'est ton droit. Il y a probablement des raisons compréhensibles qui font que tu ne l'aimes pas et je crois que beaucoup seraient prêt à les entendre ici, voire même à être d'accord sur certains points.

Maintenant, que tu te permettes de dire que c'est un langage "pourri" et que son utilisation ne peut être que problématique et mauvaise... Quelle autre crédibilité que ta faible expérience peux-tu proposer pour soutenir ton postulat? (je ne dis pas faible expérience de façon péjorative, mais parce que c'est la vérité. Tu n'es pas chercheur depuis plusieurs décennies, tu n'as pas contribué à la création de langages, tu n'es vraisemblablement pas investi dans des domaines de ce genre, etc.). À quel moment as-tu le sentiment d'être assez crédible pour dire: "tel langage est nul"? Tu peux éventuellement dire que tu ne comprends pas les choix qui se cachent derrière, que tu n'apprécies pas son utilisation, ...
Enfin bref, tu te lances dans un combat débile et même les personnes qui ne sont pas fan de JS (dont je fais partie) n'ont pas envie de te soutenir. Je trouve personnellement qu'on voie beaucoup de codes écrits en Javascript qui sont de mauvaise qualité. Mais lorsqu'il est bien utilisé, c'est un langage qui a une syntaxe claire et qui peut avoir de très très bon côté (et si tu utilises Angular, même avec un "surcouche" Typescript, c'est que tu as conscience d'une part de ces bons côtés). J'ai un ami qui participe régulièrement à des missions de recherche pour des groupes industriels. Il arrive très souvent à faire adopter JS et à faire du travail de qualité avec. Et je considère qu'il a une grande légitimité puisqu'il est Docteur en Génie Informatique et est souvent reconnu pour son travail.

Pour finir, je pense qu'il faut aussi dire qu'un langage est surtout le résultat de ce que le programmeur en fait. En ce moment, je ne travaille qu'avec C et C++. Qui pourrait oser dire que ces langages sont mauvais? Pourtant, je te jure que j'ai vu des choses bien plus ahurissantes dans ces deux langages qu'en JS. Et pour PHP c'est un peu pareil. Le langage s'est beaucoup amélioré et sa version actuelle est de grande qualité. Pourtant, il y a quelques années, on voyait du grand n'importe quoi. C'est toujours pareil, un langage n'est que rarement mauvais. Son utilisation en revanche...

[Sodium]

À quel moment as-tu le sentiment d'être assez crédible pour dire: "tel langage est nul"? Tu peux éventuellement dire que tu ne comprends pas les choix qui se cachent derrière, que tu n'apprécies pas son utilisation, ...

Le fait que tous les développeurs expérimentés que je connaisse personnellement détestent JavaScript est une première piste solide
Ensuite il n'y a pas tellement à discuter, un langage qui en 2018 ne permet pas de faire du typage statique (je ne parle même pas de le rendre obligatoire mais le proposer) n'est pas un bon langage et je ne vois pas comment l'on peut prétendre le contraire, sauf encore une fois en manquant de compétence.
Et on ne fait là que gratter la croûte des défauts de JavaScript...

Et pour PHP c'est un peu pareil. Le langage s'est beaucoup amélioré et sa version actuelle est de grande qualité. Pourtant, il y a quelques années, on voyait du grand n'importe quoi. C'est toujours pareil, un langage n'est que rarement mauvais. Son utilisation en revanche...

PHP est un langage parfaitement fréquentable depuis près de 5 ans. Il avait en effet de gros défauts, mais il a su évoluer contrairement à JavaScript qui patauge toujours. Sans doute parce que PHP est utilisé par plus de professionnels qui ont incité ces évolutions.