3 Geschichte und Entwicklung von JavaScript

---

---

3.1 Wie JavaScript entstanden ist

JavaScript wurde im Mai 1995 in 10 Tagen von Brendan Eich entwickelt. Eich arbeitete bei Netscape und implementierte JavaScript für deren Webbrowser, Netscape Navigator.

Die Idee war, dass die wichtigsten interaktiven Teile auf der Client-Seite in Java implementiert werden sollten. JavaScript sollte eine Skriptsprache sein, um diese Teile zu verbinden und HTML etwas interaktiver zu gestalten. Angesichts seiner Rolle als Unterstützung für Java musste JavaScript wie Java aussehen. Das schloss bestehende Lösungen wie Perl, Python, TCL und andere aus.

Anfänglich änderte sich der Name von JavaScript mehrmals

• Sein Codename war Mocha.
• In den Betas von Netscape Navigator 2.0 (September 1995) hieß es LiveScript.
• In Netscape Navigator 2.0 Beta 3 (Dezember 1995) erhielt es seinen endgültigen Namen, JavaScript.

3.2 Standardisierung von JavaScript

Es gibt zwei Standards für JavaScript

• ECMA-262 wird von Ecma International gehostet. Es ist der primäre Standard.
• ISO/IEC 16262 wird von der International Organization for Standardization (ISO) und der International Electrotechnical Commission (IEC) gehostet. Dies ist ein sekundärer Standard.

Die Sprache, die von diesen Standards beschrieben wird, heißt ECMAScript, nicht JavaScript. Ein anderer Name wurde gewählt, da Sun (jetzt Oracle) eine Marke für den letzteren Namen hatte. Das "ECMA" in "ECMAScript" stammt von der Organisation, die den primären Standard hostet.

Der ursprüngliche Name dieser Organisation war ECMA, ein Akronym für European Computer Manufacturers Association. Später wurde er in Ecma International geändert (wobei "Ecma" ein Eigenname und kein Akronym ist), da sich die Aktivitäten der Organisation über Europa hinaus erweitert hatten. Das anfängliche Akronym in Großbuchstaben erklärt die Schreibweise von ECMAScript.

Grundsätzlich bedeuten JavaScript und ECMAScript dasselbe. Manchmal wird folgende Unterscheidung getroffen

• Der Begriff JavaScript bezieht sich auf die Sprache und ihre Implementierungen.
• Der Begriff ECMAScript bezieht sich auf den Sprachstandard und die Sprachversionen.

Daher ist ECMAScript 6 eine Version der Sprache (ihre 6. Ausgabe).

3.3 Zeitleiste der ECMAScript-Versionen

Dies ist eine kurze Zeitleiste der ECMAScript-Versionen

• ECMAScript 1 (Juni 1997): Erste Version des Standards.
• ECMAScript 2 (Juni 1998): Kleine Aktualisierung, um ECMA-262 mit dem ISO-Standard synchron zu halten.
• ECMAScript 3 (Dezember 1999): Fügt viele Kernfunktionen hinzu – „[…] reguläre Ausdrücke, bessere Zeichenkettenbehandlung, neue Kontrollanweisungen [do-while, switch], try/catch-Fehlerbehandlung, […]“
• ECMAScript 4 (eingestellt im Juli 2008): Wäre ein massives Upgrade gewesen (mit statischer Typisierung, Modulen, Namespaces und mehr), endete aber damit, zu ambitioniert zu sein und die Betreuer der Sprache zu spalten.
• ECMAScript 5 (Dezember 2009):brachte kleinere Verbesserungen – einige Standardbibliotheksfunktionen und Strict Mode.
• ECMAScript 5.1 (Juni 2011): Eine weitere kleine Aktualisierung, um die Ecma- und ISO-Standards synchron zu halten.
• ECMAScript 6 (Juni 2015): Ein großes Update, das viele Versprechungen von ECMAScript 4 erfüllte. Diese Version ist die erste, deren offizieller Name – ECMAScript 2015 – auf dem Veröffentlichungsjahr basiert.
• ECMAScript 2016 (Juni 2016): Erste jährliche Veröffentlichung. Der kürzere Veröffentlichungszyklus führte zu weniger neuen Features im Vergleich zum großen ES6.
• ECMAScript 2017 (Juni 2017). Zweite jährliche Veröffentlichung.
• Nachfolgende ECMAScript-Versionen (ES2018 usw.) werden immer im Juni ratifiziert.

3.4 Ecma Technical Committee 39 (TC39)

TC39 ist das Komitee, das JavaScript weiterentwickelt. Seine Mitglieder sind streng genommen Unternehmen: Adobe, Apple, Facebook, Google, Microsoft, Mozilla, Opera, Twitter und andere. Das heißt, Unternehmen, die normalerweise erbitterte Konkurrenten sind, arbeiten zum Wohle der Sprache zusammen.

Alle zwei Monate finden TC39-Treffen statt, an denen von Mitgliedern ernannte Delegierte und eingeladene Experten teilnehmen. Die Protokolle dieser Treffen sind öffentlich in einem GitHub-Repository.

3.5 Der TC39-Prozess

