| |
 |
Brendan Eich
Directeur technique
Mozilla Corporation |
|
Brendan Eich (Mozilla Corp.)
"Si IE ne change pas, il continuera de perdre des parts de marché"
L'inventeur du JavaScript décrit les conditions de la création de ce langage aujourd'hui omniprésent, son gain de popularité grâce à Ajax, et ce que l'on peut attendre de la prochaine version.
14/02/2007 |
| |
 |
 |
On vous cite souvent comme l'inventeur de LiveScript pour Netscape en 1995. Etiez-vous seul sur le projet ?
Brendan Eich C'est bien moi. En mai 95, j'ai créé en une semaine le prototype du langage Mocka - un Java plus doux (NDLR : "java" est l'argot américain de "café"). L'idée était de créer un langage de script pour HTML, et permettre aux développeurs d'intégrer des programmes directement dans leurs pages plutôt que de passer par le serveur, afin d'ajouter des événements, valider des formulaires, etc. Dix jours pour faire le prototype, puis le reste de l'année passée à l'intégrer au sein de Navigator. Le nom a ensuite été influencé par des accords avec Sun, qui voulait miser sur la réussite de Java sur le Web.
Vous a-t-on demandé de lui donner une syntaxe plus proche de Java, pour plaire à Sun ?
Au début, l'idée était de le faire ressembler à du Basic. Puis ça a été le tour de Oak/Java, le travail avec le navigateur HotJava de Sun et la course pour le finir, tandis que Sun créait de son côté AWT. Avec la frénésie de l'époque, les opinions étaient partagées : n'en faire qu'un Java, n'y mettre que l'essentiel, conserver la déclaration de type...
Mais l'on s'est vite rendu compte que les pages seraient créées par des non-programmeurs, donc qu'on ne pouvait pas imposer la complexité de Java : nous devions élargir l'audience du langage, permettre à tous de l'utiliser, d'écrire et reprendre du code, comme HTML.
En bref, faire ce qu'avait fait Microsoft en ayant d'un côté C++, et de l'autre Visual Basic. Personne ne savait vraiment que faire, le management poussait pour un Java-like tandis que nous voulions simplifier. Le prototype que j'ai créé a convaincu tout le monde.
Que pensez-vous de JScript, l'implémentation Microsoft de EcmaScript ?
Il faut d'abord savoir que EcmaScript est un nom anti-procés. JavaScript est une marque déposée par Sun, donc on ne pouvait pas l'utiliser pour le standard Ecma, et pour la même raison le JavaScript de IE s'appelle JScript.
JScript a longtemps suivi un chemin parallèle, et offrait de gros problèmes côté développement. Le ramasse-miettes de IE6 cause un gros ralentissement des scripts. Ils ont corrigé le problème depuis, mais pour le reste de IE7, je ne suis pas vraiment au courant. Mais nous parlons là des différences au niveau du langage lui-même, et il y en a très peu finalement. Les gros problèmes viennent du DOM. Il n'était pas complètement standardisé quand il a été implémenté dans IE, ils n'ont pas tout implémenté et ont ajouté leurs propres fonctionnalités, comme la propriété innerhtml.
Pour IE8, Microsoft doit agir sur le court terme. IE doit évoluer sans casser les usages des utilisateurs. Ils peuvent soit adopter les standards, soit partir à nouveau sur leur propre route. Le danger est de laisser certains contenus de côté, créé pour ActiveX ou spécifiquement pour IE - mais cela arrivera à un moment ou à un autre. Si IE ne change pas, il continuera de perdre des parts de marché. Les développeurs ont leur mot à dire sur ce qui est déployé au sein des entreprises. Ceux-ci veulent faire de l'argent en développant avec les techniques de pointe. L'influence sur le devenir des navigateurs va donc au-delà des parts de marché.
Les gens détestaient JavaScript et DHTML, et maintenant ils adorent le langage. Quand situeriez-vous le moment où la tendance s'est inversée ?
|
|
 Avec JS2, il sera possible de réécrire toutes les énormes bibliothèques de code actuelles en prenant beaucoup moins de place" |
|
Cette haine provenait principalement des popups, une fonctionnalité mise en place avec Netscape 2. Une fois intégrée à IE4, elle a été largement pervertie. Dès que les navigateurs ont commencé à intégrer des bloqueurs de popups, cette haine de JavaScript a baissé. Ensuite, il suffisait d'une killer-app : c'est principalement Google, avec GMail et GMaps, qui a donné l'impulsion.
A l'époque, Firefox décollait tout juste, suite à l'annonce de Microsoft qu'ils ne sortiraient pas de nouvelle version de IE, alors que celui-ci était vulnérable. Firefox marchait mieux pour les développeurs, d'autant que grâce au dialogue avec la communauté, un moteur XSLT a été ajouté, pour faire marcher les applications de Google. Idem pour Opera : c'est parce que live.com ne fonctionnait pas qu'ils ont décidé d'émuler JavaScript et d'ajouter un moteur XSLT. Ainsi, les standards et la collaboration ont beaucoup aidé. En partageant ses idées ou en suivant le leader - ou le second -, on peut espérer ne plus attendre 10 ans pour le prochain Firefox.
L'objet XMLHttpRequest était une innovation propriétaire d'IE. Quelle intuition a poussé à son adoption par d'autres navigateurs ?
IE était le navigateur dominant, donc pour un développeur il était difficile de justifier travailler pour un autre. L'objet XMLHttpRequest (XHR) a été créé pour les ingénieurs de Microsoft : ils ne pouvaient évidemment plus utiliser Java pour certaines applications, donc ils ont mis au point XHR. Ils n'ont certainement pas vu le futur d'Ajax, mais simplement son utilité. Et parce qu'il fallait suivre les développements d'IE pour proposer la même chose aux développeurs, nous avons vu que ce pourrait être utile, même si la demande était encore faible, et l'avons adapté à notre manière. Aujourd'hui, il y a un groupe de travail ad hoc pour cette API. Pas sûr que Microsoft y participe, mais ils ne peuvent plus geler le Web.
Qu'est-ce qui a relancé le développement de JavaScript ?
L'activité a été relancée en 2003. Elle était maintenue par Waldemar Horwat après la fin de la guerre des navigateurs. Avec un IE dominant, il n'y avait pas de raison d'en pousser le développement. Le succès de Firefox a changé la donne, tout comme le développement de E4X (ECMAScript For XML). Et n'oublions pas Macromedia, qui en adoptant EcmaScript comme base du langage ActionScript a largement relancé l'intérêt du standard. L'ActionScript 3 de Flash 9 est d'ailleurs basé sur une préversion de EcmaScript 4, et donc de JavaScript 2...
Avec les besoins d'interopérabilité, il fallait remanier le document, le rendre plus clair, et standardiser ce que font effectivement les navigateurs. La 3e édition du standard n'était qu'une spécification papier, avec correctifs et compagnie ; cette fois, nous allons proposer une implémentation de référence écrite en Standard ML, une framework de vérification... Nous comptons bien aboutir à une spécification solide. Les navigateurs doivent être cohérents, et cette spécification devrait les y aider. Il est donc rassurant de retrouver les grands acteurs au sein du groupe de travail : Adobe, Microsoft, Opera, Apple, Yahoo!, et bien sûr Mozilla.
|
|
Le desktop se meurt. Les langages à base de machine virtuelle s'en sortent de mieux en mieux" |
|
JavaScript 2 apportera des nouveautés importantes, comme les espaces de noms, les classes explicites... Pouvez-vous nous donner une idée de ce que l'on peut en attendre, et les raisons de ces nouveautés ?
Nous tentons principalement de répondre aux cas où l'utilisation de JavaScript peut être problématique. Lors de sa création, nous avons dû faire vite pour le mettre en place, mais j'ai insisté sur deux aspects : les fonctions sont des objets première classe, et l'utilisation de la programmation à base de prototype, inspiré par Lisp et Self. Grâce à eux, les gens ont pu faire des choses formidables.
Mais le problème, c'est que tout le monde ne connaît pas ces idiomes, et donc ne peut pas en profiter. Donc l'objectif de la 4e édition du langage, c'est d'ajouter plus de fonctionnalités, que les gens puissent écrire ce qu'ils pensent, de manière sécurisée. Cela implique entre autres choses un système de typage.
Nous modifions également le système de gestion des virgules flottantes. Comme pour Java, C++ et les autres, JavaScript utilise le standard IEEE 754, qui est notoirement insuffisant aujourd'hui, surtout avec les systèmes à 64bits. Nous travaillons à implémenter le successeur de ce standard, IEEE 754r, au sein de JavaScript 2, avec un pragma "use decimal", ce qui enrichira largement l'utilisation des mathématiques, au bénéfice par exemple d'applications financières.
Les développeurs JavaScript devront donc adapter leur code à ce nouveau standard ?
Normalement, cela impliquerait de réécrire une grande partie du code existant, ce que nous ne pouvons nous permettre : trop d'utilisations de JavaScript reposent sur du code qui n'est même plus entretenu. Donc c'est à nous d'écrire le standard de telle sorte qu'il puisse émettre une sorte de jugement, qu'il puisse relier l'ancien code au nouveau code. Ce n'est pas une idée nouvelle, mais cela reste assez inhabituel.
Pour profiter pleinement de JavaScript 2, nous placerons des limites. Il y aura probablement un mode strict, comme le pragma "use strict" de Perl. Grâce à ce mode, il sera possible de réécrire toutes les énormes bibliothèques de code actuelles en prenant beaucoup moins de place.
Mais de nombreux développeurs ne veulent pas des classes, et n'en auront pas besoin : ils pourront en rester à l'ancienne manière. D'autres adopteront la nouvelle manière, préféreront les classent, en obtiendront un code plus efficace et évolutif dans le cadre de grands projets. Même sans connaître les idiomes classiques de JavaScript, comme le prototypage, ils pourront eux aussi faire des choses formidables.
Dans tous les cas, les deux manières peuvent être mélangées, ce qui est une première dans les conflits "ancien code contre nouveau code". A la sortie de Python 2.5, de nombreux acquis ont été remis en question, et on ne peut pas se le permettre pour JavaScript : sur Internet, il faut plusieurs années avant qu'un contenu ne meure.
Adobe mise fortement sur les applications riches avec Flex, et donc sur ActionScript 3 / JavaScript 2. Quel est votre point de vue sur ce projet ?
|
|
Les contenus Flash et Web devraient continuer de se rencontrer et se mélanger, de manière toujours plus ouverte" |
|
Adobe a été d'une aide énorme, en soutenant la proposition de Waldemar Horwat pour la 4e édition d'EcmaScript, en travaillant avec BEA et Microsoft sur E4X, et depuis que Mozilla a rejoint le groupe de travail TG1 de l'Ecma, en travaillant sur la nouvelle édition avec les acteurs dont j'ai déjà parlé et les universitaires intéressés. Enfin, ils ont passé Tamarin en Open Source pour Mozilla. Donc mon point de vue est très positif.
De ce que j'en ai vu, la plate-forme Flex est très proche de XUL à un niveau supérieur, si vous comparez le langage de balise et son algorithme de boîte de mise en forme. Il y a également des différences frappantes au niveau du runtime, le FlashPlayer d'un côté, le moteur de rendu du navigateur de l'autre. Flash maîtrise les objets vectoriels 2D, mais ne dispose pas d'un DOM. Firefox et les applications XUL utilisent fortement le DOM pour mettre en place leurs widgets et propager les modifications, pas seulement les événements d'entrée/sortie.
À mon avis, les contenus Flash et Web devraient continuer de se rencontrer et se mélanger, de manière toujours plus ouverte. J'espère que la convergence d'ActionScript et JavaScript via Tamarin aidera à cet accomplissement, mais cela dépend de nombreuses autres variables.
Voyez-vous JavaScript devenir viable pour des applications lourdes, remplaçant C/C++ dans certains contextes ?
Le desktop se meurt. Bien sûr, si vous devez écrire un système d'exploitation ou un Word, utilisez C++. Cependant, les langages à base de machine virtuelle s'en sortent de mieux en mieux - je pense notamment à C#, pas seulement côté Microsoft mais aussi avec le projet Mono de Novell, plus que je ne pense à Java.
Mais les applications basées sur le navigateur ont la plus grande portée et offrent le plus de bénéfices pour donner le pouvoir à l'utilisateur - avec les mashups, les extensions de Firefox comme GreaseMonkey et ses user-scripts, ou simplement la capacité à faire un lien et naviguer. Plus qu'un JavaScript superrapide, il y a un besoin pour un meilleur stockage local, la possibilité de faire tourner une application Web hors ligne, et d'autres bonus sur lesquels nous travaillons avec le WHAT WG, et que nous implémentons dans Firefox 3.
Un JavaScript 2 avec de meilleures performances arrivera bien assez tôt, mais ce n'est qu'une pièce du puzzle de la programmation côté client Web, et toutes les pièces doivent évoluer. API graphiques, meilleur rendu du texte, meilleure extensibilité des widgets et du DOM, meilleure performance générale : tout cela compte autant que la puissance brute de JavaScript.
|
| |
Propos recueillis par Xavier Borderie, JDN Développeurs |
|
Dossier 
