Gespräch mit Mozillas Chefentwickler Brendan Eich

Inhaltsverzeichnis

Wie steht es um die Weiterentwicklung von JavaScript? Der Erfinder der Sprache, Brendan Eich, beantwortete im Interview diese Frage – und gab als Mozillas Technikchef Einblick in künftige Pläne für Firefox.

Als Brendan Eich 1995 bei Netscape anheuerte, entwarf er in ein paar Wochen eine Programmiersprache, die heute in Sachen Verbreitung jede andere hinter sich lässt: JavaScript. Noch heute kümmert er sich um die Weiterentwicklung der Sprache und ihren Kern ECMAScript, von dem letztes Jahr Version 5 erschien (siehe Kasten). Im Hauptberuf lenkt er als CTO der Mozilla Corporation die Weiterentwicklung von Firefox.

heise Developer: Ist ECMAScript 5 ein fauler Kompromiss oder sind Sie damit glücklich?

Brendan Eich: Relativ glücklich – nichts ist vollkommen in der Welt der Standards. Bei ECMAScript 4 hatten wir ein gespaltenes Komitee: Die einen wollten, dass sich ES4 durchsetzt, andere wie Microsoft wollten etwas namens ES 3.1, das ziemlich lahm war.

Mehr Infos

Der Stand der Dinge bei ECMAScript

Der Sprachkern von JavaScript – also alles, womit man nicht auf das Dokument oder auf andere Schnittstellen zugreift – ist bei der European Computer Manufacturers' Association unter den Namen ECMA-262 oder ECMAScript standardisiert. Heutige JavaScript-Programmierung orientiert sich meist an ES3 von 1999. Der ambitionierte Nachfolger ES4 scheiterte 2008.

Ein konkurrierender Vorschlag mit moderaten Neuerungen und Rückwärtskompatibilität setzte sich durch und wurde unter dem Namen ES5 im Dezember 2009 als Standard verabschiedet. Er enthält unter anderem einen strict-Modus mit strengerer Syntax, erlaubt den Schutz von Objekten vor Schreibzugriffen (Metaprogrammierung), kann mit Gettern und Settern auf Eigenschaften zugreifen und interpretiert nativ die JSON-Notation (JavaScript Object Notation). Vieles davon unterstützen aktuelle Browser bereits.

Das ursprüngliche Konzept für ES4 war Adobes Favorit, das die Firma bei ActionScript 3 eingesetzt hat. Wir stießen auf technische Probleme bei der Standardisierung. Außerdem wurde ECMAScript zu einer richtig großen Sprache, so etwas wie C#. Viele Leute hatten gemischte Gefühle wegen ES4, auch die, die daran arbeiteten, und deshalb haben wir den Entwurf zurechtgestutzt.

In der Zwischenzeit hat Microsoft seinen Entwurf für ES 3.1 aufgewertet, vor allem in Sachen Metaprogrammierung und Vererbung. Wir fanden das Ansätze gut, aber an dem Punkt stieg Adobe aus – sie bekamen nicht, was sie wollten, und sie hatten viel investiert.

Trotz der Spannungen und unterschiedlichen Interessen stellte sich das Komitee (ohne Adobe) hinter einige Design-Grundlagen. Ich schrieb eine Nachricht namens "Harmony". Wir waren uns alle einig, dass der Sprache einige Funktionen zur Code-Integrität fehlten wie das Einfrieren von Objekten, die die dynamische Natur von JavaScript ergänzen. Seinerzeit entwarf ich die Sprache recht schlampig, weil ich so wenig Zeit hatte. Aber das ist 15 Jahre her, und jetzt haben wir große JavaScript-Anwendungen. Selbst wenn man Sicherheit außer Acht lässt, muss man sich vor seinen eigenen Fehlern oder vor denen der Kollegen schützen.

