JavaScript's Bizarre Adventure - Part 2 : les langages

JavaScript

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.


Un peu d'histoire

Logo Netscape

Le témoin de chargement d'une page dans Netscape Navigator. Good old times.

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, Netscape soumet les principes de son langage à l'association de standardisation ECMA afin d'en créer un standard. Naquit alors le standard ECMAScript, une spécification officielle des grandes lignes de JavaScript.

C'est donc les évolutions du standard ECMAScript qui font évoluer JavaScript au fil du temps, en le rendant plus complet et plus robuste. Aujourd'hui, la plupart des moteurs JavaScript des navigateurs modernes intègrent sa version 5, aussi appelée ES5. (Oubliez donc Internet Explorer 8 et inférieur)

Pourquoi ?

ConfusedTravolta

C'est l'étonnement.

Voilà une bonne question pour aborder le sujet : pourquoi vouloir absolument éviter de coder directement en JavaScript ?

Il serait facile d'y répondre comme cela : "c'est mal foutu, illogique par moments, et ça manque terriblement de fonctionnalités modernes". Et malgré la facilité de cette réponse, on ne peut pas dire qu'elle soit si fausse.

Le principal problème du langage selon moi, c'est qu'il a surtout été très long à évoluer. ECMAScript 5 n'a été finalisé qu'en 2009, soit la première évolution depuis la 3ème édition sortie en... 1999. (la 4ème édition ayant été abandonnée, voulant changer la nature même du langage et son développement ayant été trop fastidieux)

Du coup, des langages alternatifs ont fini par apparaître. Leur particularité étant qu'on ne peut pas directement interpréter ou compiler ces langages pour les exécuter, ils sont destinés à être transpilés en JavaScript. Ainsi, vous écrivez dans un langage différent, mais vous aurez toujours à la fin du JavaScript standard ! Conséquence logique, utiliser un langage alternatif ne veut pas dire que notre code sera plus rapide à l'exécution.

Mais comment peut-on avoir un meilleur langage si au final ça reste du JavaScript ?

Une syntaxe différente, des fonctionnalités plus "orienté objet", des choses empruntées aux langages fonctionnels... chacun fait un peu ce qu'il veut selon son but.

Mais alors, combien existe-il de langages transpilables en JavaScript ? Littéralement plus d'une centaine. Regardez par vous-même. Nous n'allons donc n'en voir que certains, ceux qui ont une certaine notoriété et/ou communauté derrière eux.

CoffeeScript

Café

Voyons voir ça... *sirote un Caramel Macchiato glacé*

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 des fonctionnalités et raccourcis jamais vus auparavant en 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 "Hello Joseph Joestar !" 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 et les accolades sont omises, on utilise une flèche (->) pour définir une fonction... Il faut assurément une connaissance parfaite du langage pour pouvoir le comprendre et l'utiliser.

Le site officiel propose un grand nombre d'exemples de code en CoffeeScript ainsi que leur équivalent en JavaScript.

Personnellement, et ça doit aussi s'appliquer à d'autres, la syntaxe trop épurée et exotique me rebute. J'ai plus l'impression de perdre en visibilité qu'autre chose, et ce malgré les raccourcis apportés par CoffeeScript. Mais il existe justement d'autres langages avec une écriture plus "classique"...

Dart

Dart

Google, croyant avoir inventé le langage ultime pour le web.

Dart est donc créé par Google en 2011. Il apporte surtout bon nombre de fonctionnalités très intéressantes : la définition de classes, l'import de modules, des paramètres nommés pour l'appel de fonctions et même un 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).

Plutôt compréhensible comme langage, non ? D'autres exemples sont sur le site web de Dart. 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 un String à 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.

Malgré ça, j'ai l'impression que Dart n'a pas la notoriété qu'il mérite. Il reste d'une importance capitale pour Google, et bénéficie d'une certaine maturité dans sa syntaxe et ses outils. Aussi, il y a des projets expérimentaux pour utiliser Dart sur des micro-contrôleurs (Arduino...) et pour faire des applications natives Android / iOS, à suivre de près donc.

Google a même fait une version spéciale d'AngularJS pour Dart par exemple, même si JavaScript reste le langage de "premier choix" pour ce dernier. Et pour Angular 2 justement, Google a voulu utiliser un autre langage de "premier choix". Ils ont donc tout naturellement choisi TypeScript... (même si JavaScript et Dart sont également officiellement supportés)

TypeScript

TypeScript

La découverte de ce langage peut vous électriser.

C'est en 2012 que Microsoft révéla ce projet qui en étonna plus d'un. Un sur-ensemble de JavaScript, c'est à dire que n'importe quel code JavaScript sera considéré comme du code TypeScript valide. Le langage ne fait "que" rajouter des fonctionnalités et de la syntaxe par-dessus JavaScript, vous n'avez donc pas à réapprendre les bases. Une bonne chose.

