Die Geschichte von JavaScript: ECMAScript, TC39 und darüber hinaus

JavaScript ist eine lebendige Sprache, die ständig neue Funktionen hinzufügt. In diesem Beitrag möchte ich diesen Prozess aufschlüsseln und die Schritte aufzeigen, die erforderlich sind, damit eine neue Funktion von einer einfachen Idee zu einem Teil der offiziellen Spezifikation übergeht. Dazu müssen wir drei Dinge behandeln: ECMA, ECMAScript und TC39.

Beachten Sie, dass ich auch eine Videoversion dieses Artikels aufgenommen habe, wenn Sie das lieber sehen möchten:

Lassen Sie uns zurück zu 1995 gehen. Der Kultklassiker Heavy Weights war in den Kinos, Nicolas Cage gewann einen Oscar und Websites sahen ungefähr so ​​aus. Die Chancen stehen gut, wie Sie diese Website mit Netscape Navigator angesehen haben.

Zu dieser Zeit war Netscape Navigator der beliebteste Webbrowser mit einem Marktanteil von fast 80%. Der Gründer von Netscape, dem Unternehmen hinter Netscape Navigator, war Mark Andreessen. Er hatte eine Vision für die Zukunft des Webs und es war mehr als nur eine Möglichkeit, Dokumente zu teilen und zu verteilen. Er stellte sich eine dynamischere Plattform mit clientseitiger Interaktivität vor - eine Art „Klebesprache“, die sowohl von Designern als auch von Entwicklern einfach zu verwenden war.

Hier kommt Brendan Eich ins Spiel. Er wurde von Netscape mit dem Ziel eingestellt, die Programmiersprache Scheme in Netscape Navigator einzubetten. Bevor er jedoch loslegen konnte, arbeitete Netscape mit Sun Microsystems zusammen, um die aufstrebende Programmiersprache Java im Browser verfügbar zu machen. Dies wirft nun die Frage auf: „Wenn Java bereits eine geeignete Sprache war, warum Brendan dazu bringen, eine andere zu erstellen?“.

Wenn Sie sich an das Ziel von Netscape erinnern, wollten sie eine Skriptsprache, die für Designer und Amateure einfach genug ist - Java war das nicht. So entstand die Idee, dass Java von Profis verwendet werden kann und „Mocha“, der ursprüngliche Name von JavaScript, von allen anderen verwendet wird.

Aufgrund dieser Zusammenarbeit zwischen Sprachen entschied Netscape, dass Mocha Java ergänzen muss und eine relativ ähnliche Syntax haben sollte. Dann erstellte Brendan in nur 10 Tagen die erste Version von Mocha, die noch einige Funktionen aus Scheme, der Objektorientierung von SmallTalk und der Syntax von Java enthielt. Schließlich wurde der Name Mocha in LiveScript geändert, und dann wurde LiveScript in JavaScript geändert, um den Hype um Java zu bewältigen. Zu diesem Zeitpunkt wurde JavaScript als Skriptsprache für den Browser vermarktet - sowohl für Amateure als auch für Designer zugänglich, während Java das professionelle Tool zum Erstellen umfangreicher Webkomponenten war.

Jetzt ist es wichtig, den Kontext zu verstehen, in dem diese Ereignisse stattfanden. Neben Nicolas Cage, der einen Oscar gewann, arbeitete Microsoft auch am Internet Explorer. Da JavaScript die Benutzererfahrung im Web grundlegend verändert hat, hatten Sie als konkurrierender Browser keine andere Wahl, als eine eigene JavaScript-Implementierung zu entwickeln, da diese noch nicht standardisiert war. Genau das hat Microsoft getan und sie haben es JScript genannt.

Dies führte zu einem ziemlich berühmten Problem in der Geschichte des Internets. JScript füllte den gleichen Anwendungsfall wie JavaScript, aber seine Implementierung war unterschiedlich. Dies bedeutete, dass Sie nicht eine Website erstellen konnten und davon ausgehen konnten, dass sie sowohl im Internet Explorer als auch im Nestscape Navigator funktioniert. Tatsächlich waren die beiden Implementierungen so unterschiedlich, dass die Logos "Am besten in Netscape angezeigt" und "Am besten in Internet Explorer angezeigt" für die meisten Unternehmen üblich wurden, die es sich nicht leisten konnten, für beide Implementierungen zu erstellen.

Hier kommt Ecma ins Spiel. Ecma International ist „ein 1961 gegründeter Branchenverband, der sich der Standardisierung von Informations- und Kommunikationssystemen widmet.“ Im November 1996 übermittelte Netscape Ecma JavaScript, um eine Standardspezifikation zu erstellen.

Auf diese Weise erhielten andere Implementierer eine Stimme in der Entwicklung der Sprache und im Idealfall würden andere Implementierungen über alle Browser hinweg konsistent bleiben. Lassen Sie uns untersuchen, wie Ecma funktioniert.

Jede neue Spezifikation enthält einen Standard und ein Komitee. Im Fall von JavaScript ist der Standard ECMA-262 und das Komitee, das am ECMA-262-Standard arbeitet, ist der TC39. Wenn Sie den ECMA262-Standard nachschlagen, werden Sie feststellen, dass der Begriff „JavaScript“ niemals verwendet wird. Stattdessen verwenden sie den Begriff „EcmaScript“, um über die offizielle Sprache zu sprechen. Der Grund dafür ist, dass Oracle die Marke für den Begriff „JavaScript“ besitzt. Um rechtliche Probleme zu vermeiden, verwendete Ecma stattdessen den Begriff EcmaScript.

