Menjajaki batas performa browser dengan WebAssembly dan WebGPU: menjalankan kode near-native di browser, akselerasi GPU untuk komputasi berat, kasus penggunaan nyata, dan eksperimen pertama yang bisa kalian coba

JavaScript sudah kuat, tetapi ada kelas pekerjaan yang tidak bisa dijawabnya sendirian: memproses gambar jutaan piksel, menjalankan model AI di klien, game 3D, editing video di browser. Episode 21 membuka cakrawala itu: WebAssembly (WASM) untuk komputasi near-native dan WebGPU untuk memanfaatkan GPU.
Mengapa frontend developer perlu tahu ini di 2026? Karena batas "apa yang bisa dilakukan browser" terus mundur — dan kemampuan menjalankan beban berat di klien mengubah keputusan arsitektur: alih-alih selalu mengirim semuanya ke server, sebagian bisa dikerjakan di perangkat pengguna (lebih cepat, lebih privat).
WebAssembly adalah format bytecode yang dijalankan browser dengan kecepatan mendekati native. Posisinya komplementer, bukan pengganti JavaScript: JS tetap jadi bahasa "perekat" untuk UI, sedangkan WASM menjalankan beban komputasi.
Kode C/C++/Rust dikompilasi menjadi WASM, lalu dipanggil dari JS. Browser mengeksekusi WASM dalam sandbox (aman) dengan kecepatan hampir setara native.
| Domain | Contoh di Produksi |
|---|---|
| Pengolahan media | Compress/resize gambar, transcode video |
| Kreator & dokument | Figma, AutoCAD web (berat banget untuk JS) |
| Game | Porting game C++/Unity ke web |
| AI/ML | Jalankan model di klien (offline, privat) |
| Komputasi ilmiah | Simulasi, kriptografi, encoding |
Fitur kunci untuk aplikasi besar: threads (SharedArrayBuffer) dan akses memori langsung — kemampuan yang tidak dimiliki JS murni.
WebGPU adalah API modern untuk komputasi GPU dan rendering 3D — penerus WebGL yang jauh lebih mampu dan lebih dekat ke API native (Vulkan/Metal/DX12).
async function initGPU() {
if (!navigator.gpu) {
throw new Error("WebGPU tidak didukung browser ini");
}
const adapter = await navigator.gpu.requestAdapter();
const device = await adapter!.requestDevice();
return device;
}GPU mengeksekusi ribuan operasi paralel — ideal untuk pengolahan piksel, fisika, dan inferensi model. Kasus ringan yang bisa kalian jumpai: filter gambar, blur, atau efek visual.
Note
WebGPU dan WASM sering dipakai bersama: WASM mengatur logika (mis. memparsing format file), GPU mengeksekusi komputasi paralel. Keduanya memperluas "apa yang bisa dilakukan browser" — bukan mengubah cara kalian menulis UI sehari-hari.
Jalankan module WASM sederhana dari Rust (atau bahasa lain) — praktik ini bisa diikuti di repo eksperimen kalian sendiri:
cargo install wasm-pack
cargo new --lib wasm-demo#[no_mangle]
pub extern "C" fn add(a: i32, b: i32) -> i32 {
a + b
}wasm-pack build --target webimport init, { add } from "./pkg/wasm_demo.js";
await init();
console.log("2 + 3 =", add(2, 3)); // 5Contoh yang lebih bermakna untuk TokoKita: pindahkan pemrosesan kompresi gambar produk ke WASM — gambar yang diresize/compress di klien menghemat bandwidth (mendukung episode 12) tanpa mengirim file raksasa ke server.
| Kesalahan | Dampak | Perbaikan |
|---|---|---|
| WASM untuk semua hal | Overhead & kompleksitas tak perlu | JS dulu, WASM saat terbukti lambat |
| Abaikan ukuran module | Bundle membengkak | Bangun per-feature, lazy load |
| Mengabaikan dukungan browser | Aplikasi rusak diam-diam | Feature detection + fallback |
| WebGPU tanpa fallback | User browser lama blank | Deteksi + pesan jelas |
| Komputasi berat di main thread | UI membeku | WASM threads / Web Worker |
Inti yang harus dibawa pulang:
Di episode 22 selanjutnya kita membuat TokoKita bisa dipakai tanpa koneksi: PWA & offline first — service workers, installability, dan strategi offline yang solid. Sampai jumpa di episode 22!