Il est vrai que, JavaScript, et tout le petit monde qui l'entoure, peut être franchement un peu compliqué. Voyons ça de façon calme et sereine pour essayer d'y voir un peu plus clair dans une suite d'articles. First things first : comment et où s'exécute le langage JavaScript.

Gardez en tête que cet article a pour but de vulgariser le sujet pour le rendre compréhensible, ne soyez donc pas trop étonné de certains raccourcis !

✨ Cet article a été actualisé en Août 2020 pour suivre les évolutions du domaine.

🏭 Les moteurs

JavaScript étant principalement - mais pas seulement - utilisé dans les navigateurs web, nous allons commencer par s'attarder sur eux. La composition d'un navigateur peut se réduire très grossièrement à ça :

• Moteur de rendu
• Moteur JavaScript
• Interface graphique

Dans le cas des navigateurs, un "moteur" est un outil qui permet à ce dernier d'interpréter et utiliser un langage.

Le moteur de rendu du navigateur, lui, s'occupe d'afficher graphiquement une page web en comprenant les langages HTML et CSS. C'est donc au moteur JavaScript que revient la tâche d'exécuter ce dernier.

Voici une liste des principaux moteurs de rendus associés à leur moteur JavaScript, suivis des navigateurs dans lesquels ils sont utilisés :

• Trident / Chakra : (feu) Internet Explorer
• WebKit / Nitro : Safari
• Gecko / SpiderMonkey : Firefox
• Blink / V8 : Chromium, Google Chrome, Microsoft Edge, Opera, Brave, Vivaldi...

Chose notable dans l'histoire des navigateurs, Blink est un fork (dérivé) de Webkit. Les raisons derrière la création de ce dérivé restent plus ou moins floues, si ce n'est qu'au moins, Google a au moins le contrôle complet sur son moteur de rendu. Depuis, de nombreux navigateurs ont fini par oublier l'idée de développer eux-mêmes leur propre moteur, le dernier cas en date étant la nouvelle version de Microsoft Edge.

⚡ Gotta go fast

Le but du JavaScript a grandement évolué au cours du temps. Il est passé de langage léger servant à changer la structure d'une page HTML (on parlait alors de faire du "DHTML") à un langage utile pour la création d'applications web complexes, d'abord sur ordinateur puis sur des appareils mobiles.

Du coup, on a voulu demander beaucoup aux navigateurs... peut-être un peu trop même. Une course à la vitesse, et surtout à la stabilité, a alors commencée entre leurs moteurs JavaScript : chacun devait aller le plus vite possible pour montrer que l'on pouvait réaliser tous nos rêves les plus fous - mais dans leur navigateur associé, bien sûr.

