- WebAssembly (Wasm) masih digunakan sebagai teknologi inti di berbagai produk nyata, dan memainkan peran penting dalam game engine, alat desain, dan web container
- Bahasanya sendiri memiliki struktur yang dipetakan secara efisien ke perangkat keras, dan dirancang dengan fokus pada keamanan dan portabilitas
- Model keamanannya menggunakan struktur 'deny-by-default', yang memungkinkan isolasi tingkat proses dan kecepatan eksekusi yang tinggi
- Melalui ekosistem plugin dan dukungan lintas bahasa, Wasm dimanfaatkan di beragam lingkungan, tetapi belum diadopsi pada tingkat yang menggantikan seluruh browser
- Saat ini, WebAssembly telah terintegrasi secara mendalam pada tingkat library dan runtime, dan merupakan teknologi yang berkembang cepat dalam hal standardisasi dan perluasan fitur
Contoh penggunaan nyata
- WebAssembly menangani fungsi inti di Godot, Figma, Stackblitz, Squoosh.app, Zellij, Ruffle
- Godot menggunakannya untuk build game web, dan Figma untuk mengubah kode C++ menjadi bentuk yang dapat dijalankan di browser
- Stackblitz memanfaatkan Wasm untuk web container, dan Ruffle sebagai emulator Flash
- Namun, situs berskala besar yang membangun seluruh web di atas Wasm masih jarang, dan kebanyakan penggunaan terbatas pada unit fungsi tertentu
Definisi dan kecepatan WebAssembly
- WebAssembly adalah sebuah bahasa (language), dan konsep kecepatannya tidak melekat pada bahasa itu sendiri melainkan bergantung pada performa engine
- Seperti JavaScript, engine runtime (V8, SpiderMonkey, dll.) menentukan kecepatan eksekusi
- WebAssembly memiliki struktur yang dipetakan secara efisien ke perangkat keras modern, dan dapat dijalankan baik dengan cara dikompilasi maupun diinterpretasikan
Struktur pemetaan yang efisien
- Wasm adalah bytecode yang dekat dengan assembly language, sehingga dapat dikompilasi ke sebagian besar perangkat keras tanpa kehilangan berarti
- WAT (WebAssembly Text) adalah representasi teks dari Wasm, dan hampir dapat dikonversi secara 1:1
- Mirip dengan bytecode JVM, tetapi API-nya kecil dan jaminan keamanannya kuat
- Akses memori bersifat eksplisit, dan hanya dapat memakai sumber daya yang diizinkan oleh lingkungan host
Wasm sebagai target kompilasi
- Berbagai bahasa seperti Rust, C, Zig, Go, Kotlin, Java, C# dapat dikompilasi ke Wasm
- Bahasa interpreter seperti Python, PHP, Ruby juga bisa dijalankan melalui build Wasm
- Browser secara bawaan menyertakan engine Wasm, dan tersedia juga runtime independen seperti Wasmtime, WasmEdge, Wasmer
- Satu artefak Wasm tunggal dapat dijalankan secara independen dari perangkat keras
Struktur keamanan dan pemanfaatan
- WebAssembly mengadopsi model keamanan 'deny-by-default', sehingga akses ke luar hanya diizinkan melalui import yang dinyatakan secara eksplisit
- Control flow stack tersembunyi, linear memory, dan himpunan instruksi yang terbatas memberikan jaminan isolasi yang kuat
- Cloudflare mengisolasi eksekusi kode berbasis Wasm dengan V8 isolate, dan Fermyon menyediakan waktu startup pada tingkat submilidetik
- Ruffle memulihkan konten Flash secara aman, Pyodide menjalankan Python di Wasm, dan Figma menjalankan plugin dengan QuickJS berbasis Wasm
Portabilitas dan embedding
- Runtime Wasm bersifat ringan, dan Zellij, Envoy, Lapce mengadopsi Wasm untuk sistem plugin mereka
- Bahkan di lingkungan yang memiliki engine JavaScript, berbagai library Wasm dapat digunakan untuk pemrosesan gambar, OCR, physics engine, rendering, toolkit media, database, dan parser
- Dalam banyak kasus, pengguna tidak menyadari bahwa Wasm sedang digunakan, karena berjalan secara transparan di dalam library
Tinjauan ulang kecepatan dan ukuran
- Browser menjalankan Wasm melalui pipeline yang sama dengan JS, sehingga masih ada batas performa dari struktur engine
- Perbedaan efisiensi muncul bergantung pada sistem tipe bahasa dan tingkat optimasi compiler
- Biaya batas antara host dan program serta ukuran biner yang membesar disebut sebagai kekurangan
- Standar WASI berupaya meredakannya, tetapi standardisasi tipe string masih belum selesai
- Zig menghasilkan biner Wasm paling kecil
- Di lingkungan native, performa dapat menurun karena threading, IO, dan penggunaan memori
Tren pengembangan bahasa dan standar
- Standardisasi Wasm berjalan paralel melalui W3C Working Group dan Bytecode Alliance
- Yang terakhir memimpin pengembangan yang berfokus pada alat seperti WIT, Component Model
- Usulan fitur baru diadopsi dengan cepat, meski di beberapa kalangan ada perdebatan soal kecepatan dan arah pengembangannya
- Wasm menyebar sebagai teknologi integrasi internal daripada pengganti JavaScript
- Framework seperti Blazor, Leptos memanfaatkan Wasm tanpa harus menangani JS secara langsung
- Saat ini Wasm lebih banyak diadopsi oleh pembuat library, dan developer umum tetap dapat menggunakannya tanpa harus memahami cara kerjanya di dalam
- Sulitnya materi pembelajaran disebut sebagai hambatan belajar, dan proyek pembelajaran seperti
watlings turut diperkenalkan
1 komentar
Komentar Hacker News
Saya pikir Wasm telah mencapai sebagian besar tujuan saat dibuat
Secara pribadi saya telah menggunakan Wasm sebagai komponen inti di puluhan proyek
Mesin JS memang sangat cepat, tetapi Wasm tetap memberi tingkat kontrol CPU yang tinggi dan kinerja yang luar biasa
Namun, Wasm tidak memenuhi harapan untuk sepenuhnya menggantikan JS+HTML+CSS. Menurut saya, alasan besarnya adalah tidak adanya DOM binding
Saya juga pernah mencoba framework Wasm seperti Yew, tetapi rasanya seperti lapisan canggung yang ditumpangkan di atas JS
Saya belum pernah mencoba Blazor, tetapi saya tetap merasa lebih nyaman menulis dengan JS
Meski begitu, Wasm diam-diam berjalan di banyak tempat, dan menurut saya itulah bukti keberhasilan yang sesungguhnya
Misalnya, fitur mengubah kecepatan audio di browser hanya bisa mencapai tingkat performa seperti itu jika menjalankan library C++ lewat Wasm
Jika ada DOM binding yang layak, JS akan tersingkir dari frontend dalam 10 tahun
C# memudahkan berbagi kode backend dan frontend, dan template Razor juga didukung IDE dengan baik
Namun, karena harus membawa seluruh .NET CLR dan BCL, ukuran bundelnya besar
Karena akses DOM sulit, Blazor menggunakan struktur dengan renderer Virtual DOM kecil di sisi JS
Performanya cukup baik, tetapi tetap lebih lambat daripada JS yang ditulis langsung
Bolero berbasis F# juga menarik, tetapi sulit meyakinkan tim
Untuk berinteraksi dengan DOM, dibutuhkan bahasa tingkat tinggi yang cocok untuk itu
JS menjalankan peran itu dengan baik, dan kombinasi HTML/CSS/JS sudah menjadi bahasa bersama untuk pengembangan UI
Ada juga upaya membuang rendering browser dan beralih ke basis kanvas, tetapi itu tetap ranah niche
Dunia di mana bahkan situs web sederhana harus mengunduh runtime beberapa MB itu mengerikan
Penyebab lambat yang sebenarnya bukan JS, melainkan DOM. Pada akhirnya, tetap harus berinteraksi dengan DOM
Saya telah bekerja dengan WebAssembly selama beberapa tahun, dan sebentar lagi akan merilis framework berbasis Wasm
Ekosistemnya berkembang cepat lalu tiba-tiba melambat, dan pengenalan WASI serta Component Model menimbulkan kebingungan
Tingkat dukungan berbeda di tiap engine, sehingga sering harus berpindah-pindah antara dokumentasi, kode, dan issue
Masalah terbesar adalah dukungan JS/TS. Saat ini, cara integrasinya hampir seperti hack sehingga tidak stabil
Web Containers membawa perbaikan, tetapi banyak developer sudah pindah ke Bun
Potensi Wasm sangat besar
Secara teori, ini bisa menjadi target kompilasi bersama untuk semua platform
Tetapi kenyataannya agak mengecewakan karena baru sebatas membuat sebagian fitur Figma lebih cepat
Struktur pengembangan yang berpusat pada komite juga menjadi batasan karena lajunya lambat
Di era Native Client, aplikasi dengan kecepatan native itu mungkin; sekarang Wasm lebih lambat dari itu
Sayang sekali struktur binding JS tidak diterapkan juga ke Wasm
Lagi pula, Wasm juga tidak lebih cepat daripada JS
HTML/CSS/JS sudah terbukti berguna, sedangkan Wasm masih merupakan stack teknologi yang asing
Ekosistem yang berpusat pada Docker justru menjadi beban
Banyak build tool di ekosistem JS ditulis dengan Rust, dan sebagian dijalankan di browser lewat Wasm
Ekosistem React dan npm juga secara internal menggunakan Wasm
Jika Wasm hilang, dunia frontend JS akan terguncang besar
Namun, framework UI Wasm native masih belum memadai
Harus bergantung pada DOM dan CSS, serta mengakses API browser lewat JS, sehingga tidak efisien
DOM memang bisa dikendalikan dengan Rust atau Kotlin, tetapi Rust terlalu low-level untuk frontend
Cross-compile mobile makin umum, dan JetBrains Compose Multiplatform adalah contohnya
Yang menghambat perkembangan Wasm adalah tooling
Debugging masih setingkat
printf, dan plugin DWARF untuk Chrome juga sudah lama tidak diperbaruiProses membuat file .wasm untuk tiap bahasa dan mengatur import/export itu rumit
Dukungan GC juga belum lengkap, sehingga ekosistem seperti .NET harus membawa GC sendiri
WIT terlihat seperti upaya COM/CORBA/gRPC lainnya
Emscripten rumit dan tidak stabil, wasi-sdk kekurangan fitur
Baik LLVM maupun engine sama-sama kurang optimal, dan tooling Wasm milik Rust pun pada praktiknya sudah terhenti
Bahkan belum ada cara standar untuk mengimpor modul Wasm dari JS
Dukungan multithread juga memerlukan pengaturan header COOP/COEP, sehingga tidak mungkin di GitHub Pages
Jika tooling sudah melampaui level “demo teknologi”, pemakaiannya pasti akan jauh lebih luas
Perusahaan kami, Leaning Technologies, sangat aktif menggunakan Wasm
Dengan WebVM, kami menjalankan binary x86 di browser,
dengan BrowserCraft, kami menjalankan aplikasi Java (termasuk Minecraft),
dan dengan BrowserPod, kami menjalankan container Node.js di browser
Ini sangat kuat, tetapi merupakan alat untuk power user. Mengompilasi logika frontend biasa ke Wasm itu tidak efisien
Kecepatan perkembangan CheerpJ sangat mengesankan, dan ada pendapat bahwa jika muncul 10 tahun lebih awal, platform web bisa saja berbeda sekarang
Dari sudut pandang yang tidak menyukai JS, membuat situs web tanpa JS adalah daya tarik nyata Wasm
Saya bekerja di framework Wasm berbasis Rust, Dioxus
Wasm untuk frontend dulu bermasalah karena kurangnya tool dasar seperti pemecahan bundle, hot reload, simbol debugging, dan integrasi aset
Pada 2025, banyak hal ini telah diperbaiki, dan integrasi dengan alat seperti Vite juga membaik
Berkat alat AI, kecepatan pengembangan Rust juga meningkat, dan saya berharap framework Wasm akan mendapat lebih banyak perhatian ke depannya
Ada kritik bahwa ukuran biner Wasm terlalu besar
Di lingkungan DSL, unduhannya bisa memakan waktu beberapa detik hingga beberapa menit
Klaimnya, JS lebih kecil dan bisa dijalankan saat proses unduh berlangsung
Jika dibangun dengan Rust, ukurannya bisa ditekan ke kisaran 10~100KB
JS tidak dieksekusi selama pengunduhan, sedangkan Wasm bisa mulai lebih cepat lewat streaming compilation
Ini sama saja dengan mengimplementasikan ulang fungsi yang sebenarnya sudah disediakan browser
Misalnya, FSHistory mengimplementasikan emulasi x86 hanya dengan 24KB
Hanya saja, ekosistem native memang tidak terbiasa mengoptimalkan ukuran kode
Pernyataan di artikel bahwa “tidak ada situs web besar yang dibuat dengan Wasm” berbeda dengan pengalaman saya
Tujuan proyek Wasm memang bukan untuk menggantikan seluruh web app
Sepertinya orang-orang memiliki ekspektasi yang keliru lalu bertanya, “mengapa itu tidak terjadi?”
Saya benar-benar telah menerapkan Wasm dalam berbagai kasus penggunaan nyata
Itu bisa ditangani dengan memotong hanya bagian yang dibutuhkan di backend