Sejarah JavaScript: ECMAScript, TC39, dan selanjutnya

JavaScript adalah bahasa hidup yang terus-menerus menambahkan fitur baru. Apa yang ingin saya lakukan dalam posting ini adalah memecah proses itu dan menunjukkan langkah-langkah yang diperlukan untuk fitur baru untuk beralih dari ide sederhana menjadi bagian dari spesifikasi resmi. Untuk melakukan itu, kita perlu membahas tiga hal: ECMA, ECMAScript, dan TC39.

Perhatikan bahwa saya juga merekam versi video dari artikel ini, jika Anda lebih suka menontonnya:

Mari kita kembali ke tahun 1995. Berat Klasik kultus di bioskop, Nicolas Cage memenangkan Oscar, dan situs web terlihat seperti ini. Sekarang, kemungkinan Anda melihat situs web ini adalah dengan Netscape Navigator.

Pada saat itu, Netscape Navigator adalah browser web paling populer dengan pangsa pasar hampir 80%. Pendiri Netscape, perusahaan di belakang Netscape Navigator, adalah Mark Andreessen. Dia memiliki visi untuk masa depan web dan itu lebih dari sekadar cara untuk berbagi dan mendistribusikan dokumen. Dia membayangkan platform yang lebih dinamis dengan interaktivitas sisi klien - semacam "lem langauge" yang mudah digunakan oleh desainer dan pengembang.

Di sinilah Brendan Eich muncul. Dia direkrut oleh Netscape dengan tujuan menanamkan bahasa pemrograman Skema ke dalam Netscape Navigator. Tetapi sebelum dia bisa memulai, Netscape berkolaborasi dengan Sun Microsystems untuk membuat bahasa pemrograman Java yang akan datang dan tersedia di browser. Sekarang ini memunculkan pertanyaan, "Jika Jawa sudah bahasa yang cocok, mengapa membawa Brendan untuk membuat yang lain?".

Nah, jika Anda ingat kembali ke tujuan Netscape, mereka menginginkan bahasa skrip yang cukup sederhana untuk digunakan oleh desainer dan amatir - Java bukan itu. Jadi ide menjadi bahwa Java dapat digunakan oleh para profesional dan "Mocha", yang merupakan nama awal JavaScript, akan digunakan oleh semua orang.

Karena kolaborasi antar bahasa ini, Netscape memutuskan bahwa Mocha perlu memuji Java dan harus memiliki sintaks yang relatif sama. Kemudian, hanya dalam 10 hari, Brendan menciptakan Mocha versi pertama yang masih memiliki beberapa fungsionalitas dari Skema, orientasi objek SmallTalk, dan sintaksis Java. Akhirnya nama Mocha berubah menjadi LiveScript dan kemudian LiveScript berubah menjadi JavaScript sebagai taktik pemasaran untuk mengendarai hype Java. Jadi pada titik ini, JavaScript dipasarkan sebagai bahasa scripting untuk browser - dapat diakses oleh para amatir dan desainer sementara Java adalah alat profesional untuk membangun komponen web yang kaya.

Sekarang, penting untuk memahami konteks kapan peristiwa ini terjadi. Selain Nicolas Cage memenangkan Oscar, Microsoft juga bekerja di Internet Explorer. Karena JavaScript mengubah pengalaman pengguna web secara mendasar, jika Anda adalah browser yang bersaing, Anda tidak punya pilihan selain membuat implementasi JavaScript sendiri karena belum distandarisasi. Jadi, itulah yang dilakukan Microsoft dan mereka menyebutnya JScript.

Ini mengarah pada masalah yang cukup terkenal dalam sejarah internet. JScript mengisi use case yang sama dengan JavaScript, tetapi implementasinya berbeda. Ini berarti Anda tidak dapat membangun satu situs web dan mengharapkannya berfungsi di Internet Explorer dan Nestscape Navigator. Faktanya, kedua implementasi tersebut sangat berbeda sehingga logo “Best viewed in Netscape” dan “Best viewed in Internet Explorer” menjadi umum bagi sebagian besar perusahaan yang tidak mampu membangun untuk kedua implementasi tersebut.

Di sinilah Ecma muncul. Ecma International adalah "asosiasi industri yang didirikan pada tahun 1961, didedikasikan untuk standardisasi sistem informasi dan komunikasi." Pada bulan November 1996, Netscape mengirimkan JavaScript ke Ecma untuk membangun spesifikasi standar.

Dengan melakukan ini, ini memberi suara implementor lain dalam evolusi bahasa dan, idealnya, itu akan membuat implementasi lain konsisten di seluruh browser. Jadi mari selami bagaimana Ecma bekerja.

Setiap spesifikasi baru dilengkapi dengan standar dan komite. Dalam kasus JavaScript, standarnya adalah ECMA-262 dan komite yang bekerja pada standar ECMA-262 adalah TC39. Jika Anda mencari standar ECMA262, Anda akan melihat bahwa istilah "JavaScript" tidak pernah digunakan. Sebagai gantinya, mereka menggunakan istilah "EcmaScript" untuk berbicara tentang bahasa resmi. Alasannya adalah karena Oracle memiliki merek dagang untuk istilah "JavaScript", jadi untuk menghindari masalah hukum, Ecma menggunakan istilah EcmaScript sebagai gantinya.