Mit ECMAScript 6 wurden zwei Probleme mit dem damals verwendeten Veröffentlichungsprozess offensichtlich

• Wenn zu viel Zeit zwischen den Veröffentlichungen vergeht, müssen Features, die frühzeitig fertig sind, lange warten, bis sie veröffentlicht werden können. Und Features, die spät fertig sind, riskieren, überstürzt zu werden, um die Frist einzuhalten.

• Features wurden oft lange vor ihrer Implementierung und Nutzung entworfen. Designmängel im Zusammenhang mit Implementierung und Nutzung wurden daher zu spät entdeckt.

Als Reaktion auf diese Probleme führte TC39 den neuen TC39-Prozess ein

• ECMAScript-Features werden unabhängig voneinander entworfen und durchlaufen Stufen, beginnend bei 0 („Strohmann“), endend bei 4 („fertig“).
• Insbesondere die späteren Stufen erfordern Prototyp-Implementierungen und reale Tests, was zu Feedbackschleifen zwischen Entwürfen und Implementierungen führt.
• ECMAScript-Versionen werden einmal pro Jahr veröffentlicht und enthalten alle Features, die vor einer Veröffentlichungsfrist Stufe 4 erreicht haben.

Das Ergebnis: kleinere, inkrementelle Veröffentlichungen, deren Features bereits im Feld getestet wurden. Abb. 1 veranschaulicht den TC39-Prozess.

ES2016 war die erste ECMAScript-Version, die nach dem TC39-Prozess entwickelt wurde.

3.5.1 Tipp: Denken Sie in einzelnen Features und Stufen, nicht in ECMAScript-Versionen

Bis einschließlich ES6 war es am gebräuchlichsten, über JavaScript in Bezug auf ECMAScript-Versionen nachzudenken – zum Beispiel: „Unterstützt dieser Browser ES6 schon?“

Ab ES2016 ist es besser, in einzelnen Features zu denken: Sobald ein Feature Stufe 4 erreicht hat, können Sie es sicher verwenden (sofern es von den von Ihnen anvisierten JavaScript-Engines unterstützt wird). Sie müssen nicht auf die nächste ECMAScript-Veröffentlichung warten.

3.6 FAQ: TC39-Prozess

3.6.1 Wie läuft es mit [meinem Lieblingsvorschlag für ein Feature]?

Wenn Sie sich fragen, in welchen Stufen sich verschiedene vorgeschlagene Features befinden, konsultieren Sie das GitHub-Repository proposals.

3.6.2 Gibt es eine offizielle Liste der ECMAScript-Features?

Ja, das TC39-Repo listet fertige Vorschläge auf und gibt an, in welchen ECMAScript-Versionen sie eingeführt wurden.

3.7 JavaScript weiterentwickeln: Das Web nicht brechen

Eine Idee, die gelegentlich aufkommt, ist, JavaScript aufzuräumen, indem alte Features und Eigenheiten entfernt werden. Während die Attraktivität dieser Idee offensichtlich ist, hat sie erhebliche Nachteile.

Nehmen wir an, wir erstellen eine neue Version von JavaScript, die nicht abwärtskompatibel ist, und beheben alle ihre Fehler. Infolgedessen würden wir auf folgende Probleme stoßen

• JavaScript-Engines werden aufgebläht: Sie müssen sowohl die alte als auch die neue Version unterstützen. Das Gleiche gilt für Werkzeuge wie IDEs und Build-Tools.
• Programmierer müssen die Unterschiede zwischen den Versionen kennen und sich ständig bewusst sein.
• Sie können entweder eine bestehende Codebasis vollständig in die neue Version migrieren (was viel Arbeit sein kann) oder Sie mischen Versionen und die Refaktorierung wird schwieriger, da Sie Code nicht ohne Änderung zwischen Versionen verschieben können.
• Sie müssen irgendwie pro Codeabschnitt – sei es eine Datei oder in eine Webseite eingebetteter Code – angeben, in welcher Version er geschrieben ist. Jede erdenkliche Lösung hat Vor- und Nachteile. Zum Beispiel ist Strict Mode eine etwas sauberere Version von ES5. Einer der Gründe, warum er nicht so beliebt war, wie er hätte sein sollen: Es war mühsam, ihn über eine Direktive am Anfang einer Datei oder einer Funktion zu aktivieren.

Was ist also die Lösung? Können wir beides haben? Der für ES6 gewählte Ansatz heißt "One JavaScript"

• Neue Versionen sind immer vollständig abwärtskompatibel (es kann jedoch gelegentlich kleinere, kaum wahrnehmbare Bereinigungen geben).
• Alte Features werden nicht entfernt oder behoben. Stattdessen werden bessere Versionen davon eingeführt. Ein Beispiel ist die Deklaration von Variablen mit let – was eine verbesserte Version von var ist.
• Wenn Aspekte der Sprache geändert werden, geschieht dies innerhalb neuer syntaktischer Konstrukte. Das heißt, Sie stimmen implizit zu. Zum Beispiel ist yield nur ein Schlüsselwort in Generatoren (die in ES6 eingeführt wurden). Und aller Code innerhalb von Modulen und Klassen (beide in ES6 eingeführt) befindet sich implizit im Strict Mode.