Komuniti pembangunan JavaScript sedang bergelut dengan masalah yang semakin membesar iaitu kebergantungan berat yang disebabkan oleh perpustakaan yang mengutamakan kes tepi berbanding senario penggunaan biasa. Isu ini telah mewujudkan pokok kebergantungan yang tidak perlu kompleks dan memberi kesan kepada berjuta-juta projek di seluruh dunia.
Punca Utama: Kejuruteraan Berlebihan untuk Senario Jarang Berlaku
Masalah teras berpunca daripada perpustakaan yang mengendalikan kes tepi yang tidak akan pernah dihadapi oleh kebanyakan pembangun. Daripada memberi tumpuan kepada kes penggunaan utama, banyak pakej popular melaksanakan pengesahan dan pemeriksaan jenis yang meluas untuk senario yang berlaku dalam kurang daripada 1% aplikasi dunia sebenar. Pendekatan ini memaksa semua pengguna menanggung kos prestasi untuk ciri yang mereka tidak perlukan.
Perbincangan komuniti mendedahkan bahawa isu ini sebahagiannya wujud kerana JavaScript secara sejarahnya tidak mempunyai penaipan yang kuat. Seperti yang dinyatakan oleh seorang pembangun, JavaScript memerlukan pemeriksaan runtime yang meluas kerana anda boleh menghantar apa sahaja kepada fungsi dan terpulang kepada pelaksanaan untuk menanganinya. Walau bagaimanapun, walaupun dengan penggunaan TypeScript , banyak perpustakaan terus mengamalkan corak pengaturcaraan defensif ini.
Perpustakaan Popular dengan Berjuta-juta Muat Turun Mingguan Menunjukkan Skala Masalah
Beberapa pakej yang digunakan secara meluas menunjukkan masalah ini. Perpustakaan is-number, yang dimuat turun 90 juta kali setiap minggu, tidak hanya memeriksa sama ada sesuatu itu nombor - ia secara khusus mengesahkan nombor positif, terhingga dan rentetan seperti nombor. Kebanyakan pembangun hanya memerlukan typeof n === 'number', menjadikan kerumitan tambahan tidak perlu.
Begitu juga, is-arrayish menerima 76 juta muat turun mingguan tetapi mengendalikan senario kompleks seperti pengesanan array merentas alam yang tidak pernah dihadapi oleh kebanyakan aplikasi. Kaedah standard Array.isArray() sudah memadai untuk majoriti kes penggunaan.
Perpustakaan pascalcase menunjukkan contoh peningkatan ciri dengan menerima rentetan, nilai null, nilai undefined, array, fungsi, dan objek sewenang-wenangnya dengan kaedah toString. Namun hampir setiap pengguna menghantar rentetan mudah, menjadikan pengendalian input tambahan berlebihan.
Perpustakaan Popular yang Terlalu Kompleks mengikut Muat Turun Mingguan:
is-number: 90 juta muat turun/minggu - mengesahkan nombor positif, terhingga dan rentetan seperti nomboris-arrayish: 76 juta muat turun/minggu - memeriksa objek seperti array termasuk senario merentas alampascalcase: 9.7 juta muat turun/minggu - menerima rentetan, null, undefined, array, fungsi, dan objekis-regexp: 10 juta muat turun/minggu - menyokong pengesanan RegExp merentas alamshebang-regex: 86 juta muat turun/minggu - 2 baris kod, bersamaan denganstartsWith('!')
Kos Tersembunyi Pengesahan Tidak Kelihatan
Pendekatan ini mewujudkan beban tersembunyi untuk pembangun yang tanpa sedar mewarisi peraturan pengesahan ketat yang tertanam dalam dalam pokok kebergantungan mereka. Ramai pembangun tidak menyedari bahawa perpustakaan yang mereka gunakan secara tidak langsung mungkin menolak nombor negatif atau nilai infiniti, yang membawa kepada tingkah laku tidak dijangka dalam aplikasi pengeluaran.
Logik pengesahan sering beroperasi secara tidak kelihatan, menjadikan penyahpepijatan lebih sukar apabila pengendalian kes tepi mengganggu kes penggunaan yang sah. Ini mengalihkan beban pengesahan dari sempadan aplikasi, di mana ia sepatutnya berada, ke dalam rantai kebergantungan di mana ia menjadi lebih sukar untuk dikawal.
Penyelesaian yang Muncul dari Komuniti
Komuniti pembangunan secara aktif menangani isu ini melalui beberapa pendekatan. Komuniti e18e menyumbang peningkatan prestasi merentas ekosistem dengan menggantikan kebergantungan berat dengan alternatif moden yang cekap. Mereka mengekalkan senarai penggantian yang disyorkan dan menyediakan plugin ESLint untuk membantu mengenal pasti kebergantungan bermasalah.
Untuk penyelenggara perpustakaan, penyelesaiannya melibatkan membuat andaian yang lebih ketat tentang jenis input dan menghapuskan pengesahan yang tidak perlu. Alternatif moden seperti scule menunjukkan pendekatan ini dengan hanya menerima jenis data yang direka bentuk untuknya sambil mengekalkan sifar kebergantungan.
Alat seperti npmgraph dan node-modules.dev membantu pembangun memvisualisasikan pokok kebergantungan mereka dan mengenal pasti peluang untuk pengoptimuman. Alat ini memudahkan untuk mengesan pakej yang tidak perlu terperinci dan mencari alternatif yang lebih cekap.
Alternatif Ringan yang Disyorkan:
scule: 1.8M muat turun/minggu - transformasi kes teks dengan sifar kebergantungandlv: 14.9M muat turun/minggu - akses sifat mendalam dengan pengesahan minimal- Natif
Array.isArray()- menggantikanis-arrayishuntuk kebanyakan kes penggunaan - Natif
typeof n === 'number'- menggantikanis-numberuntuk semakan jenis asas - Sebaris
Math.min(Math.max(value, min), max)- menggantikan fungsi clamp yang kompleks
Bergerak Ke Arah Kebergantungan yang Lebih Ringan
Jalan ke hadapan memerlukan peralihan asas dalam falsafah reka bentuk perpustakaan. Daripada membina perpustakaan kes-tepi-dahulu yang mengendalikan setiap senario yang mungkin, komuniti harus memberi tumpuan kepada perpustakaan kes-penggunaan-biasa dengan sambungan pilihan untuk keperluan khusus.
Pendekatan ini akan membolehkan majoriti pengguna mendapat manfaat daripada perpustakaan yang lebih ringan dan pantas sambil tetap menyediakan penyelesaian untuk pembangun yang benar-benar memerlukan pengendalian kes tepi. Matlamatnya adalah memastikan bahawa hanya mereka yang memerlukan pengesahan kompleks membayar kos prestasinya, bukannya mengenakan ia kepada keseluruhan ekosistem.
Nota: Pokok kebergantungan merujuk kepada rangkaian pakej yang diperlukan oleh projek, termasuk kedua-dua kebergantungan langsung (pakej yang anda pasang secara eksplisit) dan kebergantungan tidak langsung (pakej yang diperlukan oleh kebergantungan anda).