Apa yang terjadi smoosh?!
Proposal untuk JavaScript
fitur bahasa yang disebut Array.prototype.flatten ternyata
Tidak kompatibel dengan web. Pengiriman fitur di Firefox Nightly menyebabkan setidaknya satu situs populer
beristirahat. Mengingat bahwa kode yang bermasalah adalah bagian dari alat MooTools yang meluas
perpustakaan umum, kemungkinan lebih banyak situs web
yang terpengaruh. (Meskipun MooTools
jarang digunakan untuk {i>website<i} baru pada tahun 2018, karena
penggunaannya sangat populer dan
masih ada di banyak situs produksi.)
Penulis proposal dengan bercanda menyarankan untuk mengganti nama flatten menjadi smoosh menjadi
menghindari masalah kompatibilitas. Lelucon itu tidak jelas bagi semua orang, beberapa
orang mulai salah meyakini
bahwa nama baru itu telah digunakan
memutuskan, dan segala
sesuatunya menjadi cepat.
Apa yang dilakukan Array.prototype.flatten?
Array.prototype.flat, awalnya diusulkan sebagai Array.prototype.flatten,
meratakan array secara rekursif hingga depth yang ditentukan, yang secara default
ke 1.
// Flatten one level:
const array = [1, [2, [3]]];
array.flat();
// → [1, 2, [3]]
// Flatten recursively until the array contains no more nested arrays:
array.flat(Infinity);
// → [1, 2, 3]
Proposal yang sama mencakup Array.prototype.flatMap, yang mirip
Array.prototype.map, tetapi meratakan hasilnya menjadi array baru.
[2, 3, 4].flatMap((x) => [x, x * 2]);
// → [2, 4, 3, 6, 4, 8]
Apa yang dilakukan MooTools yang menyebabkan masalah ini?
MooTools menentukan versi non-standar Array.prototype.flatten-nya sendiri:
Array.prototype.flatten = /* non-standard implementation */;
Implementasi flatten MooTools berbeda dari standar yang diusulkan.
Namun, bukan itu masalahnya. Saat browser mengirim
Array.prototype.flatten secara native, MooTools menggantikan native
terlepas dari implementasi layanan. Hal ini memastikan bahwa kode yang mengandalkan perilaku MooTools
berfungsi sebagaimana mestinya terlepas dari apakah flatten native tersedia atau tidak.
Sejauh ini, hasilnya bagus.
Sayangnya, hal lain kemudian terjadi. MooTools menyalin seluruh
metode array kustom ke Elements.prototype (dengan Elements adalah
API khusus MooTools):
for (var key in Array.prototype) {
Elements.prototype[key] = Array.prototype[key];
}
for-in melakukan iterasi pada properti "dapat dihitung", yang tidak mencakup
metode native seperti Array.prototype.sort, tetapi menyertakan
properti yang ditetapkan secara rutin seperti Array.prototype.foo = whatever. Tapi —
dan ini contohnya — jika Anda menimpa properti yang tidak dapat dihitung, mis.
Array.prototype.sort = whatever, nilai tersebut tetap tidak dapat dihitung.
Saat ini, Array.prototype.flatten = mooToolsFlattenImplementation membuat
properti flatten yang dapat dihitung, sehingga nantinya disalin ke Elements. Namun jika
browser mengirimkan versi native flatten, versi tersebut menjadi tidak dapat dihitung, dan
tidak disalin ke Elements. Kode apa pun yang mengandalkan MooTools’
Elements.prototype.flatten sekarang rusak.
Meskipun sepertinya mengubah Array.prototype.flatten native menjadi
dapat digunakan untuk memperbaiki masalah, kemungkinan akan menyebabkan lebih
masalah kompatibilitas. Setiap situs yang mengandalkan for-in untuk melakukan iterasi
sebuah {i>array<i} (yang merupakan praktik yang buruk, tetapi
terjadi) kemudian tiba-tiba akan
iterasi loop tambahan untuk properti flatten.
Masalah mendasar yang lebih besar di sini adalah memodifikasi objek bawaan. Memperluas prototipe asli umumnya diterima sebagai praktik yang buruk saat ini, karena tidak cocok dengan library dan kode pihak ketiga lainnya. Jangan ubah objek yang bukan milik Anda!
Mengapa kita tidak mempertahankan nama yang ada dan merusak Web?
Pada tahun 1996, sebelum CSS meluas, dan jauh sebelum “HTML5” menjadi , situs Space Jam telah ditayangkan. Saat ini, {i>website<i} tersebut masih berfungsi sama seperti 22 tahun lalu.
Apa penyebabnya? Apakah seseorang memelihara situs web itu selama bertahun-tahun, memperbaruinya setiap kali vendor browser mengirimkan fitur baru?
Ternyata, "jangan merusak Web" adalah prinsip desain nomor satu untuk HTML, CSS, JavaScript, dan standar lain yang banyak digunakan pada Web. Jika pengiriman fitur browser baru akan menyebabkan situs yang ada dihentikan bekerja, ini berdampak buruk bagi semua orang:
- pengunjung situs web yang terpengaruh tiba-tiba mengalami kerusakan pengalaman pengguna;
- pemilik situs web beralih dari memiliki situs web yang berfungsi sempurna menjadi non-fungsional tanpa mengubah apa pun;
- Pengiriman fitur baru oleh vendor browser kehilangan pangsa pasar karena pengguna beralih browser setelah melihat “aplikasi ini berfungsi di browser X”;
- setelah masalah kompatibilitas diketahui, vendor browser lain menolak mengirimkan anotasi. Spesifikasi fitur tidak sesuai dengan kenyataan (“tidak ada apa-apa selain karya fiksi”), yang buruk untuk proses standardisasi.
Tentu saja, secara retrospektif MooTools melakukan hal yang salah — tapi merusak web tidak menghukum mereka, melainkan menghukum pengguna. Para pengguna ini tidak tahu apa itu moo Infrastruktur Cloud. Atau, kita dapat menemukan solusi lain, dan pengguna dapat melanjutkan untuk menggunakan web. Pilihannya mudah dibuat.
Apakah itu berarti API yang buruk tidak pernah dapat dihapus dari Platform Web?
Tergantung. Dalam kasus yang jarang terjadi, fitur yang buruk dapat dihapus dari Web. Bahkan hanya sekedar mencari mengetahui apakah kemungkinan untuk menghapus suatu fitur merupakan upaya yang sangat rumit, yang membutuhkan telemetri ekstensif untuk mengukur berapa banyak halaman web yang akan berubah. Namun, fitur ini cukup tidak aman karena dapat membahayakan pengguna, atau sangat jarang digunakan, hal ini dapat dilakukan.
<applet>, <keygen>, dan
showModalDialog() semuanya
contoh API buruk yang
berhasil dihapus dari Platform Web.
Mengapa kita tidak memperbaiki MooTools saja?
Mem-patch MooTools sehingga tidak lagi memperluas objek bawaan adalah langkah yang bagus ide. Namun, hal tersebut tidak menyelesaikan masalah yang dihadapi. Bahkan jika MooTools adalah merilis versi yang di-patch, semua situs web yang ada harus agar masalah kompatibilitas hilang.
Tidak bisakah orang cukup memperbarui salinan MooTools mereka?
Sebenarnya, MooTools akan merilis {i>patch<i}, dan setiap {i>website<i} menggunakan MooTools secara ajaib akan diperbarui pada hari berikutnya. Masalah terpecahkan, Benar kan?!
Sayangnya, ini tidak realistis. Bahkan jika seseorang entah bagaimana mengidentifikasi seluruh situs web yang terpengaruh, mengelola menemukan informasi kontak untuk satu per satu, berhasil menghubungi semua pemilik situs web, dan meyakinkan mereka semua untuk melakukan pembaruan (yang mungkin berarti seluruh code base mereka), seluruh prosesnya akan memakan waktu bertahun-tahun, paling baik.
Perlu diingat bahwa banyak dari situs web ini sudah usang dan kemungkinan tidak terawat. Meskipun pengelola masih ada, mungkin mereka bukan yang sangat ahli seperti Anda. Kami tidak mengharapkan semua orang pergi dan mengubah situs web mereka yang berusia 8 tahun karena masalah kompatibilitas web.
Bagaimana cara kerja proses TC39?
TC39 adalah komite yang bertanggung jawab mengembangkan bahasa JavaScript melalui standar ECMAScript.
#SmooshGate membuat beberapa orang percaya bahwa “TC39 ingin mengganti nama flatten menjadi
smoosh”, tetapi hanya sebagai lelucon yang tidak dikomunikasikan dengan baik kepada pihak eksternal.
Keputusan besar seperti mengganti nama proposal tidak dianggap enteng, tidak diambil
oleh satu orang, dan jelas tidak diambil dalam semalam berdasarkan satu
Komentar GitHub.
TC39 beroperasi pada proses staging yang jelas untuk proposal fitur.
Proposal ECMAScript dan perubahan besar apa pun padanya (termasuk metode
baru) dibahas selama rapat TC39, dan harus disetujui oleh
seluruh komite sebelum
mereka menjadi resmi. Dalam kasus
Array.prototype.flatten, proposal telah melalui beberapa
perjanjian, hingga Tahap 3, yang menunjukkan bahwa fitur
siap untuk diimplementasikan di {i>browser <i}web. Spesifikasi tambahan ini sudah umum
masalah yang muncul
selama implementasi. Dalam hal ini, yang paling penting
masukan yang diberikan setelah mencoba mengirimkannya: fitur dalam kondisinya saat ini,
merusak Web. Masalah yang sulit diprediksi seperti ini
adalah salah satu alasan mengapa
proses TC39 tidak hanya berakhir setelah {i>browser<i} mengirimkan fitur.
TC39 beroperasi berdasarkan konsensus, yang berarti komite harus menyetujui setiap
perubahan. Meskipun smoosh adalah saran yang serius, sepertinya
anggota komite akan keberatan
dengan menggunakan nama yang lebih umum seperti
compact atau chain.
Penggantian nama dari flatten menjadi smoosh (meskipun bukan lelucon)
tidak pernah dibahas dalam
pertemuan TC39. Dengan demikian, sikap TC39 resmi terhadap
topik ini saat ini tidak diketahui. Tidak ada satu orang pun yang dapat berbicara atas nama
seluruh TC39 sampai tercapai konsensus pada pertemuan berikutnya.
Rapat TC39 umumnya dihadiri oleh orang-orang dengan latar belakang beragam latar belakang: beberapa di antaranya memiliki pengalaman desain bahasa pemrograman, yang lain bekerja pada {i>browser<i} atau mesin JavaScript, dan semakin banyak ada untuk mewakili komunitas developer JavaScript.
Bagaimana pada akhirnya SmooshGate terselesaikan?
Selama rapat TC39 Mei 2018, #SmooshGate
diselesaikan secara resmi dengan mengganti nama flatten menjadi flat.
Array.prototype.flat dan Array.prototype.flatMap dikirim di V8 v6.9 dan
Chrome 69.