Harmonie au pays des scripts
Par Jean-Marie Chauvet

mardi 19 août 2008

Dans un monde informatique qui nous avait habitué à voir les organismes de standardisation se transformer en arènes de combats commerciaux, l'irénisme du Comité technique n°39 de l'ECMA, réuni en Norvège la semaine dernière, fait plaisir à entendre ! Ces nouveaux accords d'Oslo scellent un apaisement entre deux factions dont les désaccords menaçaient rien moins que le bon fonctionnement de nos indispensables navigateurs Web.

Vous l'aurez certainement compris : il s'agit ici du sujet pressant de la standardisation de l'évolution de Javascript, le langage de script qui s'est glissé, sous des dialectes variés, au cœur de nos navigateurs. Javascript, maintenant banalisé, est pourtant né dans la douleur. Baptisé à l'origine LiveScript, le langage est apparu en 1995 avec la première version du navigateur Netscape qui acceptait les applets Java — la grande nouveauté de l'époque. Conçu par Brendan Eich, il visait à simplifier les interactions entre pages Web et applets pour les non-Javaïstes, la majorité des développeurs en ces temps protohistoriques du Web. Soumis à un feu nourri de critiques acerbes visant tout à la fois la monumentale erreur (de jeunesse) de marketing dans le choix de « Javascript » comme nouvelle dénomination — déclenchant une confusion durable entre Java et Javascript pendant les premières années —, les innombrables failles de sécurité du système de scripts, l'absence d'environnement de développement et de debugging, les incompatibilités flagrantes entre navigateurs, Javascript acquit cependant une vie et un développement autonome loin des applets Java initiales, atteignant peut-être au succès précisément en raison de ces faiblesses. D'accès apparemment facile, pratique, interprété et donc moins contraignant pour certains que les langages à compiler, rapidement réutilisé d'une page Web à l'autre, c'est l'apogée de la technique du « copier-coller » à l'heure de l'Internet.

Les choses devinrent plus sérieuses quand Microsoft donnait non pas une mais deux versions d'un langage de script pour le Web : VBScript originellement limité aux plates-formes Windows, et JScript, en 1996, son propre portage de Javascript pour Internet Explorer. Les incompatibilités importantes entre ces différents dialectes valurent alors à Javascript la réputation pas totalement usurpée d'écueil dans la mer de standards et de protocoles ouverts du Web. L'irruption d'un Microsoft affichant sa stratégie « embrace and extend » de 1996 alors qu'il devait trébucher dans le méga-procès anti-trust dont les scories sont toujours sensibles aujourd'hui, poussèrent aussi Netscape et Sun Microsystems à chercher une réponse tactique, en proposant de standardiser rapidement le langage en le confiant à l'ECMA — un choix d'organisme de standardisation européen qui surprit à l'époque — qui l'adopta mi-1997, ainsi que l'ISO, un an plus tard. La dernière révision de ECMAScript, puisque tel est le troisième patronyme du langage, date de 1999 (ECMA 262, 3e édition).

Depuis quelques années une très ambitieuse version 4.0 du langage était en cours de spécification, également connue sous le surnom de « Javascript 2 », touchant aux sujets délicats de l'adjonction (ou non !) de véritables classes avec héritage, de fonctions génériques, de réflexion, de systèmes de types sophistiqués, bref de l'appareillage moderne d'un langage de programmation orienté objet ultra-complet. Avec, une fois de plus dans son histoire mouvementée, la menace d'incompatibilités majeures entre les éditions n°3 et n°4 d'ECMAScript. (Au moment même où, dans l'industrie qui décidément avance sans nécessairement se soucier de la discipline des standards, Javascript joue un rôle devenu primordial avec le succès de facto d'Ajax et la banalisation d'une version light des services Web.)

Cette question cristallisait depuis un an l'antagonisme entre deux courants de l'ECMA : les suppôts de l'édition n°4 dans toute sa gloire, principalement Opera, Mozilla, Adobe/Macromedia et Google — rien que le standard mais tout le standard ! — et les partisans d'une amélioration incrémentale de l'édition n°3, une version 3.1 qui aplanirait les principales difficulté et coûterait moins à implémenter, et dont les champions sont plutôt Yahoo! et Microsoft. (Tiens ! Microsoft est en pleine phase Beta d'Internet Explorer 8.0 et a lancé sans succès, il y a peu, une OPA sur Yahoo!)

À Oslo, les tractations de la semaine dernière ont abouti à un « recentrage sur la simplicité et sur les extensions pragmatiques » comme il est politiquement correct de l'exprimer. D'ailleurs pour témoigner des épanchements soudains de bons sentiments entre factions naguère irréductibles, il a été convenu de rebaptiser le projet ECMAScript Harmony !

L'harmonie est donc revenue au pays des scripts. La version 3.1 d'ECMAScript s'inscrit bien sûr dans le contexte plus vaste des spécifications putatives de l'édition n°4, reprenant certaines notions (comme une version édulcorée des classes) mais en laissant d'autres de côté, en particulier celles relatives aux visions grandioses de nouvelles syntaxe et sémantique du langage.

Doug Crockford, inventeur de JSON et Senior Javascript Architect de Yahoo!, s'empresse de se féliciter de cette sage décision dans son blog ; Mike Chambers d'Adobe, quant à lui, se veut rassurant : ActionScript 3, qui était basé sur l'édition n°4, « n'est absolument pas affecté par la décision d'Oslo », tout est donc pour le mieux. (Mozilla avait parrainé et adopté le projet Open Source Tamarin d'interpréteur ActionScript 3/Javascript 2, sur lequel travaillait Adobe sur la base de ECMAScript n°4, l'enjeu est donc de taille.)

Mettant un point final à la discussion, Brendan Eich, dans un courrier électronique récent, loue l'œcuménisme et la sérénité retrouvée du groupe de travail.

Tous harmonisés, il n'en reste pas moins, me semble-t-il, que chacun reste finalement sur ses positions : Microsoft peut continuer à livrer trois implémentations différentes d'un langage de script (Windows Scripting Host JScript, JScript.NET, et JScript pour DLR dans Silverlight, dont il n'est pas très clair que les VM partagent effectivement du code) ; Adobe continuer à promettre des innovations dans ActionScript 3 et éventuellement proposer une version de Javascript conforme aux spécifications plus modestes de l'édition 3.1, ce qui sera encore plus facile quand Mozilla livrera de série dans Firefox un front-end Javascript à Tamarin.

Il nous restera à voir, pauvres utilisateurs désarçonnés, si les implémentations promises incessamment seront aussi harmonieuses qu'annoncées...