L'open bar à smoothies

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

Je sais bien que ce ne sont pas des classes comme je les connais. Du coup, je me suis dis que TypeScript serait bien. Et puis je voulais utiliser les toutes dernières nouveautés ES6 et ES7.

Mais bon, c’est parfois dans la douleur qu’on apprend le plus.

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.

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 !

Sucre syntaxique. Cette expression me replonge dans mes cours de Haskell en école d’ingé. "Tout ça n’est que du sucre syntaxique" disait souvent mon prof. Toujours est-il que les notes en fin d’année ne souffraient pas de diabète.

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
}

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)

Souvenez-vous, humains. Il y a des priorités.

The uploader has not made this video available in your country.

Change de pays, non-humain.

Techniquement, ce serait à toi.

Whoah, firefox 57 est tellement rapide

Je ne sais plus, j’en suis à la version 59.  

Je ne sais pas, j’utilise la version ESR.

Je sais pas, j’attends la mise à jour des dépôts.

Je sais pas, je suis sur Chromium.

Je sais pas, j’utilise w3m.
_{Ou pas}.

Je ne sais pas, j’utilise IE (Qui dit mieux ?) :kappa:

Plus sérieusement, j’apprécie Vivaldi en ce moment. (Wait, je viens de dire "Plus sérieusement" dans l’open-bar à smoothies… )

Jamais utilisé 57. Je suis directement passé de Firefox 56 à Nightly 58.

Toujours été sous Safari. Ça fait ce que je lui demande.