Dalam dunia pembangunan web yang sentiasa berkembang, satu perdebatan hangat telah muncul semula mengenai kelebihan menggunakan JavaScript asli berbanding kerangka kerja popular seperti React, Vue, atau Svelte. Perbincangan ini tertumpu pada satu corak yang dipanggil Writing JavaScript Views the Hard Way, yang menyokong manipulasi DOM secara langsung menggunakan JavaScript asli berbanding bergantung pada lapisan abstraksi yang disediakan oleh kerangka kerja.
 |
|---|
| Repositori GitHub untuk "Writing JavaScript Views the Hard Way," menyoroti projek utama dalam perbahasan JavaScript biasa berbanding rangka kerja |
Daya Tarikan Bebas Kerangka Kerja
Ramai pembangun dalam komuniti menyatakan keseronokan untuk meninggalkan kerangka kerja dan beralih kepada pendekatan JavaScript asli. Mereka menyebut manfaat prestasi yang ketara, proses nyahpepijat yang lebih mudah, dan hubungan yang lebih langsung dengan platform web. Seorang pembangun berkongsi pengalaman terkini mereka membina aplikasi dalam TypeScript asli dengan Vite, menyatakan bahawa mereka semakin mempersoalkan amalan 'terbaik' pembangunan bahagian hadapan setelah melihat manfaat pendekatan langsung. Daya tarikan ini melangkaui kelebihan teknikal semata-mata termasuk manfaat pendidikan, kerana bekerja secara langsung dengan DOM memaksa pembangun untuk memahami teknologi web asas dengan lebih mendalam.
Saya tidak dapat menyimpulkan ia boleh berskala, apa pun maksudnya, tetapi saya dapat menyimpulkan bahawa terdapat manfaat besar dari segi prestasi, ia menyeronokkan, mengajar anda banyak perkara, nyahpepijat adalah mudah, memahami seni bina adalah ringkas, anda tidak memerlukan PhD dalam teknik rendering/memoization/dan sebagainya.
Kelebihan "Menulis Pandangan JavaScript dengan Cara yang Sukar"
- Prestasi: Prestasi hampir optimum dengan operasi yang tidak perlu diminimumkan
- Tiada kebergantungan: Tidak perlu menaik taraf atau menguruskan pustaka luaran
- Mudah alih: Kod boleh digunakan dengan mana-mana rangka kerja
- Kebolehselenggaraan: Mengikuti konvensyen ketat untuk organisasi kod yang boleh diramal
- Sokongan pelayar: Serasi dengan semua pelayar (dengan pilihan keserasian untuk pelayar lama)
- Penyahpepijatan lebih mudah: Jejak tindanan yang cetek menjadikan pengesanan isu lebih mudah
- Pendekatan berfungsi: Menggunakan fungsi biasa tanpa hierarki kelas yang kompleks
DOM sebagai Sumber Kebenaran
Corak menarik yang muncul dalam perbincangan adalah menggunakan DOM itu sendiri sebagai sumber kebenaran untuk keadaan aplikasi, berbanding mengekalkan pemboleh ubah keadaan berasingan. Sesetengah pembangun menyokong untuk membaca dan menulis terus ke elemen DOM melalui getter dan setter, bukannya menyimpan pemboleh ubah JavaScript berasingan yang perlu disegerakkan dengan DOM. Pendekatan ini menghapuskan keperluan untuk mengekalkan keadaan di dua tempat tetapi menimbulkan kebimbangan tentang kerentanan terhadap sambungan pelayar yang mungkin mengubah DOM secara tidak dijangka, atau cabaran dalam mengendalikan keadaan berulang merentasi berbilang komponen UI.
Kebimbangan Kebolehselenggaraan
Walaupun pendekatan Hard Way menjanjikan kesederhanaan, ramai pembangun menyatakan keraguan tentang kebolehselenggaraannya dalam persekitaran pasukan dan aplikasi yang lebih besar. Corak ini sangat bergantung pada konvensyen berbanding struktur yang dikuatkuasakan, yang boleh membawa kepada ketidakkonsistenan apabila ahli pasukan yang berbeza menyumbang kepada kod sumber. Seperti yang dinyatakan oleh seorang pengulas, corak reka bentuk ini hanya berdasarkan konvensyen. Ini bermakna pembangun bebas untuk menyimpang dari konvensyen bila-bila masa mereka mahu. Ini berbeza dengan kerangka kerja yang menguatkuasakan corak tertentu melalui API dan alat mereka.
Pengurusan Keadaan: Cabaran Sebenar
Tema berulang dalam komen adalah bahawa kesukaran sebenar dalam pembangunan bahagian hadapan bukanlah mencipta elemen DOM tetapi menguruskan keadaan dan memastikan UI sentiasa segerak dengan keadaan tersebut. Kerangka kerja reaktif wujud justeru untuk menyelesaikan masalah ini. Apabila aplikasi menjadi lebih kompleks, mengesan secara manual bahagian UI yang perlu dikemas kini apabila keadaan berubah menjadi semakin sukar. Seorang pembangun menyatakan bahawa masalah asas adalah apabila sesuatu keadaan berubah, semua UI yang bergantung pada keadaan tersebut perlu dikemas kini, dan mengekalkan fungsi kemas kini ini secara manual menjadi semakin rumit apabila aplikasi berkembang.
Struktur Komponen "Hard Way"
- Template: Menggunakan
document.createElement('template')untuk struktur HTML - Fungsi klon: Mencipta contoh baru daripada templat
- Fungsi init: Menyediakan contoh komponen dengan:
- Pemboleh ubah DOM (rujukan kepada elemen)
- Pemboleh ubah keadaan (nilai data)
- Fungsi kemaskini DOM (untuk mengubah elemen)
- Fungsi kemaskini keadaan (untuk mengubah data)
- Fungsi kemaskini (untuk menerima props daripada induk)
Pertimbangan Keselamatan
Beberapa pembangun membangkitkan kebimbangan tentang kerentanan keselamatan yang berpotensi dalam pendekatan templat yang ditulis secara manual. Menggunakan template literal untuk menjana rentetan HTML boleh membawa kepada kerentanan cross-site scripting (XSS) jika input pengguna tidak disanitasi dengan betul. Walaupun sanitasi di bahagian pelayan boleh membantu, ramai yang berpendapat bahawa kerangka kerja moden menyediakan perlindungan yang lebih baik dengan mengendalikan ini secara automatik. Perbincangan menekankan betapa mudahnya pembangun boleh memperkenalkan isu keselamatan apabila menjana HTML secara manual, terutamanya mereka yang belum mengalami era pembangunan web sebelum kerangka kerja.
Kesimpulannya, walaupun pendekatan Hard Way menawarkan manfaat yang menarik untuk kes penggunaan tertentu—terutamanya dari segi prestasi, kawalan, dan peluang pembelajaran—komuniti masih terbahagi sama ada ia sesuai untuk aplikasi pengeluaran pada skala besar. Perdebatan ini akhirnya mencerminkan ketegangan antara kesederhanaan dan struktur, antara kawalan langsung dan kemudahan yang diabstrakkan, yang telah mencirikan pembangunan web selama bertahun-tahun. Apabila pelayar terus berkembang dan menawarkan API asli yang lebih berkuasa, perbincangan ini berkemungkinan akan terus berkembang juga.