Brendan Eich: Hektik führt zu Fehlern
Durch den großen Zeitdruck bei der Entwicklung von Javascript sind aber auch Faktoren in die Sprache eingeflossen, die Eich heute bereut und für die er sich entschuldigt. Er nennt unter anderem die Funktion eval(), das With-Statement und die Tatsache, dass das globale Objekt auf oberster Ebene umgesetzt ist. Die ersten beiden dieser drei Fehler seien mittlerweile in den Standardisierungsorganisationen behoben worden, sagt Eich und verweist auf den Strict-Mode in Ecma-Script 5.
Das Problem mit dem globalen Objekt soll laut Eich in der nächsten, der 6., Edition von Ecma-Script behoben werden. Zwar liegt dafür schon ein Entwurf vor und es gibt prototypische Implementierungen für Spidermonkey, der Javascript-Engine von Firefox. Eich rechnet aber damit, dass es noch einige Jahre dauern wird, bis der neue Standard verabschiedet wird. Zudem arbeitet ein Team in München an der Umsetzung des Standardentwurfs für Googles Javascript-Engine V8, so dass es voraussichtlich möglich sein wird, noch vor Fertigstellung der Spezifikation mehrere Implementierungen auf Interoperabilität zu testen.
Coffescript als Brücke in die Zukunft
Künftige Versionen von Javascript sollen Erweiterungen beinhalten, die Entwickler nutzen können, um Javascript-Programme schneller zu machen. Diese werden aber möglicherweise nicht in allen Browsern zur Verfügung stehen. Entwickler werden die entsprechenden Funktionen explizit nutzen müssen, wie Eich erklärt. Um das zu vereinfachen, kann ihm zufolge beispielsweise auf Coffescript ausgewichen werden. Darin geschriebener Code wird in Javascript übersetzt, so dass die Programme nur neu erzeugt werden müssen, um von den Erweiterungen profitieren zu können - vorausgesetzt, Coffescript verwendet diese Neuerungen dann.
Als Beispiel für eine solche Erweiterung führte Eich Typed Arrays an, die für WebGL eingeführt wurden. Sie ermöglichen es, umfangreiche Arrays aus Gleitkomma- oder Ganzzahlen zu erzeugen, die dann effizienter verarbeitet werden können. Denkbar sei zudem, Schleifenvariablen als solche zu markieren, damit Javascript-Engines diese zuverlässig erkennen und behandeln können, was die Effizienz ebenfalls steigern würde. Die letzte Meile der Javascript-Performance-Optimierung nennt Eich das.
Parallelisierung
Große Erwartungen setzt Eich auch in das von Intel entwickelte Parallel Javascript. Die Erweiterung mit Codenamen River Trail wandelt Javascript in WebCL um, nutzt dabei aber keine neuen Schlüsselwörter in Javascript, abgesehen von parallelen Arrays. Diese können dann auf die Multi-Core-Hardware, die sich heute in vielen Desktoprechnern und zunehmend auch in mobilen Endgeräten befindet, besonders effizient verarbeitet werden. Der Vorteil: Der Ansatz soll für Entwickler leicht zugänglich sein.
Eich geht davon aus, dass der Ansatz in die Javascript-Standards einfließen wird, so dass künftig die Javascript-Engines dafür verantwortlich sind, dass solche Datenstrukturen parallel abgearbeitet werden.
Absage an Google Native Client
Mozillas wiederholt geäußerte Ablehnungen von Googles Native Client, mit dem sich nativer Code plattformübergreifend im Browser ausführen lässt, unterstreicht Eich im Gespräch mit Golem.de. Der Native Client sei zwar ein sehr interessantes Forschungsprojekt und zudem gut umgesetzt. Eich sieht jedoch zwei Probleme bei Googles Ansatz: Zum einen bedürfe der Native Client eines sehr umfangreichen APIs im Browser (Pepper API), das derzeit nur in Chrome zur Verfügung stehe und auch durch dessen Quellcode definiert sei. Daher sei es sehr unwahrscheinlich, dass das Pepper API von anderen Browserherstellern aufgegriffen werde. Zum anderen hält Eich nativen Code im Web für keine gute Idee, denn der Ansatz führe dazu, dass die APIs mit der Zeit extrem ausgeweitet werden müssten, was auf allen Seiten sehr viele Ressourcen beanspruche. Die komplexe Vielfalt auf der Serverseite müsse derzeit auf der überschaubaren Zahl von Webstandards abgebildet werden, die Browser unterstützen. Das erleichtere die Interoperabilität, sagt Eich. Eine überschaubare Anzahl von APIs sei ein wichtiger Faktor, um die Offenheit des Webs zu erhalten.
Er geht auch davon aus, dass etwas Ähnliches wie Native Client in einer plattformübergreifenden Version eher seinen Weg in Betriebssysteme finden werde, um beispielsweise Plugins besser abzusichern.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Javascript: Vom Kinderkram zur universellen Scriptsprache | Javascript ein Sicherheitsrisiko? |
Weil? Weil? null und undefined sind keine. Und sonst? Im Gegensatz zu beispielsweise...
Das ist kein Schwachsinn, sondern die Fakten. Die einzigen Werte, die in JS keine...
Nicht JavaScript ist das Problem, sondern Browserhersteller, die sich mit inkompatiblen...
Du baust etwas auf was keiner hier, bis zu deinem Beitrag, behauptet hat. Warum?