JavaScript n'a rien à voir avec Java : petite histoire d'un marketing malheureux

Par Christophe Porteneuve • Publié le 17 septembre 2012 • 5 min

Le besoin d’origine et le cœur de la différence

Début 1995, Netscape domine le marché du web en général, fournissant tant des logiciels serveurs que le navigateur alors le plus populaire, Netscape Navigator. Ils viennent de lancer un partenariat avec Sun Microsystems pour exploiter leur nouveau langage et sa VM multi-plateforme, Java, tant au sein du navigateur (pour fournir une UI riche portable) que côté serveur (pour fournir le cœur d’applications accessibles via le web, au moyen d’un simple navigateur).

C’est une offre impressionnante, en concurrence directe avec Microsoft, qui commence à peine à accepter le fait que le web est là pour durer et qu’il constitue le prochain pivot technologique majeur.

Toutefois, Java est perçu par Sun et Netscape comme un langage de professionnels, peu adapté à une utilisation simple dans le cadre de pages web (on ne parle pas encore d’applis web, il faudra attendre 10 ans et l’avènement d’Ajax). Java est en quelque sorte le concurrent du Visual C++ de Microsoft, de ce point de vue. Il lui faut un langage compagnon plus simple d’approche, plus facile d’emploi pour les néophytes ou développeurs débutants, qui soit, si l’on veut, l’équivalent de Visual Basic. Facile à prendre en main, facile à imbriquer dans une page ou ailleurs.

C’est à Brendan Eich, gourou technique chez Netscape et futur CTO de Mozilla, qu’est revenue la tâche de créer ce langage « compagnon » de toutes pièces.

Ceci dit, on exige également que les deux soient bien différenciés, au sens où les développeurs potentiels doivent sentir que le nouveau langage est « dans le style Java » mais est moins puissant. Comme l’a expliqué Brendan dans une interview :

JS devait « ressembler à Java », mais en moins avancé, [il devait] être le petit frère simplet de Java, son partenaire-otage. Et par-dessus le marché, je n’avais que dix jours pour pondre ça, ou on se retrouverait avec un truc pire que JS.

Brendan Eich

JavaScript devait donc rester conscient des spécificités de la syntaxe de Java (JS 1.0 avait tous les mots-clés de Java réservés, et ses types standard copient souvent les conventions du JDK, par exemple autour de Math et Date), mais il devait aussi s’abstenir d’utiliser la syntaxe orientée-objet du langage, à une époque ou la POO (Programmation Orientée Objet) était encore considérée comme un sujet réservé aux professionnels…

Brendan ne voulait pas pondre un langage diminué, mais devait trouver des ruses pour y glisser assez de puissance sans que celle-ci soit immédiatement visible au profane. Le langage devait rester simple et léger en apparence, tout en ayant assez de sophistication pour que des développeurs avancés soient à même d’en tirer des applications puissantes.

