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 für eine neue Funktion erforderlich sind, um von einer einfachen Idee zu einem Teil der offiziellen Spezifikation zu gelangen. Dazu müssen wir drei Dinge abdecken: ECMA, ECMAScript und TC39.

Beachten Sie, dass ich auch eine Videoversion dieses Artikels aufgenommen habe, wenn Sie dies bevorzugen:

Kehren wir zurück zu 1995. Der Kultklassiker Heavy Weights war in den Kinos zu sehen, Nicolas Cage gewann einen Oscar, und Websites sahen ungefähr so ​​aus. Nun, die Chancen stehen so, wie Sie diese Website mit Netscape Navigator gesehen haben.

Zu dieser Zeit war Netscape Navigator mit einem Marktanteil von fast 80% der beliebteste Webbrowser. Der Gründer von Netscape, der Firma 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 verbreiten. Er stellte sich eine dynamischere Plattform mit clientseitiger Interaktivität vor - eine Art „Klebesprache“, die sowohl von Designern als auch 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 sollte Brendan dann eine neue Sprache erstellen?“.

Wenn Sie sich an das Ziel von Netscape erinnern, wollten sie eine Skriptsprache, die für Designer und Amateure einfach genug war - 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 und eine relativ ähnliche Syntax haben sollte. In nur 10 Tagen erstellte Brendan die erste Version von Mocha, die noch einige Funktionen aus Schema, der Objektorientierung von SmallTalk und der Syntax von Java enthielt. Irgendwann änderte sich der Name Mocha in LiveScript und dann in JavaScript als Marketing-Trick, um dem Hype um Java zu trotzen. Zu diesem Zeitpunkt wurde JavaScript als Skriptsprache für den Browser vermarktet - sowohl für Amateure als auch für Designer, 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 Benutzerfreundlichkeit des Webs grundlegend verändert hat, blieb Ihnen 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 bekannten Problem in der Geschichte des Internets. JScript erfüllte den gleichen Anwendungsfall wie JavaScript, die Implementierung war jedoch unterschiedlich. Dies bedeutete, dass Sie keine einzige Website erstellen konnten und erwarteten, dass diese sowohl mit Internet Explorer als auch mit 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 Industrieverband, der 1961 gegründet wurde und sich der Standardisierung von Informations- und Kommunikationssystemen widmet.“ Im November 1996 reichte Netscape JavaScript bei Ecma ein, um eine Standardspezifikation zu erstellen.

Auf diese Weise konnten andere Implementierer die Entwicklung der Sprache mitverfolgen und andere Implementierungen im Idealfall über alle Browser hinweg konsistent halten. Lassen Sie uns untersuchen, wie Ecma funktioniert.

Jede neue Spezifikation enthält eine Norm und ein Komitee. Im Falle 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 Amtssprache zu sprechen. Der Grund dafür ist, dass Oracle das Warenzeichen für den Begriff "JavaScript" besitzt. Um rechtliche Probleme zu vermeiden, verwendete Ecma stattdessen den Begriff "EcmaScript".

In der Praxis 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 TC39, der für Technical Committee 39 steht, das Komitee, das die Entwicklung des Ecma262-Standards überwacht.

Das TC39 setzt sich aus Mitgliedern zusammen, die normalerweise Browser-Anbieter und große Unternehmen sind, die stark in das Internet investiert haben, wie Facebook und PayPal. Um an den Meetings teilzunehmen, werden "Mitglieder" (wiederum große Unternehmen und Browser-Anbieter) "Delegierte" entsenden, 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 unter den TC39 erreicht 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 widerspricht, um ein Veto gegen einen bestimmten Vorschlag einzulegen.

Jeder neue Vorschlag beginnt in Phase 0. Diese Phase wird als Strawman-Phase 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 die Stufe 1 erfüllt haben." Die einzige Voraussetzung, um ein Vorschlag der Stufe 0 zu werden, ist, dass das Dokument auf einer TC39-Sitzung überprüft wird. 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 bis dahin mit ziemlicher Sicherheit einige Iterationen durchlaufen.

Die nächste Stufe in der Reife eines neuen Vorschlags ist Stufe 1. Um zur Stufe 1 zu gelangen, muss ein offizieller „Champion“, der Teil von TC39 ist, identifiziert werden und für den Vorschlag verantwortlich sein. Darüber hinaus muss der Vorschlag das von ihm gelöste Problem beschreiben, veranschaulichende Verwendungsbeispiele sowie eine API auf hoher Ebene enthalten und potenzielle Bedenken und Herausforderungen bei der Implementierung aufzeigen. Mit der Annahme eines Vorschlags für Stufe 1 signalisiert der Ausschuss, dass er bereit ist, Ressourcen für eine eingehendere Prüfung des Vorschlags aufzuwenden.

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 der Semantik des neuen Features enthalten. Mit anderen Worten, es wird ein Entwurf oder eine erste Version der offiziellen Spezifikation 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 folgt Phase 3. Zu diesem Zeitpunkt ist der Vorschlag größtenteils fertig und es ist nur noch ein Feedback von Implementierern und Benutzern erforderlich, um weitere Fortschritte zu erzielen. Um mit Stufe 3 fortzufahren, muss der Spezifikationstext fertiggestellt und mindestens zwei spezifikationskonforme Implementierungen erstellt werden.

Die letzte Stufe ist Stufe 4. Zu diesem Zeitpunkt kann der Vorschlag in die offizielle Spezifikation aufgenommen werden. Um zu Stufe 4 zu gelangen, müssen Tests geschrieben werden, zwei spezifikationskonforme Implementierungen sollten diese Tests bestehen, Mitglieder sollten über umfangreiche praktische Erfahrung mit der neuen Funktion verfügen, und der EcmaScript-Spezifikationseditor muss den Spezifikationstext abmelden. Sobald ein Vorschlag die Stufe 4 erreicht hat, kann er aufhören, ein Vorschlag zu sein, und in die offizielle Spezifikation aufgenommen werden. Das letzte, was Sie über diesen gesamten Prozess wissen müssen, ist der Release-Zeitplan für TC39.

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

Dies ist Teil meines tylermcginnis.com "Modern JavaScript" -Kurses.