Nous avions déjà vu dans le précédent article comment s'exécutait JavaScript, mais ce ne serait pas amusant si tout était aussi simple ! C'est le moment d'étudier la ribambelle de langages qui ont été créés pour se transpiler - ce n'est pas une insulte - en JavaScript.
"Transpiler" signifie traduire un code d'un langage en un autre, alors que "compiler" s'applique plutôt dans le cas où l'on a un exécutable à la fin de l'opération.
✨ Cet article a été actualisé en Août 2020 pour suivre les évolutions du domaine.
📜 Un peu d'histoire
Netscape, partenaire de Sun à l'époque, intégra pour la première fois JavaScript dans son navigateur en 1996. Microsoft répliqua la même année par une implémentation nommé JScript au sein d'Internet Explorer 3.
D'abord appelé LiveScript, Sun a incité Netscape à renommer son langage en "JavaScript" afin de bénéficier de la notoriété de Java, tout en lui promettant de ne jamais l'attaquer pour l'utilisation du nom de leur langage. (encore heureux !)
Voulant éviter que les implémentations naissances des autres navigateurs soient trop différentes les unes des autres, Netscape soumet les principes de son langage à l'association de standardisation ECMA. Naquit alors le standard ECMAScript, c'est à dire une spécification officielle des grandes lignes de JavaScript pour tous ceux qui voudraient l'intégrer dans un navigateur (ou ailleurs).
C'est donc en fait les évolutions du standard ECMAScript qui font évoluer JavaScript au fil du temps, en le rendant plus complet et plus robuste... mais ce standard a mis énormément de temps à réellement évoluer.
ECMAScript 5 n'a été finalisé qu'en 2009, soit la première évolution depuis la 3ème édition sortie en... 1999. Entre temps, la 4ème édition a été abandonnée car elle voulait changer la nature même du langage, et son développement était trop fastidieux.
En 2015 sort le standard ECMAScript 6, la première grande évolution du langage avec une nouvelle syntaxe et des fonctionnalités permettant beaucoup plus facilement l'écriture (par exemple) d'applications web complexes. A partir de ce standard, aussi appelé ES6, on finira par dénommer les standard par leur année de conception : par exemple ECMAScript 2015 ou ES2015. Cela voulant donc dire que, désormais, il devrait sortir une nouvelle version du standard ECMAScript chaque année.
Aujourd'hui, grâce à la rapide évolution des moteurs JavaScript utilisés par la plupart des navigateurs, on peut considérer qu'au moins ECMAScript 2015 est supporté partout, alors qu'à l'époque il fallait encore considérer que le vieillissant ECMAScript 5 était la norme. Lorsque l'on veut utiliser un standard qui n'est par exemple pas encore finalisé, ou que l'on veut exécuter du code sur un navigateur ne supportant pas un standard précis, on peut utiliser un transpileur comme Babel.
🔀 Pourquoi transpiler ?
Voilà une bonne question pour aborder le sujet : pourquoi vouloir absolument éviter de coder directement en JavaScript ?
A l'époque d'ES5, il aurait été aisé de répondre que le langage était plein d'illogismes et qu'il manquait terriblement de fonctionnalités modernes... des arguments de moins en moins valides, non seulement depuis ES2015, mais encore plus à chaque nouveau standard annuel.
De par l'originale lenteur d'évolution de JavaScript, des langages alternatifs ont vite fini par apparaître. Leur particularité étant qu'on ne peut pas directement interpréter ou compiler ces langages pour les exécuter, car ils sont destinés à être transpilés (convertir un langage dans un autre) en JavaScript.
Ainsi, vous écrivez dans un langage différent, mais vous aurez toujours à la fin du JavaScript standard compréhensible par un navigateur ou autre. Un inconvénient étant que la vitesse d'exécution ou la taille du code peuvent être plus élevés que si l'on avait utilisé simplement JavaScript à la base.
Mais comment peut-on avoir un meilleur langage si au final ça reste du JavaScript ?
En proposant une syntaxe différente, des fonctionnalités de langage plus "orienté objet", des choses empruntées aux langages fonctionnels... au final, chacun fait un peu ce qu'il veut selon son but.
Il existe des dizaines de langages créés juste pour être transpilé en JavaScript, et il y a énormément d'outils tentant de transpiler en JavaScript des langages qui n'étaient pas conçus pour à la base. Regardez par vous-même. Nous n'allons voir que certains de ces projets, selon leur notoriété ou leur apport à l'histoire.
☕ CoffeeScript
Créé fin 2009, le but de CoffeeScript était surtout d'être plus lisible et moins verbeux que le JavaScript, avec une syntaxe très simplifiée, tout en ajoutant quelques fonctionnalités et raccourcis jamais vus auparavant dans JavaScript.
Partons sur un exemple de code commun aux langages de cet article : une classe "Hello" dont le constructeur accepte un paramètre "name", qui possède une valeur par défaut. On crée ensuite une instance de cette classe avec un autre nom en paramètre afin d'afficher un message dans la console.
class Hello
constructor: (name = "world") ->
console.log "Hello #{name} !"
new Hello "Joseph Joestar"
Comme vous pouvez le voir, la syntaxe est plus qu'épurée ! Les parenthèses sont omises, on utilise une flèche (->) pour définir une fonction, l'indentation remplace l'usage des accolades (comme en Python ou Ruby)...
Personnellement, et c'est un des principaux arguments utilisés en défaveur du langage, je trouve la syntaxe limite trop épurée et surtout exotique. Cependant, CoffeeScript a eu une influence sur l'évolution de JavaScript (de l'aveu de son créateur Brendan Eich), a réussi à l'époque à rallier beaucoup de développeurs web vu la popularité de l'usage du langage sur GitHub, et il reste activement en développement bien qu'il soit largement moins populaire aujourd'hui. Cet article explique bien l'histoire du langage et son prévisible destin.
🎯 Dart
Dart est donc créé par Google en 2011. Conçu à la base pour être un remplaçant de JavaScript, allant même jusqu'à vouloir supporter le langage directement dans Google Chrome, il apporte surtout bon nombre de fonctionnalités très intéressantes pour l'époque : la définition de classes, l'import de modules, des paramètres nommés pour l'appel de fonctions, et même un système de typage optionnel.
class Hello {
Hello({String name: "world"}) {
print("Hello $name !");
}
}
void main() {
new Hello(name: "Joseph Joestar");
}
Ici, notre exemple de code est le même, si ce n'est que le paramètre "name" est un paramètre nommé (ça parlera aux connaisseurs de Ruby ou Python). C'est à dire que lors de l'appel d'une fonction, on peut écrire le nom du paramètre que l'on passe, et l'ordre des arguments n'a alors plus grande importance (à peu près - je ne vous explique ici que très rapidement le principe).
Pour ce qui est du typage, il ne sera utilisé que par le compilateur qui vous préviendra alors d'éventuelles erreurs : si par exemple vous donnez manifestement une chaîne de caractères à une fonction qui attends un nombre, etc. Ça permet d'éviter des erreurs "bêtes" lors de l'exécution du code dans le navigateur.
L'objectif du langage et son accueil par les développeurs a beaucoup évolué au fil du temps. Google a abandonné l'idée d'en faire un remplaçant de JavaScript, allant jusqu'à préférer l'usage de TypeScript pour les récentes versions de leur framework Angular. Depuis, il est possible de compiler nativement le langage pour ordinateur ou iOS/Android, et il est aujourd'hui principalement utilisé par le framework Flutter (de Google également) qui sert à développer rapidement des applications natives Android ou iOS.
💪 TypeScript
C'est en 2012 que Microsoft révéla ce projet qui en étonna plus d'un : TypeScript, un sur-ensemble de JavaScript, c'est à dire que n'importe quel code JavaScript sera considéré comme du code TypeScript valide. Le langage rajoute des fonctionnalités et de la syntaxe par-dessus JavaScript, et vous pouvez donc d'abord prendre un code JavaScript existant pour utiliser petit à petit les fonctionnalités de TypeScript de votre choix. Aussi, le but pour Microsoft reste d'être le plus proche possible de chaque standard ECMAScript, pour ne pas avoir un langage trop différent fondamentalement.
Notons que son co-créateur n'est autre que l'actuel architecte en chef du langage C#, ce qui explique le "feeling C#" que l'on sent dans ce langage (ce qui n'est pas un défaut si vous avez déjà fait du C# et que vous aimez son écriture).
class Hello {
constructor(name: string = "world") {
console.log("Hello ${name} !");
}
}
new Hello("Joseph Joestar");
Encore le même exemple de code, mais sans les paramètres nommés. On peut cependant réussir à faire la même chose en TypeScript avec du "destructuring" de paramètres, mais on va éviter de vous rendre confus pour le moment.
Le typage est évidemment optionnel, mais concrètement, c'est quand même un peu la raison d'être du langage. Tout comme Dart, le compilateur vous avertit d'éventuelles erreurs à la compilation. Vous avez donc tout intérêt à utiliser au maximum le typage pour avoir un code propre.
Depuis sa création, TypeScript a su s'attirer une grande communauté et une popularité incontestable. Nombreux sont ceux qui, voulant juste faire du JavaScript avec du typage, choisissent ce langage pour avoir l'assurance d'un code plus robuste.
🤔 JavaScript, ou autre chose ?
Tous ces langages, c'est bien mignon, mais faut-il absolument les utiliser ? Pas forcément.
Ce n'est pas évident lorsque vous partagez votre code dans un langage qui n'est pas très connu, lorsque votre code ne se transpile plus correctement à cause des rapides évolutions du langage choisi, lorsqu'il faut installer plein d'outils avant de pouvoir commencer à travailler, lorsqu'il faut faire plus d'efforts pour utiliser avec succès un framework JavaScript... On pourrait continuer longtemps comme ça, mais ces problématiques s'appliquent tout autant aux autres langages qui se transpilent en CSS ou en HTML.
Malgré tout ça, il y a encore aujourd'hui de réels avantages à utiliser ces langages alternatifs. L'essentiel est de savoir pourquoi on utilise tel ou tel langage, et il faut surtout choisir celui le plus adapté à son projet et/ou à son contexte. Un choix qui n'est pas souvent aisé, surtout qu'il important de rationaliser les effets de mode qui nous font perdre un peu notre esprit critique, chose courante dans le développement web.
🔜 Next time on the series...
On commence à bien connaître le JavaScript, où il s'exécute et quelles sont ses alternatives. Heureusement pour nous, il nous reste encore plein de choses à voir, avec un prochain article qui parle des librairies bibliothèques JavaScript.
