Dieser Artikel ist Teil einer Serie:
Heimlich, still und leise hält die nächste Version von JavaScript Einzug in unsere Browser. Überschattet von Trubel um HTML5 und CSS3 merkt fast keiner, dass neben HTML und CSS auch das oft so verkannte JavaScript dabei ist, ein größeres Update zu erfahren und dass sich somit alle drei Grundpfeiler des Webs – HTML, CSS und eben JavaScript – weiterentwickeln. Dieser Artikel soll der Startschuss zu einer kleinen Serie sein, in der wir einen Blick auf ECMAScript 5 (oder kurz ES5) und damit die nähere Zukunft von JavaScript wagen werden. Besonderes Augenmerk werden wir natürlich darauf richten, in welchem Umfang die verschiedenen Neuerungen schon zu gebrauchen sind, doch unser erster Blick gilt den Hintergründe von ES5. Was ist eigentlich „ECMAScript“ und wieso hat es die Versionsnummer 5?
Was ist ECMAScript und wieso gibt es Version 5?
Als Anfang der 90er Jahre Brendan Eich für Netscape innerhalb weniger Tage eine kleine Browser-Programmiersprache zusammenschraubte, grassierte der Java-Wahn. Man war sich damals so sicher, dass Java die wichtigste Programmiersprache der Zukunft sein würde, dass man aus Marketinggründen entschied, die neue Browser-Programmiersprache JavaScript zu nennen – obwohl beide Technologien sich auch nicht nur im entferntesten ähneln. Dass man damit bis in alle Ewigkeit Verwirrung bei Webentwicklern stiften würde, war weniger wichtig, als dass man dort war, wo man damals „vorne“ vermutete.
JavaScript had to look like Java only less so, be Java’s dumb kid brother or boy-hostage sidekick.
Seither hat sich viel getan. Java hat überraschenderweise nicht die Weltherrschaft übernommen und stattdessen hat sich ausgerechnet JavaScript von einer Spielerei zur wichtigsten Programmiersprache der Welt verwandelt. Aufgrund des Namens-Deals, den Netscape seinerzeit mit dem Java-Entwickler Sun Microsystems eingefädelt hatte, liegen die Namensrechte heutzutage beim momentanen Sun-Besitzer Oracle, während die Spezifikationen der Sprache von einer privaten Normierungsorganisation namens Ecma International (ehemals ECMA – European Computer Manufacturers Association) gepflegt werden. Das, was wir alle als JavaScript kennen und bezeichnen, ist also eine Implementierung eines Standards namens ECMAScript bzw. ECMA-262.
Die letzte von allen heute verbreiteten Browsern unterstützte Fassung des Standards ist die dritte Edition von ECMA-262, die im November 2000 verabschiedet wurde. Die Pläne zu einer vierten Edition zerschellten unvollendet an ihren eigenen Ansprüchen – man wollte zu viel, konnte sich nicht einigen und stellte schließlich die Arbeit an der vierten Edition ein. So kam es, dass jetzt mit der fünften Fassung ein vergleichsweise bescheidenes Update im Anflug ist, ohne dass es je eine vierte gegeben hätte. Erklärtes Ziel von ECMAScript 5: die Sprache entrümpeln und robuster machen, damit man in Zukunft ein gutes Fundament für dann wieder hochtrabendere Pläne hat.
Was kann die neue Version?
Dafür, dass Brendan Eich nur wenige Tage Zeit hatte um JavaScript zu entwickeln und nebenbei unter enormem Druck aus der Netscape-Führungsetage stand, kann sich das Ergebnis sehen lassen.
I had to be done in ten days or something worse than JS would have happened.
Doch trotzdem haben sich aufgrund der Kürze der Zeit einige sehr sonderbare Eigenschaften in die Sprache eingeschlichen. Eine kleine Auswahl mit Beispielen, die sicher die meisten von uns kennen:
// Ergibt "object" statt "array"
typeof [];
// "bar" wird eine _globale_ Variable, weil das "var" vergessen wurde
function foo(){
bar = 42;
}
// Ergibt "8"
parseInt('010');
Zwar hat jede Programmiersprache so ihre Macken, doch nur bei wenigen füllen die WTF-Momente ganze Websites und sogar Bücher. Oberstes Ziel von ES5 ist es, die Anzahl der genannten WTF-Momente zu reduzieren. Außerdem soll die Rubustheit von JavaScript erhöht werden – die Zeiten, als jedes Objekt jederzeit manipuliert werden konnte, sind vorbei. Und auch das Webentwickler-Leben soll durch eine Handvoll neuer Helferlein erleichtert werden. Im Einzelnen sind dabei:
- Scripte und Teile von Scripts können in einen Strict Mode versetzt werden, in dem einige defekte JS-Altlasten (z.B. with(){}) nicht mehr verwendet werden können und der an einigen Stellen die Regeln von JavaScript so verändert, dass es weniger WTF-Momente gibt.
- Mittel und Wege, um Objekte gegen Manipulationen zu sichern werden ebenso eingeführt wie Getter- und Setter-Methoden für Objekteigenschaften
- Viele neue Helferlein lösen ganz alltägliche Probleme und reduzieren den Bedarf an kryptischen Eigenbau-Lösungen und Boilerplate-Code. Genannt seien unter anderem
Object.create()
(erstellt in einem Arbeitsschritt ein Objekt und legt seinen Prototyp fest),Array.isArray()
undArray.prototype.forEach()
Einige dieser Features werden von heutigen JavaScript-Frameworks bereits bereitgestellt, so dass man sich durchaus fragen kann, ob ES5 einen überhaupt kümmern sollte.
Muss mich als jQuery-Nutzer ES5 überhaupt interessieren?
Wer wirklich niemals mehr macht, als via Framework ein paar DOM-Knoten durch die Gegend zu schrieben, kommt vermutlich die nächste Zeit auch ohne detaillierte Kenntnisse der meisten ES5-Features über die Runden. Einiges anderes, wie zum Beispiel die durchaus vorhandenen Gefahren des Strict Mode, sollte man aber in jedem Fall auf dem Schirm haben. Und schließlich gilt: die neuen Features einer Programmiersprache aus einer informierten Perspektive heraus zu ignorieren ist immer besser, als sie aus Gründen der Ignoranz nicht zu verwenden. Ebenfalls zu bedenken ist, dass JavaScript auch außerhalb des Browser mehr und mehr um sich greift. Egal ob Node.js oder Windows-Widgets, so manche Offline-Anwendung ist bereits heute in JS geschrieben. Und es ist nicht damit zu rechnen, dass sich dieser Trend so bald umkehrt – vor allem nicht, wenn die Sprache durch frische Features immer attraktiver wird.
Welche Browser unterstützen ES5 und wie geht es weiter?
JavaScript hat wie jede Browsertechnologie das Problem, dass man nicht einfach so eine neue Version rausbringen kann, die dann innerhalb kürzester Zeit überall verfügbar ist. Allerdings ist bei ES5 die Lage nicht ganz schlimm, wie man dieser Kompatibilitätstabelle entnehmen kann. Der Internet Explorer 8 ist, wie zu erwarten war, der Internet Explorer 6 von ES5, aber alle anderen Browser enthalten schon viele ES5-Features. Insbesondere bei Chrome, Firefox ab Version 4 und Internet Explorer ab Version 9 kann man von sehr guter Unterstützung sprechen. Die Lage stellt sich also rosig genug dar, um eine kleine Artikelserie zu rechtfertigen. Sofern sich genügend freie Zeit auftreiben lässt, werden es in den nächsten Wochen und Tagen noch vier weitere Artikel zum Thema ES5 erscheinen, die Einzelaspekte unter die Lupe nehmen. Wenn alles nach Plan läuft, werden wir in ein paar Tagen als erstes den Strict Mode behandeln – Feedback und Sonderwünsche sind dabei wie immer gern gesehen!
Kommentare (8)
Ole ¶
5. April 2011, 09:30 Uhr
Hallo Peter,
Da machst du einem ja richtig lust auf mehr. Also bitte bitte mehr Artikel zu ES5 :)
Ben ¶
5. April 2011, 14:04 Uhr
Klingt alles sehr interessant. Freue mich auch auf die weiteren Artikel!
fwolf ¶
5. April 2011, 14:38 Uhr
Dreamweaver + Co. verwenden für ihre "Erweiterungen" ja auch schon seit Jahren ECMAScript. AFAIR ist ActionScript ebenfalls nur eine Untermenge davon. Somit ist das Thema durchaus akut .. wohin sich diese Sprache entwickelt.
cu, w0lf.
Nico ¶
5. April 2011, 14:39 Uhr
Ich frage mich allerdings warum man sich überhaupt noch mit so vielen Altlasten herumschlägt. Der Übergang von ActionScript 2 zu ActionScript 3 (beides ebenfalls ECMAScript-Varianten und deswegen für mich das beste Beispiel) in der Flash-Entwicklung war ein tiefer Einschnitt, aber gleichfalls ein Segen für jeden, der sich ernsthaft damit auseinander gesetzt hat.
Wenn ECMAScript 5 kommt, warum setzt man dann nicht ebenfalls einen harten Schnitt an und konzipiert die Sprache von Grund auf neu und versucht nicht nur die alten Löcher zu stopfen?
Peter ¶
5. April 2011, 14:47 Uhr
Zitat Nico:
Genau das hat man versucht. Das war die im Artikel erwähnte vierte Edition von ECMAScript, die an ihren eigenen Ambitionen gescheitert ist. Das Ganze ging schief, weil man eben beim Basis-Standard ECMAScript viele verschiedene Player (v.A. Browserhersteller) am einem Tisch hat, die nicht alle das exakt gleiche wollen. Bei ActionScript kann hingegen eine Firma allein diktieren wohin die Reise gehen soll. So entwickelt es sich natürlich leichter, aber das kann man wirklich nicht vergleichen.
Nico ¶
5. April 2011, 15:04 Uhr
Zitat Peter:
Die Frage für mich ist hier halt: Wird sich ein so minimales Update durchsetzen? Inzwischen sind wir mit unseren ganzen Frameworks so weit, dass wir Javascript mit all seinen Schwächen ganz gut nutzen können. Wenn die Änderungen nur minimal sind könnte der Druck zu wechseln auch nur minimal sein. Ich befürchte sogar schon, dass es auch hier an der Umsetzung durch die Browserhersteller scheitern wird, denen diese minimale Änderung eines bestehenden Systems zu viel extra Aufwand bedeutet.
Peter ¶
5. April 2011, 15:49 Uhr
Zitat Nico:
Klar sind Frameworks toll, aber „ganz gut nutzen“ reicht nicht. Frameworks können nicht verhindern, dass Anfänger in Fallen tappen, die die Programmiersprache selbst enthält. Und nur mit Frameworks kann man Dinge wie den Strict Mode oder Property Descriptors nicht umsetzen. Da muss man an den Kern ran – und sobald das Fundament tragfähig ist, kann man dann auch größere Brötchen backen bzw. es wird ja wird ja bereits gebacken. Guckst du hier.
Zitat Nico:
Das wird kein Problem sein, alle Browserhersteller implementieren ES5 bereits in großem Umfang in den aktuellen Versionen ihrer Produkte.
molily ¶
6. April 2011, 15:35 Uhr
»Wenn ECMAScript 5 kommt, warum setzt man dann nicht ebenfalls einen harten Schnitt an und konzipiert die Sprache von Grund auf neu und versucht nicht nur die alten Löcher zu stopfen?«
Weil der die Sprache aus Sicht der Macher nicht von Grund auf fehlerhaft ist. Man stopft nicht alte Löcher, sondern verbessert das Gute und schaltet das Problematische langsam ab. Man will nicht wie AS3 plötzlich auf eine statisch getypte, klassenbasierte Sprache wechseln, damit so etwas wie Flash Builder möglich ist. JavaScript soll nicht Java werden.
Außerdem wird ECMAScript Harmony ja ein großer Einschnitt werden. Bei Harmony werden die Syntaxunterschiede voraussichtlich so groß sein, dass Scriptautoren die Version im script-Element angeben müssen, da der Code nicht abwärtskompatibel zu ES3/ES5-Interpretern sein kann.
»Inzwischen sind wir mit unseren ganzen Frameworks so weit, dass wir Javascript mit all seinen Schwächen ganz gut nutzen können.«
Frameworks ändern an den Schwächen von JavaScript als Sprache nichts. Sie ändern etwas an den Schwächen der Browser, des DOMs und nicht zuletzt der Webentwickler.
JavaScript ganz gut nutzen kann man, wenn man ECMAScript gut versteht, also die Sprachgrundlagen. Frameworks mit ihren Abstraktionen helfen einem dabei nur wenig weiter. Man kann auch und gerade mit jQuery Code schreiben, der bloß von Unverständnis von ECMAScript, DOM/BOM und anderen APIs zeugt. (Und trotzdem halbwegs funktioniert.)
»Wenn die Änderungen nur minimal sind könnte der Druck zu wechseln auch nur minimal sein.«
Der Druck in der JavaScript-Entwicklung ist sehr groß, denn guter JavaScript-Code ist schwer zu schreiben. Deswegen sind Coding-Standards und entsprechende Tools wie JSLint so wichtig. ES5 soll die Qualität und Zuverlässigkeit erhöhen, indem es bessere Kapselung erlaubt, den Strict Mode einführt und viele Helfermethoden standardisiert. Das sieht nach außen hin wie ein minimales Update aus. Für JavaScript-Entwickler ist es ein wirklicher Segen.
Die neuen Features zielen insofern weniger auf diejenigen, die ein bisschen DOM-Scripting mit jQuery machen und ihre Aufgaben durch fertige jQuery-Plugins lösen, sondern auf die Entwicklung größerer JavaScript-Anwendungen. Was mit JavaScript schon seit Jahren gemacht wird: Webanwendungen mit »Ajax«, »HTML5«, node.js und dergleichen.