Si les deux langages appartiennent à une famille syntaxique « de type C » (syntaxe des identifiants, accolades, opérateurs principaux, structures de contrôle…), ils ont des sémantiques extrêmement différentes. La philosophie de JavaScript est très fortement inspirée de langages objet ou fonctionnels « purs », au premier rang desquels [Self](http://en.wikipedia.org/wiki/Self_(programming_language)) et [Scheme](http://en.wikipedia.org/wiki/Scheme_(programming_language)), mais aussi certains aspects de SmallTalk et [LISP](http://en.wikipedia.org/wiki/Lisp_(programming_language)).

Java est un langage compilé, statique (chaque variable est typée explicitement) et doté d’un typage fort (le type déclaré contraint les valeurs de façon étroite, et aucune conversion implicite n’est mise en place), là où JavaScript est interprété et dynamique avec un typage plus léger (d’où la distinction entre == et ===, similaire à celle de PHP).

En Java, tout code existe à l’intérieur d’une classe. JavaScript ne l’exige pas.

Java, malgré près d’une décennie de débat stérile, n’a toujours pas de fonctions de premier ordre. JavaScript a des fonctions de premier ordre et, partant, des fonctions d’ordre supérieur.

Java utilise un modèle d’héritage « classique », mono-parent, basé sur l’héritage de classes. JavaScript est basé sur les prototypes et autorise plusieurs paradigmes de programmation, notamment les styles orienté-objet, impératif et fonctionnel (largement inspiré par Scheme).

Vous le voyez, les deux langages sont extrêmement différents, à un niveau pratique comme à un niveau fondamental, philosophique.

Les noms de départ

JavaScript était développé sous le nom de code Mocha, son nom officiel prévu étant LiveScript. C’était pourtant pas mal ce nom, vous ne trouvez pas ? Microsoft n’avait pas encore collé une connotation négative à « Live » à l’époque… Et d’ailleurs, dans les deux premières versions beta de Netscape Navigator 2.0, en septembre 1995, on trouve en effet LiveScript.

La décision marketing pourrie

Hélas, trois fois hélas, les marketeux ont voulu insister sur le rôle « collaboratif » de ce langage vis-à-vis de Java et ses applets, et tenter probablement de récupérer une partie du prestige issu du marketing de Sun autour de Java. Du coup, à partir de Netscape Navigator 2.0ß3, Brendan a dû le renommer JavaScript.

Et la confusion naquit.

Peu après, Netscape voulut, à juste titre, faire bénéficier JavaScript d’un processus formel de standardisation. IETF, ISO et le jeune W3C posaient chacun des problèmes distincts dans cette optique, de sorte qu’au final c’est l’ECMA (European Computer Manufacturers Association), un organisme de standardisation européen, qui a récupéré le bébé. Et on a vu apparaître la première édition du standard ECMA-262, pour le langage ECMAScript, qui est en pratique essentiellement utilisé en tant que JavaScript.

La 3ème édition (ES3) constitue le socle de la version la plus répandue/utilisée du langage (à peu près équivalente à JavaScript 1.5). La 4ème est morte-née, et la 5ème (ES5), désormais implémentée dans tous les navigateurs modernes, sert de socle aux applis web modernes et à JS côté serveur (avec Node.js notamment).

Ironie du sort

Ce qui à mon sens est assez amusant dans cette affaire, c’est que JavaScript est, finalement, disponible de base sur davantage de plates-formes et périphériques que Java, aujourd’hui. Même si l’explosion d’Android a fortement relancé le déploiement de Java, qui s’enorgueillit de « plusieurs milliards de périphériques installés » (comme en a longtemps témoigné la grande bannière Oracle/Sun à l’aéroport Charles de Gaulle terminal 1…), Java n’est pas tellement déployé sur d’autres plates-formes mobiles, et n’est pas non plus automatiquement présent sur toutes les plates-formes desktop.

Mais allez trouver un seul desktop, laptop, smartphone, tablette ou liseuse qui n’ait pas une runtime JavaScript installée—et s’en serve intensivement ! Dans certains cas, comme webOS et maintenant Firefox Mobile OS, JavaScript est au cœur-même de la plate-forme, constituant sa clé de voûte. Même sur iOS, Android ou les Blackberry récents, la tendance forte des mobile web apps repose très lourdement sur JavaScript. Petit à petit, les technologies collectivement appelées « HTML5 » remplacent ce pourquoi on avait encore recours aux applets ou, plus souvent, à Flash.

La couche serveur connaît elle aussi, depuis plus de 2 ans maintenant, une explosion de JavaScript comme langage de développement, avec des résultats impressionnants. La course à la performance des runtimes JavaScript (V8, cœur de Node.js, affiche des performances bluffantes), couplée au modèle de développement traditionnellement événementiel de JavaScript, qui permet d’assurer de fortes charges sans coût linéaire, y sont pour beaucoup.

Je souris en pensant que JavaScript, nommé ainsi parce qu’il essayait de « faire sérieux » et tirer parti des nues marketing auxquelles on portait Java, a déjà, je trouve, supplanté ce dernier en termes de présence sur les marchés qui comptent.