WebAssembly 3.0 telah dilancarkan secara rasmi sebagai piawaian baharu, membawa ciri-ciri utama seperti sokongan memori 64-bit dan kutipan sampah. Walau bagaimanapun, pelancaran ini telah mencetuskan perbincangan hangat dalam komuniti pembangun mengenai penalti prestasi dan ketiadaan akses terus DOM yang berterusan.
Ciri-ciri Utama WebAssembly 3.0:
- Ruang alamat 64-bit: Berkembang daripada 4GB kepada 16 exabytes (web terhad kepada 16GB)
- Memori berbilang: Modul tunggal boleh mengisytihar dan mengakses objek memori berbilang
- Pengumpulan sampah: Pengurusan memori terbina dalam untuk bahasa peringkat tinggi
- Rujukan berjeniskan: Sistem jenis yang dipertingkat dengan subtaip dan rekursi
- Panggilan ekor: Panggilan fungsi yang cekap ruang tindanan
- Pengendalian pengecualian: Sokongan pengecualian asli dalam WebAssembly
- Arahan vektor santai: Operasi SIMD yang dioptimumkan prestasi
- Profil deterministik: Pelaksanaan yang boleh dihasilkan semula untuk sistem blockchain/ulang main
 |
|---|
| Pengumuman WebAssembly 30, menonjolkan ciri-ciri baharu seperti memori 64-bit dan pengumpulan sampah |
Memori 64-bit Datang dengan Kos Prestasi
Ciri yang paling dinanti-nantikan - ruang alamat 64-bit - membolehkan aplikasi secara teorinya mengakses sehingga 16 eksabait memori, berkembang daripada had 4 gigabait sebelumnya. Kejayaan ini terutamanya memberi manfaat kepada aplikasi penyuntingan video dan aplikasi web kompleks seperti Figma , yang mengendalikan fail dengan lebih sejuta lapisan. Walau bagaimanapun, pembangun mendapati kelemahan prestasi yang ketara. Penanda aras awal menunjukkan bahawa WebAssembly 64-bit boleh berjalan 10% hingga 100% lebih perlahan daripada versi 32-bit, dengan sesetengah aplikasi mengalami kelembapan 2x sepenuhnya. Kesan prestasi berpunca daripada keperluan pemeriksaan sempadan tambahan yang tidak diperlukan dalam pelaksanaan 32-bit, di mana masa jalan boleh memperuntukkan ruang alamat 4GB penuh.
Pemeriksaan sempadan: Ciri keselamatan yang mengesahkan akses memori berada dalam had yang dibenarkan untuk mencegah ranap dan kelemahan keselamatan.
Perbandingan Kesan Prestasi:
| Ciri | Kesan Prestasi | Sebab |
|---|---|---|
| Memori 64-bit | 10-100% lebih perlahan | Pemeriksaan sempadan tambahan diperlukan |
| Memori 32-bit | Garis dasar | Boleh mengelakkan pemeriksaan sempadan pada hos 64-bit |
| WebAssembly GC | Berpotensi lebih pantas | Menghapuskan keperluan untuk runtime GC yang dihantar |
| Pelbagai Memori | Berubah-ubah | Bergantung pada corak capaian memori |
Kutipan Sampah Membuka Pintu untuk Bahasa Peringkat Tinggi
WebAssembly 3.0 memperkenalkan sokongan kutipan sampah terbina dalam, membolehkan bahasa seperti Java , Kotlin , Scala , dan Dart berjalan dengan lebih cekap tanpa menghantar sistem pengurusan memori mereka sendiri. Komuniti melihat ini sebagai pengubah permainan untuk mengurangkan saiz berkas dan meningkatkan prestasi untuk bahasa yang dikutip sampah. Walau bagaimanapun, sesetengah pembangun bimbang tentang tanggapan salah, menyatakan bahawa ini bukan peluru perak untuk memindahkan mana-mana bahasa peringkat tinggi. WebAssembly GC sengaja berada pada peringkat rendah, memerlukan reka bentuk pengkompil yang teliti untuk mengambil kesempatan daripada jenis struct dan tatasusunannya.
Status Sokongan Bahasa:
- Kini Disokong dengan GC: Java , OCaml , Scala , Kotlin , Scheme , Dart
- Masih Mencabar: C (tiada sokongan penunjuk rujukan/dalaman), Go (ketidakserasian runtime)
- Tidak Terjejas: C , C++ , Rust , Zig (tidak menggunakan ciri GC )
Akses DOM Kekal Sebagai Bahagian yang Hilang
Mungkin perbincangan yang paling kontroversi berkisar mengenai kekurangan akses terus DOM yang berterusan dalam WebAssembly . Ramai pembangun menyatakan kekecewaan bahawa mereka masih memerlukan JavaScript sebagai perantara untuk memanipulasi elemen halaman web. Walaupun penyelesaian wujud melalui ikatan JavaScript , pembangun berhujah bahawa ini mengalahkan tujuan menggunakan bahasa alternatif untuk pembangunan web. Vendor pelayar mengekalkan bahawa akses terus DOM akan mewujudkan risiko keselamatan dan kerumitan pelaksanaan, lebih suka pendekatan semasa di mana WebAssembly memanggil API JavaScript .
Akses terus DOM tidak masuk akal sebagai ciri WASM . Ia akan menjadi ciri pelayar web yang terbaik yang perlu dilaksanakan oleh vendor pelayar di luar WASM .
Cabaran Pengalaman Pembangun Berterusan
Maklum balas komuniti mendedahkan kekecewaan berterusan dengan alat pembangunan dan dokumentasi WebAssembly . Pembangun melaporkan kesukaran dengan ralat pengesahan, dokumentasi API yang lemah, dan kerumitan rantaian alat sedia ada seperti Binaryen . Ada yang menemui kejayaan dengan beralih kepada alat berasaskan Rust seperti wasm-tools , manakala yang lain menyokong penulisan WebAssembly dengan tangan daripada menggunakan abstraksi peringkat tinggi.
Pelancaran ini mewakili langkah maju yang ketara untuk keupayaan WebAssembly , terutamanya untuk persekitaran bukan web di mana ciri-ciri baharu boleh bersinar tanpa had pelayar. Walau bagaimanapun, pertukaran prestasi dan ciri khusus web yang hilang menunjukkan bahawa perjalanan WebAssembly untuk menjadi sasaran kompilasi universal yang dibayangkan pembangun masih mempunyai halangan untuk diatasi.
Rujukan: Wasm 3.0 Completed