Ternyata ini Alasan Kenapa JavaScript Tidak Memperbaiki Kekurangannya

Contoh kasus yang belum lama terjadi di lanskap Javascript: Smooshgate.

Pada tahun 2018, sebuah proposal fitur baru JavaScript mencapai stage 3 dan siap menjalani uji implementasi, yaitu fungsi Array.prototype.flatten. Fungsi tersebut membuat array yang bertingkat menjadi hanya satu tingkat, misalnya [1, [2, 3]].flatten() akan menghasilkan [1, 2, 3].

Fitur baru berdasarkan spesifikasi tersebut diluncurkan di Firefox Nightly untuk pengujian, masalah pun ditemukan. Seseorang melaporkan bug di Bugzilla untuk rilis Firefox Nightly, ia menemukan sebuah situs cuaca di Jerman, http://wetteronline.de tidak berfungsi sebagai mana mestinya akibat polyfill yang dilakukan MooTools terhadap Array.prototype.flatten yang memiliki ketidakcocokan dengan spesifikasi flatten yang akan diluncurkan[1]. Melihat masalahnya adalah dengan MooTools, seorang kontributor lain di Bugzilla menduga situs yang akan mengalami masalah ada lebih banyak, mengingat popularitas MooTools di zamannya.

MooTools adalah pustaka JavaScript yang diluncurkan pada tahun 2006. MooTools memperkaya JavaScript dengan utilitas-utilitas yang disematkan pada objek prototipe berbagai objek pada JavaScript. Diperkirakan ada sekitar 4% situs web di dunia yang menggunakan MooTools, jumlah yang sangat banyak[2]. Yang membuat keadaan semakin kompleks adalah, MooTools tampaknya sudah tidak dikelola lagi; Barusan saya memeriksa repositorinya, dan menemukan rilis terakhir di tahun 2016, dan commit terakhir di tahun 2017[3].

Dalam frustasinya, salah seorang anggota TC39, saya lupa siapa - antara Mathias Bynens atau Brian Terlson - mengajukan ide untuk mengganti nama flatten yang akan dirilis menjadi smoosh, tentu saja dengan bercanda. Lanskap JavaScript pun sempat ramai saat itu, ada yang menerima candaan tersebut dengan baik, ada juga yang menanggapinya dengan serius, tetapi semua orang saat itu sepakat menjadikan kasus ini sebagai contoh bagaimana JavaScript sangat harus menghindari pengenalan fitur baru yang merusak implementasi lama (breaking changes).

Mari kita pertimbangkan tiga premis: 4% situs web di seluruh dunia menggunakan MooTools; pustaka MooTools diluncurkan pada 2006; dan MooTools sudah tidak dikelola lagi sejak 2016. Besar kemungkinan dari segitu banyaknya situs web di dunia yang menggunakan MooTools, banyak yang sudah tidak dikelola lagi, melihat usia pustaka MooTools itu sendiri. Lebih lagi, MooTools yang sudah tidak dikelola lagi memupuskan harapan akan adanya rilis baru yang memecahkan masalah flatten ini. Kalaupun ada, rasanya tak mungkin semua situs yang menggunakan MooTools akan memperbarui pustaka MooTools yang mereka pasang. Jadi, tidak mungkin jika MooTools yang harus menyesuaikan dengan spesifikasi JavaScript baru, justru harus spesifikasi baru yang 'mengalah'. Pelik bukan?

Pada akhirnya, tim TC39 memutuskan untuk mengganti nama flatten menjadi flat, dan flattenMap yang mengikutinya juga berubah menjadi flatMap[4]. Sebenarnya nama itu tidak ideal, karena idealnya nama sebuah metode, yang notabene adalah fungsi baiknya menggunakan kata kerja, sementara pada kasus ini mau tidak mau harus menggunakan kata sifat.

Kesimpulan

Jadi kembali ke pertanyaannya, kenapa tidak diperbaiki? Memperbaiki sesuatu pada bahasa pemrograman yang sangat ubiquitous seperti JavaScript berpotensi merusak implementasi program-program yang sudah stabil, bahkan sudah tidak dikelola. Ditambah lagi, versi JavaScript yang digunakan dalam mengeksekusi program, dalam hal ini situs web, bergantung kepada versi JavaScript pada engine peramban, bukan versi kodenya.

Bacaan Lebih Lanjut

• The final feature set of ECMAScript 2016 (ES7)
   - Menjelaskan proses implementasi proposal fitur baru pada ECMAScript dan ECMAScript sebagai living standard
• TC39 - ECMAScript
   - Menjelaskan tentang TC39
• #SmooshGate FAQ | Web | Google Developers
   - Rangkuman tentang Smooshgate