Du pire au mieux

Il faudrait être aveugle pour ne pas remarquer l'engouement grandissant ces dernières années pour l'utilisation de Javascript dans les navigateurs pour la construction de la partie client d'une application navigateur.

Ce langage qui a sa création a été perçu, avec raison, comme une chose bancale, lente et aux implémentations hasardeuses est devenu en quelques années un langage présent au cœur d'applications très sérieuses. La littérature produite autour de son utilisation est aussi passée de petits livres d'astuces à de vraies livres d'informatique couvrant les meilleures pratiques, les performances ou encore l'architecture logicielle.

C'est que, même si le langage et son environnement était mal définis, mal implémentés, ils se sont révélés composer tout de même le moyen le plus simple de transformer un monde de pages web statiques en une utilisation dynamique plus habituelle dans les applications traditionnelles.

L'ajout de la possibilité d'emmètre des requêtes http depuis l'intérieur d'un programme Javascript client (dans un navigateur) a ouvert la voie à des échanges avec le serveur plus fluides, plus légères et a permis à des armées de départements marketing de manipuler des termes évocateurs comme « cloud » ¹ ou « webapp ».

Avec son utilisation côté serveur, avec par exemple node.js, et le fait qu'il soit à présent mieux implémenté côté clients, Javascript obtient ses lettres de noblesse. On peut même trouver des environnements pour créer des applications de bureau traditionnelles en Javascript (par exemple Gnome Seed).

Du mieux au pas pire

Pourtant, à quelques modifications près, Javascript a peu bougé. C'est plutôt son environnement qui a été mieux défini et de manière plus uniforme (le DOM par exemple), ou bien grandement amélioré (VM plus performantes, apparition de ,...) ; ainsi que la maîtrise du langage et les outils disponibles.

À la lecture d'ouvrages ou articles sérieux sur le Javascript, ce qui revient le plus souvent est la nécessité pour fabriquer des applications qui tiennent la route d'avoir recours à des pratiques de programmation rigoureuses appuyées par des outils d'analyse statique et des systèmes de constructions permettant de produire un « exécutable » final.

Les risques du langage étant à présent plutôt bien connus, des outils existent pour les réduire. Par exemple, Google Closure permet d'annoter le code source pour faciliter l'analyse statique. Cependant, la syntaxe en devient assez alourdi, et, étant un outil externe, n'est pas partagée avec d'autres outils d'analyse.

Au final, la communauté a produit de quoi construire des applications robustes sur des bases qui le sont peu. On pourrait rapprocher cela du C, langage très permissif qui, au fil de nombreuses années, a développé un bagage énorme permettant au programmeur attentionné d'être aidé contre ses possibles erreurs d'étourderie.

Langage ou environnement ?

Une autre façon de contourner les lacunes du Javascript en tant que langage (sans prendre en compte son environnement d’exécution) a été de proposer des langages qui se compilent en Javascript. Coffee Script par exemple produit un exécutable en Javascript et offre des constructions plus sûres en gardant une parenté avec le Javascript.

D'autres initiatives proposent un langage différent dans l'optique d'offrir une alternative dans le domaine d'utilisation de Javascript. Dart par exemple.

Récemment sont aussi apparus des compilateurs pour différents langages de programmation allant du C++ au Caml en passant par Python qui prennent des fichiers sources dans ces langages et produisent un code Javascript équivalent.

Ces différents projets font se poser la question : finalement, est-ce leJavascript qui est au cœur du développement web, ou plutôt son environnement naturel, le navigateur web ?

Avec le développement des capacités des navigateurs, l'arrivée du HTML5 (lui-même associé au développement du Javascript), de WebGL, de leurs stabilisations, de leurs performances accrues, de leurs présence sur de très nombreuses plateformes et de leur connectivité naturelle, on se retrouve avec un environnement d'exécution très agréable au-dessus du système d'exploitation natif.

Cet environnement offre naturellement des capacités d'affichage, une couche réseau, de la sérialisation locale. Malgré certaines limitations, comme le traitement sonore ou certains périphériques d'entrée, l'environnement permet de développer des applications avec assez peu de code.

Le langage de script naturel de ces navigateurs (le défaut pour la balise <script>) étant le Javascript, l'utilisation de l'environnement s'est historiquement fait en Javascript, permettant de développer encore plus l'environnement.

Mais on vient de le voir, l'époque est à présent au contournement des limitations du Javascript. Au niveau des chaînes de fabrication, l'une des dernières étapes avant déploiement est même la diminution du nombre de fichiers de script (voire même la construction d'un fichier unique) et la diminution de leur taille par compactage de code ² et même par compression [^3].

Une machine virtuelle standardisée

Finalement, ce qui a l'air d'intéresser une bonne partie des développeurs web(voire la majeure partie des développeurs) n'est pas spécifiquement le Javascript, qui est un moyen, mais la possibilité d'utiliser un environnement d'exécution pratique et facile à déployer.

La manière de construire une application web actuellement ressemble tout à fait à une application standard, ou plutôt à une application qui cible une machine virtuelle comme du Java ou du C#. Le résultat de la construction du programme ressemble à du bytecode à ceci près que c'est du Javascript compacté.

Ce qui m'amène à cette question qui est aussi le titre du billet : est-ce qu'il ne vaudrait pas mieux pour les navigateurs offrir l'accès à la machine virtuelle qui est nécessairement présente pour exécuter le Javascript ? Si celle-ci était normalisée et disponible sans passer par la phase d'analyse du Javascript, on aurait alors éviter l'étape maladroite de détournement du Javascript en pseudo bytecode, et différents langages pourraient cibler directement cette machine.

Ce qui n'empêcherait pas les navigateurs de garder la possibilité d'exécuter directement du Javascript. La prise en charge native éviterait de plus l'échec qu'on connu les applets Java.

[^3] en profitant des capacités des navigateurs à décompresser des images ; cet usage est plutôt limité au domaine de la démo actuellement car pas forcément portable et sans feedback utilisateur.