Rumah  >  Artikel  >  hujung hadapan web  >  Perbandingan perbezaan antara SeaJS dan RequireJS_AngularJS

Perbandingan perbezaan antara SeaJS dan RequireJS_AngularJS

WBOY
WBOYasal
2016-05-16 16:28:191314semak imbas

"Sejarah bukan masa lalu, sejarah berlaku sekarang. Dengan perkembangan pesat spesifikasi seperti W3C dan pelayar, pembangunan modular bahagian hadapan secara beransur-ansur akan menjadi infrastruktur. Segala-galanya akhirnya akan menjadi sejarah, dan masa depan akan menjadi lebih baik. "—— Memetik perenggan terakhir artikel asal Yu Bo, saya secara peribadi sangat bersetuju. Sekarang setelah kita bercakap tentang "masa depan", saya secara peribadi berpendapat bahawa jika modul js bahagian hadapan terus berkembang, format modulnya berkemungkinan menjadi spesifikasi standard untuk WEB masa hadapan, menghasilkan pelbagai kaedah pelaksanaan. Sama seperti format JSON, ia akhirnya menjadi standard dan dilaksanakan secara asli oleh pelayar.

Siapakah yang lebih berkemungkinan menjadi standard modul tak segerak masa hadapan? SeaJS mengikut spesifikasi CMD, dan RequireJS mengikut spesifikasi AMD Mari mulakan dengan dua format berbeza ini.

CMD

Kaedah pengisytiharan kebergantungan modul CMD:

Salin kod Kod adalah seperti berikut:

define(fungsi (memerlukan) {
var a = memerlukan('./a');
var b = memerlukan('./b');
// lagi kod..
})

Kebergantungan CMD diisytiharkan berdekatan dan diisytiharkan melalui kaedah keperluan dalaman. Tetapi kerana ia adalah modul tak segerak, pemuat perlu memuatkan modul ini lebih awal, jadi semua kebergantungan dalam modul perlu diekstrak sebelum modul benar-benar digunakan. Sama ada ia diekstrak dengan segera oleh pemuat atau diekstrak terlebih dahulu melalui alat automatik, format pengisytiharan pergantungan CMD ini hanya boleh dicapai melalui analisis statik, yang merupakan kelemahan CMD.

Kelemahan spesifikasi CMD

Tidak boleh dimampatkan secara langsung: memerlukan ialah pembolehubah tempatan, yang bermaksud ia tidak boleh dimampatkan secara langsung melalui alat pemampatan Jika pembolehubah memerlukan diganti, alat pemuat dan automasi tidak akan dapat memperoleh kebergantungan modul.
Terdapat konvensyen tambahan untuk penulisan modul: parameter laluan tidak boleh tertakluk kepada operasi rentetan dan tidak boleh digantikan dengan pembolehubah, jika tidak, alat pemuat dan automasi tidak akan dapat mengekstrak laluan dengan betul.
Kontrak di luar spesifikasi bermakna lebih banyak dokumentasi, melainkan ia juga sebahagian daripada spesifikasi.

Nota: Analisis statik SeaJS dilaksanakan dengan meletakkan pakej modul keString() dan kemudian menggunakan ungkapan biasa untuk mengekstrak bahagian yang diperlukan untuk mendapatkan laluan modul bergantung.

AMD

Kaedah pengisytiharan pergantungan modul AMD:

Salin kod Kod adalah seperti berikut:

tentukan(['./a', './b'], fungsi (a, b) {
// lagi kod..
})

Kebergantungan AMD diisytiharkan terlebih dahulu. Kelebihan kelebihan ini ialah kebergantungan tidak perlu dianalisis secara statik Kedua-dua pemuat dan alat automasi secara langsung boleh mendapatkan kebergantungan pemuat dan automasi alat analisis adalah berfaedah.

Kelemahan spesifikasi AMD

Pengisytiharan tanggungan terlebih dahulu tidak begitu mesra dalam penulisan kod.
Terdapat perbezaan tertentu antara modul secara dalaman dan Modul NodeJS.
Perkara kedua memerlukan penjelasan khas. Malah, modul asynchronous CMD atau AMD tidak boleh konsisten dengan spesifikasi modul segerak (Modul NodeJS hanya satu yang lebih seperti modul segerak daripada yang lain). Untuk menukar AMD kepada modul yang disegerakkan, selain mengalih keluar pembungkus fungsi define, anda perlu menggunakan require dalam pengepala untuk mengisytiharkan dependensi, manakala CMD hanya perlu mengalih keluar pembungkus fungsi define.

Ringkasan

Dari segi spesifikasi, AMD lebih ringkas dan lebih ketat, dengan kebolehgunaan yang lebih luas Dengan promosi kukuh RequireJS, ia hampir menjadi standard modul tak segerak de facto di luar negara, dan perpustakaan utama juga telah menyokong spesifikasi AMD secara berturut-turut.

Tetapi dari perspektif SeaJS dan CMD, ia juga telah melakukan banyak perkara yang baik:

1. Gaya pengisytiharan pergantungan yang agak semula jadi
2. Pelaksanaan dalaman yang kecil tetapi cantik
3. Reka bentuk fungsi periferi intim
4. Sokongan komuniti Cina yang lebih baik

Jika boleh, saya berharap untuk melihat SeaJS turut menyokong AMD Untuk konsisten dengan persekitaran komuniti hadapan, kebahagiaan utama adalah majoriti pembangun.

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn