JavaScript's Bizarre Adventure - Part 1 : les moteurs

JavaScript

JavaScript et tout son petit monde qui l'entoure, c'est vrai que c'est 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 choqué (et déçu) de certains raccourcis :)

"Vroom vroom" fait le moteur

InoriAizawa

Inori Aizawa, personnification officielle d'Internet Explorer

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

  • Moteur de rendu
  • Moteur JavaScript
  • Interface graphique

L'interface graphique étant optionnelle dans le cas où vous intégrez un navigateur dans une autre application, par exemple.

C'est à dire, un moteur ?

Certains langages ne peuvent s'exécuter tous seuls et ont besoin d'un interprète pour ce faire. Dans le cas des navigateurs, un "moteur" est une application qui permet à ce dernier d'utiliser un langage.

Le moteur de rendu du navigateur, lui, s'occupe d'afficher 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 pour votre culture une liste des principaux navigateurs suivis de leur moteur de rendu / moteur JavaScript :

  • Internet Explorer : Trident / Chakra
  • Safari : Webkit / Nitro
  • Firefox : Gecko / SpiderMonkey
  • Chromium & Chrome : Blink / V8

M'enfin, Chrome n'est pas basé sur Webkit ?

Il l'était. Son moteur de rendu, Blink, est en effet 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 le contrôle complet sur son moteur de rendu. (Webkit étant un projet d'Apple, voyez...)

Gotta go fast !

Sonic

"De toute façon, c'est moi le plus rapide !" - Tous les navigateurs, tout le temps

L'usage 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 "DHTML") à un langage utile à 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. Une course à la vitesse et à 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, bien sûr.

Des outils de test et de mise à l'épreuve, des "benchmarks", ont été conçus pour quantifier la rapidité d'un moteur JavaScript sur un navigateur et une plateforme donnée. SunSpider est celui d'Apple, Kraken celui de Mozilla, et Octane celui de Google.

Chrome

La réduction de la consommation mémoire n'est malheureusement pas une priorité...

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.

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 dernières dans le standard ECMAScript (on en parlera dans l'article suivant), elles sont déjà petit à petit intégrées aux moteurs des navigateurs. (tout comme l'on intégrait HTML5 bien avant que son standard soit terminé)

Node.js ramène sa fraise

Dio

S'il fallait résumer l'arrivée de Node.js en un gif

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 ?

C'est plus ou moins comme ça 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 fait 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 un fichier 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, utiliser la ligne de commande...

L'autre enjeu est sa conception, qui fait également tout son intérêt : 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, et 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 son fonctionnement, 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 pouvez toujours coder en synchrone, mais c'est un aveu de flemmardise si je puis me permettre.

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

Mindblown

Votre réaction après la lecture de ce qui va suivre

Résumons. Nous avons des moteurs JavaScript de plus en plus performants dans nos navigateurs, qui eux-mêmes sont de mieux en mieux. 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éé une application pour utiliser JavaScript hors du navigateur de façon efficace et pas chère, c'est Node.js que je préfère.

Alors oui, évidemment, on l'a fait. On a eu l'idée de mixer Chromium et Node.js.

...Plaît-il ?

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

Vous avez maintenant de quoi créer une application web pour Windows, Linux ou OS X, avec un accès à tout ce que permet de faire Node.js directement depuis le code JavaScript qui sera exécuté par le navigateur.

Donc c'est du JavaScript côté serveur exécuté côté client ?

Mmmmh on peut dire ça comme ça, oui.

Aujourd'hui, on trouve deux gros projets qui concrétisent cette idée : NW.js et Electron, ce dernier étant développé par GitHub.

Il est alors très simple de saisir l'enjeu de ces projets : la possibilité de développer des applications web avec quasiment les mêmes fonctionnalités qu'une application de bureau traditionnelle.

Atom

Une application de bureau tout en JavaScript ! (Bon d'accord, Atom n'est pas un exemple de rapidité)

Un exemple : l'éditeur Atom créé par GitHub (qui utilise, vous l'aurez deviné, Electron) est présenté comme une alternative open-source à Sublime Text et autres, tout en étant facilement bidouillable vu qu'il est basé sur les technologies du web.

Next time on the series...

Connaître comment et où s'exécute du Javascript, ce n'était que le début. La prochaine fois, on fera un petit historique du langage et un tour des langages qui se transpilent en JavaScript : lire l'article

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

ToBeContinued