Google NaCl : Du code natif dans le navigateur

Alors que Chrome OS déplace le débat au sein du navigateur, ce choix technologique ne va pas sans inconvénients : le code exécutable au sein d'un navigateur est autrement plus lent que du code natif. Un détail qui est d'autant plus gênant que Chrome OS se destine avant tout aux netbooks, qui sont déjà très limités en puissance. Pour y remédier, Google a mis au point une technologie qui semble toute indiquée pour son système d'exploitation.

Commençons par expliquer le pourquoi du comment : les applications exécutables contiennent du code binaire qui s'adresse tant au processeur qu'aux API (Application Programming Interface) du système d'exploitation. En tant que telles, les applications se destinent donc à un couple CPU/OS spécifique et ne peuvent être utilisées sur d'autres plateformes telle quelles. Le langage machine est spécifique à chaque processeur, et il est fastidieux d'apprendre ce langage à chaque fois qu'on programme pour un processeur différent, sans oublier qu'il est assez abscons et difficile d'accès. Afin de rendre la programmation plus accessible, on utilise un langage universel tel que le C, qui est converti dans le langage spécifique à la machine par un compilateur.

Le web se destinant à une multitude de postes clients, il a donc fallu trouver d'autres moyens pour exécuter des instructions, afin que ces opérations soient universelles. Ainsi, toutes les technologies qui exécutent du code côté client (JavaScript, Flash, Shockwave, Java…) sont basées sur une couche d'abstraction matérielle, par le biais d'un langage intermédiaire qui n'est pas compilé mais interprété. Un "interpréteur" spécifique à chaque machine se charge de traduire ce langage universel dans un langage compréhensible par la machine concernée, ce qui se fait au prix d'une exécution bien moins véloce. Par conséquent, toutes les fonctions "lourdes", comme par exemple le décodage d'une vidéo, sont transférées à l'intérieur des interpéteurs, ne laissant aux développeurs que la latitude d'y faire appel sans pouvoir les modifier ou créer leurs propres fonctionnalités évoluées.

L'autre inconvénient de cette approche, c'est que les fonctions en question ne seront disponibles que sur les plateformes qui disposent de l'interpréteur idoine. Il est ainsi impossible de lire les contenus en Shockwave sur une machine tournant sous Linux (à moins de passer par un intermédiaire supplémentaire tel que Wine). C'est notamment pour remédier à ce problème qu'on a intégré nombre de fonctions équivalentes dans le standards HTML 5. L'interpréteur n'est cette fois plus dans un plugin, mais intégré directement dans le navigateur.

La question de la fluidité d'exécution est devenue d'autant plus cruciale avec la multiplication des "web apps" et du "cloud computing" : si un certain nombre de fonctions peuvent être exécutées par le serveur, il reste important de limiter les accès et d'exécuter un certain nombre de fonctions côté client pour plus de réactivité. Les différents navigateurs sont entrés dans une course à la compatibilité et à la rapidité d'exécution de leur moteurs JavaScript précisément pour ces raisons. Mais aussi rapides qu'ils soient, les moteurs JavaScript ne pourront jamais arriver qu'à une fraction de la vitesse d'exécution du code natif. Il existait bien des moyens d'exécuter du code natif, comme par exemple les ActiveX, mais ceux-ci restent non seulement cantonnés à Windows, mais en outre ils posent de sérieux problèmes de sécurité, puisqu'ils sont susceptibles de faire tout un tas de misères à la machine sur laquelle ils s'exécutent.