WASM 3.0 Rampung

• Standar Wasm 3.0 resmi diumumkan, mencakup fitur-fitur besar yang disiapkan selama 6–8 tahun
• Ruang alamat 64-bit, garbage collection, typed reference, tail call, penanganan eksepsi, dan lainnya memudahkan kompilasi bahasa tingkat tinggi ke Wasm
• Fitur inti baru ini membantu aplikasi berkinerja tinggi, berbagai runtime bahasa, keamanan, dan skalabilitas
• Cocok untuk kasus penggunaan di ekosistem non-web maupun luar lingkungan web yang perlu menangani kapasitas dan himpunan data lebih besar
• Sudah didukung di browser web utama, dan akan segera lengkap di mesin mandiri seperti Wasmtime, sehingga Wasm akan makin kokoh sebagai platform eksekusi serbaguna

---

Ikhtisar rilis Wasm 3.0

• Versi 3.0 dari standar WebAssembly dirilis pada 17 September 2025
  • Pembaruan besar ini hadir 3 tahun setelah versi 2.0 (selesai pada 2022) yang memperkenalkan instruksi vektor, operasi bulk memory, nilai kembalian jamak, dan tipe referensi sederhana
  • Grup komunitas dan working group W3C terus mengembangkan standar ini, dan rilis kali ini mencakup fitur-fitur besar yang disiapkan selama 6–8 tahun, sehingga skalanya cukup besar
  • Wasm tetap mempertahankan karakter sebagai bahasa tingkat rendah, sambil memperkuat sistem memori dan tipe untuk lebih mendukung kompilasi bahasa tingkat tinggi
• Fitur-fitur yang dikembangkan setelah versi 2.0 kini telah dimatangkan dan menjadi bagian dari standar Live, dengan dukungan yang meluas di browser web dan mesin mandiri
  • Status dukungan tiap mesin dapat dilacak di halaman status fitur Wasm
  • Diproduksi sebagai versi pertama menggunakan toolchain baru SpecTec untuk meningkatkan keandalan

Perubahan utama dan fitur baru

• Ruang alamat 64-bit
  • Memori dan tabel dapat dideklarasikan dengan tipe i64
  • Ruang alamat aplikasi Wasm dapat diperluas dari sekitar 4GB hingga batas fisik (secara teoretis 16 exabyte)
  • Untuk web, batas 16GB diterapkan, tetapi di ekosistem non-web ini berguna untuk mendukung aplikasi dan dataset skala besar
• Multi-memory
  • Dapat mendeklarasikan dan mengakses langsung beberapa objek memori dalam satu modul
  • Dapat dimanfaatkan untuk penggabungan modul, pemisahan ruang alamat, buffering, keamanan, dan lainnya
  • Alat static linking seperti wasm-merge kini dapat digunakan pada semua modul Wasm
• Garbage collection (GC)
  • Selain linear memory, kini didukung penyimpanan yang dikelola otomatis oleh runtime Wasm
  • Compiler dapat mendeklarasikan langsung layout data seperti tipe struct/array dan integer unboxed
  • Hanya menyediakan blok bangunan dasar untuk manajemen memori; sistem objek tingkat tinggi atau closure tetap dapat dirancang tersendiri sesuai bahasa implementasinya
• Typed reference
  • Sistem tipe Wasm diperluas agar dapat mendeskripsikan bentuk nilai heap dan referensi fungsi dengan lebih akurat
  • Mendukung subtyping dan rekursi tipe, serta memungkinkan pemanggilan fungsi tidak langsung yang aman tanpa runtime type check lewat instruksi baru call_ref
• Tail call
  • Mendukung struktur tail call yang langsung mengembalikan hasil tanpa menambah penggunaan ruang stack fungsi yang ada
  • Dapat dimanfaatkan pada bahasa fungsional atau optimisasi internal runtime
• Penanganan eksepsi
  • Memperkenalkan sistem penanganan eksepsi native di dalam Wasm
  • Menyediakan deklarasi tag dan payload eksepsi, catch opsional, serta exception handler berbasis blok
  • Memungkinkan peningkatan portabilitas dan performa tanpa metode tidak efisien yang sebelumnya harus memutar lewat JS
• Instruksi vektor relaxed
  • Untuk menyesuaikan perbedaan perangkat keras pada instruksi SIMD, tersedia varian relaxed yang membiarkan detail perilaku sebagian instruksi ditentukan implementasi
  • Berbagai optimisasi dimungkinkan selama masih berada dalam himpunan perilaku yang sah
• Profil deterministik
  • Bahkan dalam situasi ketika hasil instruksi yang sama bisa tidak deterministik, seperti operasi floating-point atau relaxed SIMD, standar ini mendefinisikan eksekusi deterministik lintas platform
  • Dapat menjamin reproducibility dan portabilitas untuk blockchain, sistem yang dapat diputar ulang, dan lainnya
• Sintaks custom annotation
  • Menambahkan sintaks anotasi yang bisa dibaca dan ditulis manusia di dalam source code
  • Tidak diinterpretasikan langsung oleh standar, tetapi dapat dimanfaatkan untuk implementasi standar atau ekstensi di masa depan

Konektivitas dengan JavaScript dan kompatibilitas

• JS string builtins
  • Nilai string JS dapat diteruskan dan dimanipulasi di Wasm sebagai externref
  • Dengan mengimpor fungsi bawaan baru, Wasm dapat langsung menggunakan string JS eksternal dari dalam modul

Manfaat dan prospek Wasm 3.0

• Menyediakan fondasi penting untuk kompilasi bahasa pemrograman tingkat lanjut ke target Wasm
• Bahasa-bahasa utama seperti Java, OCaml, Scala, Kotlin, Scheme, Dart dan lainnya juga mulai aktif memanfaatkan fitur GC

Status penyusunan spesifikasi dan distribusi

• Wasm 3.0 adalah standar pertama yang disusun dengan toolchain baru SpecTec
• Sebagian besar browser web utama sudah mendukung Wasm 3.0, dan mesin mandiri seperti Wasmtime juga akan segera menyusul sepenuhnya
• Status dukungan per mesin dapat dilihat di halaman Wasm feature status

[coremaker]

Bukankah mungkin juga akan muncul upaya untuk membuat DB memori?

[GN⁺]

Komentar Hacker News

• Hal yang paling saya nantikan adalah 64-bit menjadi nilai default spesifikasi, terutama karena web app seperti editor video online masih banyak terkena berbagai batasan akibat limit 32-bit, bahkan Figma juga mengalami batasan ini secara langsung. Satu hal yang saya penasaran adalah apakah batas memori yang bisa dialamatkan per tab di perangkat mobile akan tetap dipertahankan; biasanya ini ditentukan oleh OS, jadi mungkin tidak terhubung langsung dengan ruang 32-bit.

  • Saya ragu apakah benar aplikasi seperti editor video seharusnya dimasukkan ke document browser. Sayang sekali kita sebenarnya sudah punya native operating system yang dirancang dengan baik, tetapi sekarang hampir tidak ada yang memakainya. Jika memang dibutuhkan virtual machine yang lebih kuat daripada virtualisasi yang sudah diberikan proses OS yang ada, menurut saya lebih jujur untuk merancang abstraksi yang benar-benar sesuai tujuan. Rasanya seperti memaksa document reader sederhana menjadi editor video.

  • Sayangnya, fitur Memory64 punya penalti performa yang cukup besar. Pada 32-bit sebelumnya, runtime selalu langsung mengalokasikan seluruh 4GB sehingga pengecekan batas praktis tidak diperlukan, tetapi pada 64-bit batas harus dicek secara langsung. Kalau memang butuh memori di atas 4GB, mau tidak mau harus dipakai.

  • Saya juga menantikan hadirnya GC, reference types, dan JS string API. Senang rasanya melihat huruf J lagi setelah sekian lama, penasaran apakah dia baik-baik saja.

  • Memang terasa wajar kalau web app mentok di batas memori 4GiB. Rasanya seperti hidup di zaman membaca email saja butuh minimal 512GiB.

• Sungguh menarik bahwa garbage collection akan ditambahkan. Sebelumnya, Wasm tidak bisa mengakses stack secara langsung, jadi pendekatan GC tradisional seperti stack scanning tidak memungkinkan. Sebagai gantinya, sifat bahasa low-level tetap dipertahankan dengan memungkinkan layout memori dinyatakan lewat struct, array type, unboxed tagged int, dan seterusnya, sementara alokasi dan pengelolaan umur objek ditangani oleh Wasm. Sampai di situ saja, tapi tetap mengagumkan.

  • Menarik juga karena dengan masuknya GC, strukturnya tetap mendukung lingkungan non-GC. Ini mirip dengan bahasa D (D mendukung kompilasi dan eksekusi cepat baik untuk non-GC maupun GC). Sebagai tambahan, compiler Dlang yaitu LDC sekarang juga bisa menghasilkan Wasm: Generating WebAssembly with LDC

  • Saya penasaran apakah perubahan ini memungkinkan ukuran objek WebAssembly.Memory diperkecil. Ini isu yang sangat penting karena meskipun memori dibebaskan, alokasinya tetap tinggal di browser. Isu1 Isu2

• Saya penasaran kapan WASM bisa menyentuh DOM secara langsung. Rasanya ini seperti tujuan inti WASM sejak awal, tetapi sekarang justru terasa seperti monster terpisah yang hampir tidak berhubungan dengan web. Saya juga penasaran kapan JavaScript tidak lagi wajib dipakai.

  • Saya harap bagian ini dan pendekatan multithread bisa didukung dengan benar. Saya ingin bisa menulis aplikasi Rust, compile ke wasm, lalu langsung memanggilnya seperti ini:

    Untuk web app berperforma tinggi atau hal seperti browser extension, masalah memori dan performa benar-benar besar, jadi ini akan sangat membantu. Kalau aplikasinya berbasis wasm, kita juga bisa melewati v8 dan memakai engine seperti wasmer secara langsung. Menurut saya, teknologi web dipakai di desktop app seperti Electron karena desktop API terlalu buruk dan tidak portabel. Jika dukungan native untuk WASM makin kuat, aplikasi seperti Slack, VSCode, dan Discord bisa menjadi lebih ringan.

  • Bahkan sekarang pun program WASM bisa mengakses DOM. Hanya saja harus lewat JS API yang sudah ada. Sempat ada pembahasan tentang API khusus WASM, tetapi karena kekurangannya makin banyak, pada akhirnya dibatalkan.

  • Saya terus mengikuti perkembangan sambil menunggu bahasa frontend yang dirancang dengan baik. Tapi saya juga bertanya-tanya apakah lewat wrapper JS saat mengakses DOM benar-benar se-inefisien itu. Sebagian besar kode sudah tidak efisien sejak awal, jadi saya rasa overhead dari sini biasanya tidak terlalu menonjol.

  • Kalau menurut Anda JavaScript bermasalah, nanti Anda akan sadar bahwa sisi DOM jauh lebih parah.

  • Begitu WASM memegang referensi DOM, ada bagian tricky karena itu berarti bisa melihat langsung objek yang bisa di-garbage collect. Dalam model keamanan web JavaScript, bagian dalam GC tidak boleh bisa dilihat. Kalau WASM memegang pointer ke DOM, bagaimana itu harus ditangani jadi masalah. Mungkin setelah GC benar-benar masuk, isu ini bisa dibahas lagi, tetapi untuk WASM tanpa GC, tampaknya hampir tidak ada jawaban yang bagus.

