L'open bar à smoothies

Qui a dit "Hors sujet" ?

a marqué ce sujet comme résolu.

La vérité c’est que je ne sais pas écrire du JavaScript propre. En ES5, faire une classe, je ne peux pas, je ne sais pas faire. Donc pourquoi ne pas utiliser TypeScript ? Ça ne reste qu’une simple surcouche à JavaScript.

Nan je râle surtout sur la complexité du truc et les trouzillions d’outils, pas vraiment sur JS lui-même (quoique).

La vérité c’est que je ne sais pas écrire du JavaScript propre. En ES5, faire une classe, je ne peux pas, je ne sais pas faire. Donc pourquoi ne pas utiliser TypeScript ? Ça ne reste qu’une simple surcouche à JavaScript.

Nan je râle surtout sur la complexité du truc et les trouzillions d’outils, pas vraiment sur JS lui-même (quoique).

informaticienzero

Ouais c’est quand même un autre langage, tu dois le compiler vers JavaScript. Ça implique pas mal de décisions pas évidentes, du genre : "vers quelle version de JS veux-tu compiler ? Pour quel runtime ? Faut-il faire un gros bundle ou des fichiers ? Faut-il un polyfill pour telle ou telle feature ?".

Du coup ouais, tu râles en réalité contre TypeScript. :)

(La POO en JS est class-less, y’a bien un mot-clé class, ce qui est une connerie, mais ça permet pas du tout de créer de classes comme ce serait en Java/PHP/Ruby/Python/C# etc. Evite de les utiliser si tu vois pas bien la différence entre un prototype et une classe, t’auras un tas d’ennuis par la suite dans le cas contraire. C’est un genre de faux-ami, si tu pars du principe que class en JS permet de définir un truc comme class dans un langage OO class-based, ça va péter. ;) )

+0 -0

(La POO en JS est class-less, y’a bien un mot-clé class, ce qui est une connerie, mais ça permet pas du tout de créer de classes comme ce serait en Java/PHP/Ruby/Python/C# etc. Evite de les utiliser si tu vois pas bien la différence entre un prototype et une classe, t’auras un tas d’ennuis par la suite dans le cas contraire. C’est un genre de faux-ami, si tu pars du principe que class en JS permet de définir un truc comme class dans un langage OO class-based, ça va péter. ;) )

victor

C’est donc du sucre syntaxique qui n’apporte pas grand-chose de nouveau si j’ai bien compris ? Mais dans ce cas pourquoi ne pas l’utiliser ? C’est un peu le comble pour un tel langage dont il est question de rattraper certaines erreurs et de standardiser son utilisation, non ? Pardonne-moi si je me trompe, tu sais que je m’aventure sur un terrain glissant dont je n’en vois pas du tout le bout. ;)

C’est du sucre syntaxique, il apporte pas de nouveauté mais rend la définition d’un prototype nettement plus aisée.

Avant/après:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
-function Animal (name) {
​-  this.name = name;
-}-Animal.prototype.speak = function () {
-  console.log(this.name + ' makes a noise.');
-}

+class Animal { 
+  constructor(name) {
+    this.name = name;
+  }
+  
+  speak() {
+    console.log(this.name + ' makes a noise.');
+  }
+}

J’ai pas dit de pas utiliser class, j’ai dit que pour moi c’était une bêtise d’avoir choisi ce mot-clé. Mais je suis conscient qu’il n’y avait pas un grand choix de mots réservés à disposition pour ce sucre. Typiquement, utiliser prototype aurait cassé la compatibilité.

Mon principal argument c’est qu’utiliser class sans avoir bien compris en quoi ça diffère du concept de classe qu’on trouve dans l’OO class-based, c’est à dire dans presque tous les langages OO, c’est dangereux parce que c’est trompeur.

il est question de rattraper certaines erreurs et de standardiser son utilisation, non ?

C’est pas le but.

  • Le but c’est de rester 100% retro-compatible. Tu peux pas corriger les erreurs d’une précédente version sans casser la compatibilité.
  • Pas sûr de ce que tu veux dire par "standardiser son utilisation". Le langage lui-même est standardisé depuis plus de 20 ans.
+0 -0

Pas sûr de ce que tu veux dire par "standardiser son utilisation". Le langage lui-même est standardisé depuis plus de 20 ans.

Faire en sorte que le même code fonctionne sur tous les navigateurs, entre autre. Ce qui n’était pas le cas il y a 10 ans, mais cela a peut-être changé depuis.

OK, alors là c’est de la responsabilité des browsers pas de la spec du langage. Mais sinon oui, ça s’améliore, les navigateurs ont environ décidé de respecter la spec en implémentant leurs moteurs js respectifs.

Par contre là on est hs dans le sujet hs. Fin du hs !

+0 -0

Puisqu’on parle de sucre syntaxique, j’ai découvert récemment qu’en JavaScript, une fonction flêchée n’était pas tout à fait identique à son équivalent plus « classique », comme l’illustre le code ci-dessous. J’ai jamais compris pourquoi cette différence…

1
2
3
4
5
6
7
8
9
function SomePrototype() {}

SomePrototype.prototype.this1 = function() {
    return this; // retourne l'objet SomePrototype
}

SomePrototype.prototype.this2 = () => {
    return this; // retourne l'objet window
}
+0 -0

Deuchnord :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
function Family (members = []) {
  this.id = uuid()
  this.members = members
}

Family.prototype.list = function () {
  this.members.forEach((member) => {
    // print member name and family ID
    console.log(member.name, this.id)
  })
}

Family.prototype.list = function () {
  const self = this
  this.members.forEach(function (member) {
    // print member name and family ID
    console.log(member.name, self.id)
  })
}

C’est hyper relou d’assigner this à un truc pour y avoir accès dans une closure.

(Personne te dira qu’une arrow function est du sucre syntaxique. La sémantique est bel et bien différente. Y’a pas que le this qui change ici. Regarde par exemple : const x = () => arguments)

+2 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte