La storia di JavaScript: ECMAScript, TC39 e oltre

JavaScript è un linguaggio vivente che aggiunge costantemente nuove funzionalità. Quello che voglio fare in questo post è abbattere quel processo e mostrare i passaggi necessari affinché una nuova funzionalità passi da un'idea semplice a una parte delle specifiche ufficiali. Per fare ciò, dovremo coprire tre cose: ECMA, ECMAScript e TC39.

Tieni presente che ho anche registrato una versione video di questo articolo, se preferisci guardarlo:

Torniamo al 1995. Il classico cult Heavy Weights era nei cinema, Nicolas Cage ha vinto un Oscar e i siti web hanno assomigliato a questo. Ora, le probabilità sono come hai visto questo sito Web con Netscape Navigator.

All'epoca, Netscape Navigator era il browser Web più popolare con una quota di mercato di quasi l'80%. Il fondatore di Netscape, la compagnia dietro Netscape Navigator, era Mark Andreessen. Aveva una visione per il futuro del web ed era molto più che un modo per condividere e distribuire documenti. Ha immaginato una piattaforma più dinamica con l'interattività lato client - una sorta di "lingua colla" che era facile da usare sia per i progettisti che per gli sviluppatori.

È qui che entra in scena Brendan Eich. È stato reclutato da Netscape con l'obiettivo di incorporare il linguaggio di programmazione Scheme in Netscape Navigator. Ma prima che potesse iniziare, Netscape ha collaborato con Sun Microsystems per rendere disponibile il proprio linguaggio di programmazione Java nel browser. Ora questo fa sorgere la domanda: "Se Java era già un linguaggio adatto, perché portare Brendan a crearne un altro?".

Bene, se ricordi di tornare all'obiettivo di Netscape, volevano un linguaggio di scripting abbastanza semplice da usare per designer e dilettanti: Java non era quello. Quindi l'idea è diventata che Java potesse essere utilizzato da professionisti e "Mocha", che era il nome iniziale di JavaScript, sarebbe stato utilizzato da tutti gli altri.

A causa di questa collaborazione tra le lingue, Netscape decise che Mocha doveva complimentarsi con Java e che avrebbe dovuto avere una sintassi relativamente simile. Quindi, in soli 10 giorni, Brendan ha creato la prima versione di Mocha che aveva ancora alcune funzionalità da Scheme, l'orientamento agli oggetti di SmallTalk e la sintassi di Java. Alla fine il nome Mocha cambiò in LiveScript e poi LiveScript cambiò in JavaScript come stratagemma di marketing per cavalcare l'hype di Java. Quindi, a questo punto, JavaScript è stato commercializzato come linguaggio di scripting per il browser, accessibile sia ai dilettanti che ai designer, mentre Java era lo strumento professionale per la creazione di ricchi componenti web.

Ora, è importante capire il contesto in cui si stavano verificando questi eventi. Oltre a Nicolas Cage che ha vinto un Oscar, Microsoft stava lavorando anche su Internet Explorer. Poiché JavaScript ha sostanzialmente cambiato l'esperienza utente del Web, se eri un browser concorrente non avevi altra scelta che inventare la tua implementazione JavaScript poiché non era ancora standardizzata. Quindi, questo è esattamente ciò che Microsoft ha fatto e lo hanno chiamato JScript.

Ciò ha portato a un problema piuttosto famoso nella storia di Internet. JScript ha riempito lo stesso caso d'uso di JavaScript, ma la sua implementazione era diversa. Ciò significa che non è stato possibile creare un sito Web e aspettarsi che funzioni sia su Internet Explorer sia su Nestscape Navigator. In effetti, le due implementazioni erano così diverse che i loghi "I migliori in Netscape" e "I migliori in Internet Explorer" divennero comuni per la maggior parte delle aziende che non potevano permettersi di costruire per entrambe le implementazioni.

È qui che entra in scena Ecma. Ecma International è "un'associazione industriale fondata nel 1961, dedicata alla standardizzazione dei sistemi di informazione e comunicazione". Nel novembre del 1996, Netscape ha inviato JavaScript a Ecma per elaborare una specifica standard.

In questo modo ha dato agli altri implementatori voce nell'evoluzione del linguaggio e, idealmente, avrebbe mantenuto coerenti le altre implementazioni tra i browser. Quindi tuffiamoci nel modo in cui funziona Ecma.

Ogni nuova specifica viene fornita con uno standard e un comitato. Nel caso di JavaScript, lo standard è ECMA-262 e il comitato che lavora sullo standard ECMA-262 è il TC39. Se cerchi lo standard ECMA262, noterai che il termine "JavaScript" non viene mai utilizzato. Invece, usano il termine "EcmaScript" per parlare della lingua ufficiale. Il motivo è che Oracle possiede il marchio commerciale per il termine "JavaScript", quindi per evitare problemi legali, Ecma ha usato invece il termine EcmaScript.

Nel mondo reale, ECMAScript viene solitamente utilizzato per fare riferimento allo standard ufficiale, EMCA-262, mentre JavaScript viene utilizzato quando si parla della lingua in pratica. Come accennato in precedenza, il comitato che sovrintende all'evoluzione dello standard Ecma262 è il TC39, che sta per Comitato tecnico 39.

Il TC39 è composto da "membri" che sono in genere venditori di browser e grandi aziende che hanno investito molto nel Web come Facebook e PayPal. Per partecipare alle riunioni, "membri" (di nuovo, grandi aziende e fornitori di browser) invieranno "delegati" per rappresentare detta società o browser. Sono questi delegati che sono responsabili della creazione, dell'approvazione o del rifiuto delle proposte linguistiche.

Quando viene creata una nuova proposta, tale proposta deve superare determinate fasi prima che diventi parte delle specifiche ufficiali. È importante tenere presente che, affinché qualsiasi proposta passi da una fase all'altra, deve essere raggiunto un consenso tra il TC39. Ciò significa che una grande maggioranza deve essere d'accordo, mentre nessuno è abbastanza in disaccordo per porre il veto a una proposta specifica.

Ogni nuova proposta inizia nella fase 0. Questa fase è chiamata fase Strawman. Le proposte della fase 0 sono "proposte che devono essere presentate alla commissione da un campione del TC39 o che sono state presentate alla commissione e non sono state definitivamente respinte, ma non hanno ancora raggiunto nessuno dei criteri per accedere alla fase 1". l'unico requisito per diventare una proposta Stage 0 è che il documento deve essere rivisto in una riunione del TC39. È importante notare che l'utilizzo di una funzionalità Stage 0 nella tua base di codice va bene, ma anche se continua a far parte delle specifiche ufficiali, quasi sicuramente passerà attraverso alcune iterazioni prima di allora.

La fase successiva nella maturità di una nuova proposta è la Fase 1. Per passare alla Fase 1, è necessario identificare un "campione" ufficiale che fa parte del TC39 ed è responsabile della proposta. Inoltre, la proposta deve descrivere il problema che risolve, disporre di esempi illustrativi di utilizzo, un'API di alto livello e identificare eventuali dubbi e sfide di implementazione. Accettando una proposta per la fase 1, il comitato segnala che sono disposti a spendere risorse per esaminare la proposta in modo più approfondito.

La fase successiva è la Fase 2. A questo punto, è più che probabile che questa funzione diventerà parte delle specifiche ufficiali. Per passare alla fase 2, la proposta deve, in un linguaggio formale, avere una descrizione della sintassi e della semantica della nuova funzionalità. In altre parole, viene scritta una bozza o una prima versione di ciò che sarà nelle specifiche ufficiali. Questo è il palcoscenico per bloccare davvero tutti gli aspetti della funzione. Probabilmente potrebbero ancora verificarsi cambiamenti futuri, ma dovrebbero essere solo cambiamenti minori e incrementali.

Il prossimo è la fase 3. A questo punto la proposta è per lo più terminata e ora ha solo bisogno di feedback da parte degli implementatori e degli utenti per progredire ulteriormente. Per passare alla fase 3, il testo delle specifiche deve essere completato e devono essere create almeno due implementazioni conformi alle specifiche.

L'ultima fase è la fase 4. A questo punto, la proposta è pronta per essere inclusa nelle specifiche ufficiali. Per arrivare alla fase 4, i test devono essere scritti, due implementazioni conformi alle specifiche devono superare tali test, i membri devono avere una significativa esperienza pratica con la nuova funzionalità e l'editor di specifiche EcmaScript deve firmare sul testo delle specifiche. Fondamentalmente una volta che una proposta arriva alla fase 4, è pronta a smettere di essere una proposta e farsi strada nelle specifiche ufficiali. Questo fa apparire l'ultima cosa che devi sapere sull'intero processo e che è il programma di rilascio di TC39.

A partire dal 2016, ogni anno viene rilasciata una nuova versione di ECMAScript con le funzionalità disponibili in quel momento. Ciò significa che qualsiasi proposta Stage 4 esistente quando si verifica una nuova versione, verrà inclusa nella versione per quell'anno. A causa di questo ciclo di rilascio annuale, le nuove funzionalità dovrebbero essere molto più incrementali e più facili da adottare.

Questo fa parte del mio corso "Modern JavaScript" di tylermcginnis.com.