• Saya tidak mengikuti perkembangan WASM sekitar setahun, jadi baru sadar sekarang model rilisnya beralih ke versi. Saya kira banyak fitur akan tetap opsional, tetapi sekarang tampaknya implementasi baru bisa disebut kompatibel dengan versi tertentu (misalnya WASM 3.0) jika semua fitur didukung. Saya penasaran siapa runtime non-browser kedua yang akan mendukung 3.0 secara penuh; tebakan saya wasmtime akan jadi yang pertama (deno dikecualikan karena berbasis v8). GC khususnya terasa seperti fitur yang tricky. Saya juga penasaran bagaimana rilis 3.0 ini terhubung dengan model "evergreen" sebelumnya. Evergreen adalah model yang terus memperbarui draf standar tanpa menetapkan versi final resmi secara terpisah. Saat ini Candidate Recommendation Draft terbaru praktis dianggap sebagai standarnya. status fitur wasm kabar wasm 2.0 draf standar terbaru

  • wasmtime sebenarnya sudah mendukung semua fitur utama wasm 3.0. GC diimplementasikan beberapa tahun lalu oleh rekan saya Nick Fitzgerald, tail call tahun lalu sudah diimplementasikan secara penuh oleh Jamey Sharp dan Trevor Elliott (tanpa batasan signature, tanpa perlu trampoline). Exception handling juga sudah ada dan akan segera dirilis resmi. Jadi rilis "3.0" ini bisa dilihat sebagai sinyal bahwa setiap engine pada dasarnya sudah menyiapkan semua fitur tersebut. Saya adalah maintainer wasmtime dan Cranelift.

  • Wizard adalah tool untuk riset, tetapi mendukung seluruh Wasm 3.0. Hanya saja, tool ini hanya punya interpreter dan baseline compiler, tidak punya compiler yang dioptimalkan seperti v8 atau wasmtime. Jadi dari sisi kecepatan memang lambat.

  • Sepertinya pengelolaan versinya akan menjadi seperti pendekatan feature set di JavaScript, yaitu tiap runtime akan dibicarakan berdasarkan set fitur yang didukungnya. Saya penasaran bagaimana feature discovery bekerja di wasm.

• Saya sangat senang melihat dukungan GC ditambahkan. Dulu, karena WASM tidak bisa mengakses stack secara langsung, implementasi GC tradisional berbasis stack scanning pada dasarnya tidak mungkin dilakukan.

• Saya merasa komunitas WebAssembly perlu lebih memperhatikan developer experience (DX). Saya pernah menulis compiler sendiri yang menargetkan Wasm, dan pengalamannya cukup tidak nyaman. Saya mengira ini bahasa dengan makna yang sangat terstruktur, tetapi saat menghasilkan Wasm lewat Binaryen.js, rasanya tidak benar-benar seperti menargetkan instruction set yang jelas. Mungkin ini karena Binaryen sendiri dan kurangnya dokumentasi. Sedikit hiburannya, menulis snippet teks Wasm terasa menyenangkan. compiler wasm jasmine

  • Binaryen membawa banyak legacy dari masa Wasm dulu dianggap sebagai AST. Fitur-fitur baru sulit dipaksakan masuk ke model lama itu. Compiler kami mendefinisikan sendiri struktur data untuk representasi Wasm abstrak, lalu default hasil kompilasinya diekspor sebagai .wasm, dan saat debug diekspor sebagai .wat. Menurut saya ini cukup intuitif, jadi instruction set-nya sendiri sebenarnya baik-baik saja. backend wasm Scala.js

  • Saya pernah mencoba Binaryen dari TypeScript dan merasakan frustrasi yang mirip. Setelah pindah ke wasm-tools berbasis Rust, pengalamannya jauh lebih baik.

  • Saya penasaran bagian mana yang secara spesifik terasa sulit. Ada kalanya validation error benar-benar menyebalkan, jadi di Wizard kami menambahkan opsi --trace-validation. Opsi itu membantu memvisualisasikan proses validasi agar lebih mudah dipahami.

  • Dokumentasi dan binding untuk binaryen.js memang sangat kurang. Saat ini fokus kemampuan tim lebih banyak diarahkan ke peningkatan optimisasi di core Binaryen, jadi sisi JS/TS perkembangannya lambat. Tapi kalau ada yang mau meluangkan waktu untuk memperbaiki binding JS/TS, menurut saya itu akan menguntungkan semua orang.

  • Saya juga merasa kadang lebih mudah membuat pure assembly code dari nol. Kebanyakan materi terpusat pada tool Rust, padahal pengalaman menulis langsung dengan tangan juga penting. Compiler dan assembly adalah hal yang berbeda. Perlu juga sudut pandang bahwa bukan hanya developer compiler yang tertarik pada Wasm.

• Saya masih punya harapan besar pada WASM, dan rilis kali ini terlihat keren. Saya menjalankan plugin WASM dengan traffic tinggi di envoy, juga memakai WASM untuk plugin aplikasi terminal seperti zellij. Dalam side project kecil, saya juga menjalankan web app wasm berbasis rust leptos. Jujur saja, mungkin 2 dari 3 penggunaan itu bukan pilihan teknis terbaik, tetapi saya merasa arah ini akan terus berkembang dengan baik ke depan. Kerja bagus semuanya.