Ein besonders umstrittener Bereich waren Namensräume, um die Namen der einen von denen der anderen zu trennen. Das ist eine sehr attraktive Idee, aber so wie in den Entwürfen zu ES4 hätte es nicht funktioniert – nicht ohne zusätzliche Maschinerie, wie sie der Flash Player enthält. Für Harmony einigten wir uns darauf, auf Namensräume zu verzichten und die Syntax komfortabler zu gestalten, ohne JavaScript zu einer Riesensprache zu machen. JavaScript hat ein paar Stärken, die wenige andere Programmiersprachen teilen, zum Beispiel erstklassige Funktionen und Closures. Man kann mit ihr fast alles bewerkstelligen, aber manches wird fehleranfällig oder nervig.

Das war die Geschichte von ES4, das teilweise aus politischen, teilweise aus technischen Gründen gescheitert ist. Im Juli 2008 einigten wir uns bei einem Treffen in Oslo, und Anfang 2009 änderten wir den Namen von ES 3.1 in ES5. Auf die Weise erinnern wir auch an die Version 4, die wir übersprungen haben. Der Harmony-Entwurf soll bis Ende 2013 fertig werden, der Prototyp anderthalb Jahre vorher – wir wollen wirklich keine zehn Jahre brauchen, selbst die Leute von Microsoft wollen nicht zurück zu diesem Stillstand. Einige Harmony-Vorschläge werden in ES6 eingehen, andere vielleicht in Version 7.

heise Developer: Und die "Harmony" im Projektnamen spiegelt die Stimmung im Komitee wider?

Eich: So ziemlich. Man bekommt keine große Gruppe technisch versierter Leute dazu, sich in allem einig zu sein, und ihre Firmen haben auch Interessen, aber die grundlegenden technischen Werte teilen alle.

Die Entwicklung von Standards ist etwas Langfristiges, es geht dabei nicht um kurzfristige Marktvorteile. Die Browser-Hersteller mit kleinem Marktanteil klagen manchmal, dass die Großen De-facto-Standards erstellen. Doch diese Standards sind ein wichtiges Signal: Sie drücken aus, was Entwickler machen. Ein Beispiel sind die Getter und Setter in ES5. Solche Standards lenken das Komitee; wenn es nur erfindet, macht es mehr Fehler, selbst wenn es regelmäßige Entwürfe veröffentlicht. WebKit ist ein Beispiel, dass der größere nicht immer den kleineren Marktanteil herumkommandiert.

heise Developer: Durch die kompilierenden JavaScript-Engines hat die JavaScript-Programmierung einen gewaltigen Schub bekommen.

Eich: Ja, man sieht Sachen, von denen man früher nicht glaubte, dass sie möglich sind, zum Beispiel in Canvas. Die Leute benutzen JavaScript zur Darstellung ebenso wie zur Berechnung. Das schlägt auch auf die Serverseite durch, etwa in der NoSQL-Bewegung. Ich erwarte aber nicht, dass sich JavaScript auf der Serverseite durchsetzt, weil es dort so viele Sprachen zur Auswahl gibt, von denen einige gut sind. JavaScript hat eine funktionale Natur, anders als etwa Java. Das ist auch die Stärke von einem Projekt wie node.js – es reduziert die Schichten und erleichtert die Kommunikation zwischen den Maschinen. So etwas hätte ich nicht vorhergesehen.

heise Developer: Sind die JavaScript-Bibliotheken Experimentierlabore für die Programmiersprache?

Eich: Ich glaube, die Bibliotheken sind mehr als Kleber für die Browser-Inkompatibilitäten. Sie geben den Programmierern ein höheres Abstraktionsniveau und eine Auswahl beim Programmierstil. Ein Komitee wird keine gute Arbeit bei der Standardisierung von Bibliotheken leisten – man sieht das an den Problemen bei den C-Bibliotheken, die sehr schwer zu standardisieren waren und Sicherheitslücken enthielten. Voreilige Standardisierung ist ein Fehler. Wir stehen bei den JavaScript-Bibliotheken noch am Anfang. In Harmony fügen wir der Sprache Module hinzu, damit die Bibliotheken besser zusammenarbeiten können. Es wird noch viele Experimente geben, vielleicht auch eine Standardisierung, aber nicht so schnell.