Des "benchmarks" (outils de test et de mise à l'épreuve) ont été conçus pour quantifier la rapidité d'un moteur JavaScript sur un navigateur et une plateforme donnée. JetStream 2 et Speedometer 2.0 sont ceux d'Apple, Kraken est celui de Mozilla. Les premiers grands benchmarks de l'époque étaient par exemple SunSpider ou Octane.

Google a fait du moteur JavaScript V8 le fer de lance de son navigateur Chrome, en plus du support d'un bon nombre de fonctionnalités HTML5. C'est probablement une des raisons qui a poussé les concurrents à porter un peu plus d'attention au développement de leur moteur JavaScript à partir de ce moment.

Une fois la rapidité et la stabilité obtenue, il était temps de réfléchir aux futures fonctionnalités du langage. Tout en travaillant sur la spécification officielle de ces fonctionnalités dans le standard ECMAScript (on en parlera dans l'article suivant), elles sont déjà intégrées en avance dans les moteurs des navigateurs. (tout comme l'on intégrait HTML5 bien avant que son standard soit terminé)

🎁 La petite révolution Node.js

JavaScript est un langage connu par beaucoup de développeurs, sans compter que le moteur V8 est plutôt rapide. Et si l'on prenait V8 pour qu'il tourne tout seul en dehors d'un navigateur, tout en l'améliorant pour cet usage ?

C'est plus ou moins comme cela qu'est né Node.js, qui lança alors la grande mode du "JavaScript côté serveur". Même si l'exécution de JavaScript en dehors d'un navigateur était déjà possible depuis longtemps (avec Rhino de Mozilla par exemple), la rapidité et la conception spécifique de Node.js a très rapidement construit sa notoriété.

Concrètement, le moteur V8 de Chromium se transforme ainsi en une application que l'on installe et que l'on peut utiliser pour exécuter une application en JavaScript.

Mais ce n'est pas seulement ça. L'enjeu de Node.js est qu'il va vous permettre d'accéder à des choses inédites depuis votre code JavaScript par rapport à l'environnement d'un navigateur : appeler des fonctions du système d'exploitation, lire/écrire des fichiers, créer un serveur HTTP, appeler la ligne de commande...

L'autre enjeu est sa conception, dont tout le monde en a très vite senti l'intérêt dans un contexte de course aux performances pour le côté back-end des applications web : il est événementiel et non-bloquant.

• Événementiel car il écoute des événements générés par des éléments lorsqu'ils sont modifiés, puis il réagit en conséquence.
• Non-bloquant car il est asynchrone, c'est à dire que le traitement d'une requête HTTP ou bien la lecture d'un fichier ne va pas bloquer l'intégralité de l'application, et il pourra faire autre chose en même temps.

Bien évidemment, le code que vous écrirez pour Node.js pourra aussi être événementiel et/ou non-bloquant, et c'est même recommandé. Après, vous pourrez toujours coder en synchrone, selon les contraintes techniques ou si vous débutez avec le langage par exemple.

Alors maintenant, que peut-on faire avec ? Quelques exemples :

• Un site web de A à Z
• Un serveur WebSockets pour de la communication temps réel
• Un analyseur en temps réel de données ou de flux
• Un utilitaire avec des tâches d'automatisation
• Un exécuteur de tests unitaires
• Un outil destiné à la ligne de commande

🙃 Le meilleur des deux mondes... ?

Résumons : jusqu'ici, nous avons des moteurs JavaScript de plus en plus performants dans nos navigateurs. Le web est clairement une plateforme universelle, certes implémentée différemment un peu partout, mais bon. En plus de ça, on a créé un outil pour utiliser JavaScript hors du navigateur, Node.js.

Alors évidemment, il a bien fallu que ça arrive : on a eu l'idée de mixer Chromium et Node.js.

Pour rappel, Chromium est le projet open-source à la base du navigateur Google Chrome. En partant d'un Chromium qui servira uniquement à afficher des pages web stockées sur votre ordinateur, on lie son moteur JavaScript (c'est à dire V8) à celui de Node.js (basé sur V8).

Vous avez maintenant de quoi créer une application web pour Windows, Linux ou macOS, avec un accès à tout ce que permet de faire Node.js directement depuis le code JavaScript qui sera exécuté par le navigateur. La possibilité de mixer du JavaScript "côté client" avec du JavaScript "côté serveur", et donc au final, la possibilité de développer des applications web avec quasiment les mêmes fonctionnalités qu'une application de bureau traditionnelle.

Aujourd'hui, on trouve deux gros projets qui concrétisent cette idée : NW.js, appelé node-webkit à l'époque, et Electron, développé par GitHub.

L'éditeur Atom, développé par GitHub, a été dans le monde du développement un des plus grands projets utilisant Electron, en proposant quelque chose de bien plus facile à personnaliser que les IDE traditionnels car utilisant les technologies du web.

Chose un peu ironique, Microsoft a fini par créer son propre éditeur basé lui aussi sur Electron, nommé Visual Studio Code. Il a très vite affiché une extraordinaire fluidité et beaucoup plus de fonctionnalités poussées que son concurrent Atom, et aujourd'hui, Microsoft ayant racheté GitHub, on se doute qu'Atom finira par ne plus être activement développé.

🔜 Next time on the series...

Connaître comment et où s'exécute du Javascript n'était que le début. Le prochain article fait un petit historique du langage, ainsi que des langages qui se transpilent 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.