• Yang sederhana itu terbaik. Harapan saya adalah cara yang lebih mudah dan cepat untuk mengirim Go struct. Saat memasukkan atau mengambil go struct ke/dari runtime, saya berharap kodenya tidak kusut dan tidak perlu solusi tempelan. Solusi umum yang bisa dipakai banyak bahasa juga bagus, meskipun ada batasan realistis tetap tidak masalah. Bagi saya, go adalah yang paling penting.

  • Saya setuju sekali, dan secara realistis ini juga tidak jauh lebih baik bahkan di bahasa tanpa GC. Faktanya, runtime yang di-GC di wasm justru sering lebih berantakan. Pengalaman JavaScript terburuk yang pernah saya alami adalah merapikan pointer secara manual. Di C++, destructor akan menangani saat keluar dari scope, tetapi di wasm dan js semuanya harus dikelola sendiri, jadi rasanya pengalaman JNI dulu malah lebih baik (termasuk dengan go). Dan setelah bersusah payah hanya untuk mengirim satu struct, overhead per call ternyata besar, jadi akhirnya saya mulai membungkus dan mengirim dalam unit yang lebih besar. Saya juga hanya berharap pipeline wasm bisa jadi lebih baik, karena sejauh ini masih berat.

  • Kalau ini native code, solusinya tetap sama: menyesuaikan antarbahasa ke struktur standar (seperti C struct) atau melakukan serialize/deserialzie. Ketika mencampur banyak runtime dan bahasanya tidak mendukung langsung, situasinya memang benar-benar melelahkan. Sangat jelas kenapa ini menjadi masalah.

  • Saya tidak tahu persis apa yang Anda inginkan, tetapi component model yang menjadi dasar WASI tampaknya akan membantu. Model ini memungkinkan tiap modul menentukan sendiri cara memetakan data ke memori (nantinya bahkan sampai GC heap), dan hal seperti tipe struct juga bisa didefinisikan sebagai interface sehingga compiler dapat membuat glue code secara otomatis.

  • Ini tampaknya bukan wilayah spesifikasi WASM, melainkan wilayah library. Saya pernah punya pengalaman bagus memakai code generator seperti ini secara internal.

• Saya menantikan dukungan OpenMP. Saya sedang menjalankan web build Solvespace secara eksperimental, dan jika OpenMP didukung hasilnya akan jauh lebih baik. demo solvespace online, CAD open source yang berjalan di browser.

  • Menurut saya Solvespace benar-benar tool yang keren. Dulu saya pernah mengikuti tutorial YouTube untuk mendesain casing keyboard split lalu membuatnya dengan CNC. Hasilnya bisa didapat dengan cepat. Terima kasih sudah merawat proyek ini.

  • Menurut saya ini UI web berbasis WASM terbaik yang pernah saya lihat. Saya penasaran apa tantangan tersulit saat menjalankan desktop build lewat Emscripten.

• Saya tambahkan satu hal yang sepertinya belum disebut: saya penasaran apakah fitur multiple-memories bisa dipakai untuk menghindari copy ganda saat memetakan resource WebGPU. Saat ini ada data yang dipetakan ke ArrayBuffer, jadi dari WASM harus disalin lewat JS dan ini merugikan performa. Beberapa memori WASM ditambah fitur address space di Clang/LLVM terasa seperti jalan keluarnya, tetapi saya tidak tahu apakah praktiknya sesederhana itu.

  • Memang ada diskusi dukungan toolchain multi-memory, tetapi saya juga tidak tahu apakah implementasi yang memanfaatkan banyak address space di LLVM benar-benar sudah jadi.

  • Semua ini mengingatkan saya pada segmented memory dan far-pointers zaman dulu. Belakangan saya sedang menulis game Gameboy, jadi memory mapping memang bagian dari "kesenangan", tetapi saya kurang suka kalau harus mengulanginya di lingkungan tanpa batasan seperti sekarang. Ada alasan kuat kenapa far pointers era DOS/Win16 dulu akhirnya dikubur.