Notons que son co-créateur n'est autre que l'inventeur principal du 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, mais sans les paramètres nommés. On peut 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.

Toute la documentation et quelques exemples sont sur le site officiel de TypeScript. Le typage est également 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. Vous avez donc tout intérêt à utiliser au maximum le typage pour avoir un code propre et éviter des erreurs idiotes.

Microsoft oblige, Visual Studio et Visual Studio Code supportent déjà le langage avec une gestion de la compilation et de l’auto-complétion, mais on aussi peut retrouver les mêmes facilités de développement dans Sublime Text ou Atom par exemple.

TypeScript a déjà gagné une bonne popularité et une communauté de taille raisonnable, il n'y a d'ailleurs pas un jour sans voir un article qui chante ses louages. Et avec la future sortie d'Angular 2 qui a choisi TypeScript comme langage de référence, vous pouvez être sur que sa popularité va exploser !

Et voulant bien faire les choses, Microsoft a annoncé dès le début que le but du langage serait également de respecter le plus possible les standards ECMAScript 2015 (auparavant appelé ES6) et ES7. C'est probablement pour cela que Dart n'a pas été choisi par défaut pour Angular 2, afin de ne pas trop dépayser les développeurs JavaScript, même s'il reste un langage officiellement supporté pour Angular 2.

ES2015

ES2015

La réaction de tout développeur web sain face aux nouveautés de ES2015

Une nouvelle version d'ECMAScript ? Et oui ! Non négligeable, cette édition apporte un nombre incroyable de fonctionnalités puissantes et surtout "dans l'air du temps".

Une liste non-exhaustive de ces nouveautés :

  • Classes et modules
  • Définition de variables avec le mot clé "let"
  • "Fat arrow" (=>) pour l'écriture de fonctions
  • Syntaxe simplifiée pour l'écriture d'objets
  • Chaînes de caractères multi-lignes
  • Valeur par défaut pour les arguments
  • Itérateur "for (var n of list)"
  • Promesses et générateurs
  • Structures de données "Set" et "Map"

Et bien d'autres. Le langage a fait un énorme bond en avant et il va falloir apprendre tout ça (youpi). C'est quand même plutôt cool, parce que tous ces ajouts rendent réellement JavaScript plus pratique à utiliser et surtout bien plus plaisant pour développer avec.

Par contre, étant donné sa jeunesse, les navigateurs et autres moteurs JavaScript n'ont pas encore implémenté l'intégralité des fonctionnalités du standard. Il faudra alors vérifier leur support au cas par cas, ou bien utiliser un transpileur (Babel, Traceur...) qui transforme du code ES2015 en ECMAScript 5 afin d'utiliser certaines de ses fonctionnalités dès aujourd'hui.

JavaScript ou autre chose ?

Both

Pourquoi pas les deux ?

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 et que d'autres développeurs ne connaissent pas votre langage, lorsque votre code ne se transpile plus car le langage évolue encore très souvent, quand il faut installer plein d'outils avant de pouvoir commencer à travailler... Et on peut continuer longtemps comme ça. D'ailleurs, tout ça s'applique aussi aux autres langages qui se transpilent en CSS ou en HTML.

Ces langages alternatifs ont surtout vu le jour suite à l'absence d'évolution d'ECMAScript, chose désormais révolue. Mais son implémentation parfaite dans tous les navigateurs restera une chose lente et surtout complexe.

Je pense qu'il y a donc toujours un véritable intérêt à utiliser des langages alternatifs qui se transpilent en ECMAScript 5 et ce malgré l'arrivée récente d'ECMAScript 6, mais rien ne vous empêche d'utiliser également ECMAScript 6 si vous préférez son aspect standardisé et "officiel".

L'essentiel est de savoir pourquoi on utilise tel ou tel langage, et surtout de choisir celui le plus adapté à son projet et/ou à son contexte. Un choix pas très facile certes, surtout qu'il important de rationaliser les effets de mode qui nous font perdre un peu notre esprit critique.

Dans le FUTUR

Futur

Le développement web c'est trop swag pour toi maintenant (enfin, un peu)

Rassurez-vous, nous n'attendons pas encore 10 ans avant de voir la prochaine version d'ECMAScript. L'édition 7 du standard est déjà en cours de rédaction, et certains moteurs JS proposent quelques implémentations expérimentales, mais on n'en est vraiment qu'aux premiers balbutiements.

ECMA a tout de même annoncé que les évolutions du standard seraient plus rapprochées à l'avenir, histoire de continuer dans la lancée initiée par l'édition 2015, et c'est plutôt une bonne nouvelle.

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 reste encore plein de choses à voir, et la prochaine fois on parlera des librairies bibliothèques : lire l'article

ToBeContinued