Di dunia nyata, ECMAScript biasanya digunakan untuk merujuk pada standar resmi, EMCA-262, sedangkan JavaScript digunakan ketika berbicara tentang bahasa dalam praktik. Seperti yang disebutkan sebelumnya, komite yang mengawasi evolusi standar Ecma262 adalah TC39, yang merupakan singkatan dari Komite Teknis 39.

TC39 terdiri dari "anggota" yang biasanya vendor peramban dan perusahaan besar yang banyak berinvestasi di web seperti Facebook dan PayPal. Untuk menghadiri pertemuan, “anggota” (sekali lagi, perusahaan besar dan vendor browser) akan mengirim “delegasi” untuk mewakili perusahaan atau browser tersebut. Delegasi inilah yang bertanggung jawab untuk membuat, menyetujui, atau menolak proposal bahasa.

Ketika proposal baru dibuat, proposal itu harus melalui tahap-tahap tertentu sebelum menjadi bagian dari spesifikasi resmi. Penting untuk diingat bahwa agar setiap proposal berpindah dari satu tahap ke tahap lainnya, konsensus di antara TC39 harus dipenuhi. Ini berarti bahwa mayoritas besar harus setuju sementara tidak ada yang sangat tidak setuju untuk memveto proposal tertentu.

Setiap proposal baru dimulai pada Tahap 0. Tahap ini disebut tahap Strawman. Proposal Tahap 0 adalah “proposal yang direncanakan untuk dipresentasikan kepada komite oleh juara TC39 atau, telah diajukan kepada komite dan belum ditolak secara definitif, tetapi belum mencapai kriteria untuk masuk ke tahap 1.” Jadi, satu-satunya persyaratan untuk menjadi proposal Tahap 0 adalah bahwa dokumen tersebut harus ditinjau pada pertemuan TC39. Penting untuk dicatat bahwa menggunakan fitur Stage 0 di basis kode Anda baik-baik saja, tetapi bahkan jika itu terus menjadi bagian dari spesifikasi resmi, hampir pasti akan melewati beberapa iterasi sebelum itu.

Tahap berikutnya dalam kematangan proposal baru adalah Tahap 1. Untuk melanjutkan ke Tahap 1, "juara" resmi yang merupakan bagian dari TC39 harus diidentifikasi dan bertanggung jawab atas proposal tersebut. Selain itu, proposal perlu menjelaskan masalah yang dipecahkannya, memiliki contoh ilustrasi penggunaan, API tingkat tinggi, dan mengidentifikasi potensi kekhawatiran dan tantangan implementasi. Dengan menerima proposal untuk tahap 1, panitia mengisyaratkan mereka bersedia menghabiskan sumber daya untuk melihat proposal secara lebih mendalam.

Tahap selanjutnya adalah Tahap 2. Pada titik ini, kemungkinan besar fitur ini pada akhirnya akan menjadi bagian dari spesifikasi resmi. Untuk mencapai tahap 2, proposal harus, dalam bahasa formal, memiliki deskripsi sintaksis dan semantik fitur baru. Dengan kata lain, konsep, atau versi pertama dari apa yang akan ada dalam spesifikasi resmi ditulis. Ini adalah panggung untuk benar-benar mengunci semua aspek fitur. Perubahan di masa depan mungkin masih terjadi, tetapi itu hanya perubahan kecil dan inkremental.

Selanjutnya adalah Tahap 3. Pada saat ini proposal sebagian besar sudah selesai dan sekarang hanya perlu umpan balik dari implementor dan pengguna untuk kemajuan lebih lanjut. Untuk melanjutkan ke Tahap 3, teks spesifikasi harus diselesaikan dan setidaknya dua implementasi yang sesuai spesifikasi harus dibuat.

Tahap terakhir adalah Tahap 4. Pada titik ini, proposal siap untuk dimasukkan dalam spesifikasi resmi. Untuk sampai ke Tahap 4, tes harus ditulis, dua implementasi yang memenuhi spesifikasi harus lulus tes tersebut, anggota harus memiliki pengalaman praktis yang signifikan dengan fitur baru, dan editor spesifikasi EcmaScript harus menandatangani pada teks spesifikasi. Pada dasarnya begitu proposal membuat ke tahap 4, itu siap untuk berhenti menjadi proposal dan masuk ke spesifikasi resmi. Ini memunculkan hal terakhir yang perlu Anda ketahui tentang seluruh proses ini dan itu adalah jadwal rilis TC39s.

Pada 2016, versi baru ECMAScript dirilis setiap tahun dengan fitur apa pun yang siap saat itu. Apa itu artinya bahwa setiap proposal Tahap 4 yang ada saat rilis baru terjadi, akan dimasukkan dalam rilis untuk tahun itu. Karena siklus rilis tahunan ini, fitur-fitur baru harus lebih banyak tambahan dan lebih mudah untuk diadopsi.

Ini adalah bagian dari kursus “JavaScript Modern” tylermcginnis.com saya.