WebAssembly 3.0 telah resmi diluncurkan sebagai standar baru, menghadirkan fitur-fitur utama seperti dukungan memori 64-bit dan garbage collection. Namun, peluncuran ini telah memicu diskusi sengit di komunitas developer mengenai penalti performa dan ketiadaan akses langsung DOM yang masih berlanjut.
Fitur Utama WebAssembly 3.0:
- Ruang alamat 64-bit: Memperluas dari 4GB menjadi 16 exabyte (web dibatasi hingga 16GB)
- Memori berganda: Modul tunggal dapat mendeklarasikan dan mengakses beberapa objek memori
- Pengumpulan sampah: Manajemen memori bawaan untuk bahasa tingkat tinggi
- Referensi bertipe: Sistem tipe yang ditingkatkan dengan subtipe dan rekursi
- Panggilan ekor: Panggilan fungsi yang efisien dalam penggunaan ruang stack
- Penanganan pengecualian: Dukungan pengecualian asli dalam WebAssembly
- Instruksi vektor santai: Operasi SIMD yang dioptimalkan untuk performa
- Profil deterministik: Eksekusi yang dapat direproduksi untuk sistem blockchain/replay
 |
|---|
| Pengumuman WebAssembly 30, menyoroti fitur-fitur barunya seperti memori 64-bit dan garbage collection |
Memori 64-bit Hadir dengan Biaya Performa
Fitur yang paling ditunggu-tunggu - ruang alamat 64-bit - memungkinkan aplikasi untuk secara teoretis mengakses hingga 16 exabyte memori, meningkat dari batas sebelumnya yaitu 4 gigabyte. Terobosan ini sangat menguntungkan aplikasi editing video dan aplikasi web kompleks seperti Figma , yang menangani file dengan lebih dari satu juta layer. Namun, developer menemukan kelemahan performa yang signifikan. Benchmark awal menunjukkan bahwa WebAssembly 64-bit dapat berjalan 10% hingga 100% lebih lambat dibandingkan versi 32-bit, dengan beberapa aplikasi mengalami perlambatan hingga 2x lipat. Penurunan performa ini berasal dari persyaratan bounds checking tambahan yang tidak diperlukan dalam implementasi 32-bit, di mana runtime dapat dengan mudah mengalokasikan seluruh ruang alamat 4GB.
Bounds checking: Fitur keamanan yang memverifikasi akses memori berada dalam batas yang diizinkan untuk mencegah crash dan kerentanan keamanan.
Perbandingan Dampak Performa:
| Fitur | Dampak Performa | Alasan |
|---|---|---|
| Memori 64-bit | 10-100% lebih lambat | Diperlukan pemeriksaan batas tambahan |
| Memori 32-bit | Baseline | Dapat menghilangkan pemeriksaan batas pada host 64-bit |
| WebAssembly GC | Berpotensi lebih cepat | Menghilangkan kebutuhan runtime GC yang dikirim |
| Multiple Memories | Bervariasi | Tergantung pada pola akses memori |
Garbage Collection Membuka Peluang untuk Bahasa High-Level
WebAssembly 3.0 memperkenalkan dukungan garbage collection bawaan, memungkinkan bahasa seperti Java , Kotlin , Scala , dan Dart untuk berjalan lebih efisien tanpa perlu menyertakan sistem manajemen memori mereka sendiri. Komunitas melihat ini sebagai game-changer untuk mengurangi ukuran bundle dan meningkatkan performa untuk bahasa yang menggunakan garbage collection. Namun, beberapa developer khawatir tentang kesalahpahaman, mencatat bahwa ini bukanlah solusi ajaib untuk porting bahasa high-level apa pun. WebAssembly GC sengaja dibuat low-level, memerlukan desain compiler yang cermat untuk memanfaatkan tipe struct dan array-nya.
Status Dukungan Bahasa:
- Kini Didukung dengan GC: Java , OCaml , Scala , Kotlin , Scheme , Dart
- Masih Menantang: C (tidak ada dukungan ref/interior pointer), Go (ketidakcocokan runtime)
- Tidak Terpengaruh: C , C++ , Rust , Zig (tidak menggunakan fitur GC )
Akses DOM Tetap Menjadi Bagian yang Hilang
Mungkin diskusi paling kontroversial berkisar pada kurangnya akses langsung DOM yang masih berlanjut di WebAssembly . Banyak developer mengungkapkan frustrasi karena mereka masih memerlukan JavaScript sebagai perantara untuk memanipulasi elemen halaman web. Meskipun ada solusi alternatif melalui JavaScript bindings, developer berargumen bahwa ini menghilangkan tujuan menggunakan bahasa alternatif untuk pengembangan web. Vendor browser mempertahankan bahwa akses langsung DOM akan menciptakan risiko keamanan dan kompleksitas implementasi, lebih memilih pendekatan saat ini di mana WebAssembly memanggil JavaScript APIs.
Akses langsung DOM tidak masuk akal sebagai fitur WASM . Paling banter itu akan menjadi fitur web-browser yang perlu diimplementasikan vendor browser di luar WASM .
Tantangan Developer Experience Masih Berlanjut
Umpan balik komunitas mengungkapkan frustrasi yang berkelanjutan dengan tools pengembangan dan dokumentasi WebAssembly . Developer melaporkan kesulitan dengan error validasi, dokumentasi API yang buruk, dan kompleksitas toolchain yang ada seperti Binaryen . Beberapa menemukan kesuksesan dengan beralih ke tools berbasis Rust seperti wasm-tools, sementara yang lain mengadvokasi penulisan WebAssembly secara manual daripada menggunakan abstraksi high-level.
Peluncuran ini merepresentasikan langkah maju yang signifikan untuk kemampuan WebAssembly , khususnya untuk lingkungan non-web di mana fitur-fitur baru dapat bersinar tanpa keterbatasan browser. Namun, trade-off performa dan fitur khusus web yang hilang menunjukkan bahwa perjalanan WebAssembly untuk menjadi target kompilasi universal yang dibayangkan developer masih memiliki rintangan yang harus diatasi.
Referensi: Wasm 3.0 Completed