In der realen Welt wird ECMAScript normalerweise verwendet, um auf den offiziellen Standard EMCA-262 zu verweisen, während JavaScript verwendet wird, wenn über die Sprache in der Praxis gesprochen wird. Wie bereits erwähnt, ist der Ausschuss, der die Entwicklung des Ecma262-Standards überwacht, der TC39, der für Technical Committee 39 steht.

Der TC39 besteht aus „Mitgliedern“, die in der Regel Browser-Anbieter sind, und großen Unternehmen, die stark in das Internet investiert haben, wie Facebook und PayPal. Um an den Besprechungen teilzunehmen, senden „Mitglieder“ (wiederum große Unternehmen und Browser-Anbieter) „Delegierte“, um das Unternehmen oder den Browser zu vertreten. Es sind diese Delegierten, die für das Erstellen, Genehmigen oder Ablehnen von Sprachvorschlägen verantwortlich sind.

Wenn ein neuer Vorschlag erstellt wird, muss dieser Vorschlag bestimmte Phasen durchlaufen, bevor er Teil der offiziellen Spezifikation wird. Es ist wichtig zu bedenken, dass ein Konsens zwischen den TC39 erzielt werden muss, damit ein Vorschlag von einer Stufe zur nächsten übergeht. Dies bedeutet, dass eine große Mehrheit zustimmen muss, während niemand stark genug anderer Meinung ist, um ein Veto gegen einen bestimmten Vorschlag einzulegen.

Jeder neue Vorschlag beginnt bei Stufe 0. Diese Stufe wird als Strawman-Stufe bezeichnet. Vorschläge der Stufe 0 sind „Vorschläge, die dem Komitee von einem TC39-Champion vorgelegt werden sollen oder die dem Komitee vorgelegt und nicht endgültig abgelehnt wurden, aber noch keines der Kriterien für den Eintritt in die Stufe 1 erfüllt haben.“ Die einzige Voraussetzung, um ein Vorschlag für Stufe 0 zu werden, besteht darin, dass das Dokument bei einem TC39-Meeting überprüft werden muss. Es ist wichtig zu beachten, dass die Verwendung einer Stage 0-Funktion in Ihrer Codebasis in Ordnung ist, aber selbst wenn sie weiterhin Teil der offiziellen Spezifikation wird, wird sie mit ziemlicher Sicherheit bis dahin einige Iterationen durchlaufen.

Die nächste Phase in der Reife eines neuen Vorschlags ist Phase 1. Um zur Phase 1 zu gelangen, muss ein offizieller „Champion“ identifiziert werden, der Teil von TC39 ist und für den Vorschlag verantwortlich ist. Darüber hinaus muss der Vorschlag das von ihm gelöste Problem beschreiben, anschauliche Anwendungsbeispiele und eine API auf hoher Ebene enthalten und potenzielle Bedenken und Implementierungsprobleme identifizieren. Durch die Annahme eines Vorschlags für Stufe 1 signalisiert das Komitee, dass es bereit ist, Ressourcen aufzuwenden, um den Vorschlag eingehender zu prüfen.

Die nächste Stufe ist Stufe 2. Zu diesem Zeitpunkt ist es mehr als wahrscheinlich, dass diese Funktion irgendwann Teil der offiziellen Spezifikation wird. Um die Stufe 2 zu erreichen, muss der Vorschlag in formaler Sprache eine Beschreibung der Syntax und Semantik des neuen Features enthalten. Mit anderen Worten, ein Entwurf oder eine erste Version dessen, was in der offiziellen Spezifikation enthalten sein wird, wird geschrieben. Dies ist die Bühne, um wirklich alle Aspekte der Funktion zu sperren. Zukünftige Änderungen können wahrscheinlich noch auftreten, sollten jedoch nur geringfügige, inkrementelle Änderungen sein.

Als nächstes steht Phase 3 an. Zu diesem Zeitpunkt ist der Vorschlag größtenteils fertig und benötigt nur noch Feedback von Implementierern und Benutzern, um weiter voranzukommen. Um zu Stufe 3 zu gelangen, sollte der Spezifikationstext fertig sein und mindestens zwei spezifikationskonforme Implementierungen müssen erstellt werden.

Die letzte Stufe ist Stufe 4. Zu diesem Zeitpunkt ist der Vorschlag bereit, in die offizielle Spezifikation aufgenommen zu werden. Um zu Stufe 4 zu gelangen, müssen Tests geschrieben werden, zwei spezifikationsgerechte Implementierungen sollten diese Tests bestehen, Mitglieder sollten über umfangreiche praktische Erfahrung mit der neuen Funktion verfügen und der EcmaScript-Spezifikationseditor muss den Spezifikationstext abzeichnen. Sobald ein Vorschlag die Stufe 4 erreicht hat, kann er im Grunde genommen aufhören, ein Vorschlag zu sein, und in die offizielle Spezifikation aufgenommen werden. Dies bringt das Letzte auf, was Sie über diesen gesamten Prozess wissen müssen, und das ist der Release-Zeitplan von TC39.

Ab 2016 wird jedes Jahr eine neue Version von ECMAScript mit allen zu diesem Zeitpunkt verfügbaren Funktionen veröffentlicht. Dies bedeutet, dass alle Vorschläge der Stufe 4, die zum Zeitpunkt der Veröffentlichung einer neuen Version vorliegen, in die Veröffentlichung für dieses Jahr aufgenommen werden. Aufgrund dieses jährlichen Veröffentlichungszyklus sollten neue Funktionen wesentlich inkrementeller und einfacher zu übernehmen sein.

Dies ist Teil meines tylermcginnis.com-Kurses „Modern JavaScript“.