Mengoptimalkan Interaksi DOM dari WebAssembly: Strategi untuk UI Berkinerja Tinggi

1. Pendahuluan

WebAssembly (Wasm) telah membuka gerbang performa native di browser, memungkinkan kita menjalankan kode yang ditulis dalam bahasa seperti Rust, C++, atau Go dengan kecepatan mendekati aplikasi desktop. Ini luar biasa untuk komputasi berat, pemrosesan grafis, atau bahkan game. Tapi bagaimana dengan antarmuka pengguna (UI)? Bisakah kita menggunakan WebAssembly untuk membangun UI yang super cepat dan responsif, terutama ketika berinteraksi dengan Document Object Model (DOM)?

Jawabannya adalah: bisa, tapi ada tantangannya! ⚠️

Meskipun WebAssembly unggul dalam komputasi murni, ia tidak memiliki akses langsung ke DOM. Semua interaksi dengan DOM harus melalui JavaScript. Ini menciptakan sebuah “jembatan” antara lingkungan Wasm yang berkinerja tinggi dan lingkungan JavaScript yang berinteraksi dengan DOM. Setiap kali data atau perintah melewati jembatan ini, ada biaya (overhead) yang timbul. Jika kita tidak hati-hati, overhead ini bisa mengikis semua keuntungan performa yang dijanjikan Wasm.

Artikel ini akan membawa Anda menyelami strategi praktis untuk mengoptimalkan interaksi DOM dari WebAssembly, memungkinkan Anda membangun UI yang responsif dan berkinerja tinggi. Kita akan membahas mengapa interaksi ini mahal dan bagaimana pola desain cerdas dapat membantu kita meminimalkan biaya tersebut.

2. Memahami Batasan dan Biaya Interaksi JS-Wasm

Seperti yang disebutkan, WebAssembly berjalan dalam sandbox yang terisolasi dan tidak memiliki akses langsung ke DOM, objek JavaScript, atau API browser lainnya. Ia hanya dapat berinteraksi dengan “dunia luar” melalui fungsi-fungsi yang diekspor dari JavaScript ke Wasm, atau fungsi-fungsi yang diekspor dari Wasm yang kemudian dipanggil oleh JavaScript.

Setiap kali Anda memanggil fungsi dari JavaScript ke Wasm, atau sebaliknya, ada beberapa biaya yang terjadi:

1. Overhead Panggilan Fungsi (Call Overhead): Setiap panggilan lintas batas (JS-Wasm atau Wasm-JS) memiliki sedikit biaya. Biaya ini kecil per panggilan, tetapi bisa menumpuk jika Anda melakukan ribuan panggilan dalam satu frame animasi.
2. Biaya Serialisasi/Deserialisasi Data: Parameter dan nilai kembalian harus dikonversi antara tipe data Wasm (integer, float) dan tipe data JavaScript (string, object, array). Misalnya, string di Wasm disimpan sebagai array byte di memori Wasm, dan perlu dikonversi ke string JavaScript (UTF-8 decoding) saat melewati batas. Proses ini memakan waktu dan memori.
3. Akses Memori: WebAssembly beroperasi pada blok memorinya sendiri (WebAssembly Linear Memory). Jika Anda perlu memanipulasi data di memori Wasm dari JavaScript, atau sebaliknya, Anda harus mengakses WebAssembly.Memory sebagai ArrayBuffer atau TypedArray dan kemudian membaca/menulis data. Ini juga memiliki biaya.

Bayangkan Anda ingin mengubah warna 1000 elemen DOM. Jika Wasm memanggil fungsi JavaScript 1000 kali, masing-masing dengan ID elemen dan warna baru, biayanya akan jauh lebih tinggi daripada jika JavaScript melakukan itu sendiri secara langsung. ❌

🎯 Tujuan kita adalah meminimalkan “perjalanan” bolak-balik melintasi jembatan JS-Wasm dan meminimalkan jumlah data yang dipertukarkan dalam setiap perjalanan.

3. Strategi #1: Meminimalkan Panggilan Lintas Batas (Batching & Virtual DOM)

Strategi paling fundamental adalah mengurangi frekuensi interaksi antara Wasm dan JavaScript.

a. Batching DOM Operations

Daripada mengirim instruksi satu per satu, kumpulkan semua perubahan DOM yang diperlukan dalam satu batch (paket), lalu kirimkan ke JavaScript dalam satu panggilan.

💡 Contoh Konkret: Misalnya, Anda memiliki algoritma di Wasm yang menghitung posisi baru untuk ratusan elemen. Daripada Wasm memanggil updateElementPosition(id, x, y) ratusan kali, Wasm bisa mengumpulkan semua perubahan ini ke dalam sebuah struktur data (misalnya, array of objects atau array of numbers) di memori Wasm. Kemudian, dalam satu panggilan ke JavaScript, Wasm hanya perlu memberitahu JavaScript di mana data ini berada di memori. JavaScript kemudian membaca seluruh batch perubahan dan menerapkannya ke DOM.

// Contoh di Rust (Wasm)
#[wasm_bindgen]
pub struct DomUpdate {
    // Representasi perubahan DOM
    id: u32,
    x: f32,
    y: f32,
}

// Bayangkan ini adalah list dari perubahan DOM yang dihitung di Wasm
static mut CHANGES: Vec<DomUpdate> = Vec::new();

#[wasm_bindgen]
pub fn calculate_and_get_dom_changes() -> Box<[DomUpdate]> {
    // Lakukan perhitungan di sini dan isi CHANGES
    // ...
    unsafe {
        let changes_box: Box<[DomUpdate]> = CHANGES.drain(..).collect::<Vec<_>>().into_boxed_slice();
        changes_box
    }
}

// JavaScript
import { calculate_and_get_dom_changes } from './wasm_module.js';

function applyDomChanges() {
    // Wasm mengembalikan array objek atau struktur data yang bisa dibaca JS
    const changes = calculate_and_get_dom_changes(); // Ini adalah satu panggilan Wasm-JS
    
    // Iterasi dan terapkan perubahan di JavaScript
    for (const change of changes) {
        const element = document.getElementById(change.id);
        if (element) {
            element.style.left = `${change.x}px`;
            element.style.top = `${change.y}px`;
        }
    }
    // Perubahan DOM hanya terjadi di sisi JS, dan hanya satu kali panggilan Wasm.
}

// Panggil ini di requestAnimationFrame untuk UI yang smooth
requestAnimationFrame(applyDomChanges);

b. Virtual DOM dalam WebAssembly

Pola Virtual DOM (VDOM) yang populer di React atau Vue juga bisa diterapkan dengan WebAssembly. Ide utamanya:

1. Wasm mengelola representasi VDOM: WebAssembly tidak memanipulasi DOM asli, melainkan membangun dan memperbarui struktur data internal yang merepresentasikan DOM (seperti objek JavaScript polos).
2. Wasm menghitung “diff”: Ketika ada perubahan state, Wasm menghitung perbedaan (diff) antara VDOM lama dan VDOM baru. Hasilnya adalah daftar operasi DOM minimal yang diperlukan (misalnya, “tambah elemen ini”, “hapus elemen itu”, “ubah atribut ini”).
3. JavaScript menerapkan “patch”: Daftar operasi ini kemudian dikirim ke JavaScript dalam satu panggilan. JavaScript bertanggung jawab untuk menerapkan “patch” ini ke DOM asli secara efisien.

✅ Manfaat:

• Hanya satu panggilan Wasm-JS per frame (atau per batch perubahan).
• Data yang ditransfer adalah daftar operasi yang minimal, bukan seluruh VDOM.
• Wasm dapat fokus pada logika UI dan manajemen state, sementara JavaScript menangani interaksi DOM yang sebenarnya.

Beberapa framework UI Wasm seperti Yew (Rust) menggunakan pola ini secara ekstensif.

4. Strategi #2: Menggunakan Struktur Data Bersama (Shared Memory & Transferable Objects)

Untuk transfer data yang lebih efisien, kita bisa memanfaatkan fitur-fitur yang dirancang untuk skenario performa tinggi.

a. Shared WebAssembly Linear Memory

WebAssembly Linear Memory, saat di-instantiate, diakses oleh JavaScript sebagai ArrayBuffer. Ini berarti JavaScript dan Wasm dapat membaca dan menulis ke blok memori yang sama.

📌 Tips Praktis:

• Wasm menulis, JS membaca: Wasm bisa menulis data ke lokasi tertentu di memorinya, lalu JavaScript membaca data langsung dari ArrayBuffer tersebut tanpa perlu serialisasi/deserialisasi eksplisit di setiap panggilan. Wasm hanya perlu memberitahu JavaScript “data dimulai di offset X, panjang Y”.
• Hindari string: Ganti string dengan ID numerik atau enum jika memungkinkan untuk mengurangi biaya transfer. Jika harus menggunakan string, tulis string ke memori Wasm sebagai UTF-8 byte array dan berikan offset/panjangnya ke JavaScript.

// Rust (Wasm) - Menulis data ke memori Wasm
#[wasm_bindgen]
pub fn update_element_data(offset: u32, value: u32) {
    // Asumsi kita punya memori Wasm yang bisa diakses JS
    // Tulis `value` ke `offset` di memori
    // (Implementasi detail akan melibatkan `std::slice::from_raw_parts_mut` atau sejenisnya)
}

// JavaScript - Membaca/Menulis dari memori Wasm
import * as wasm from './wasm_module.js';

const memory = wasm.memory; // Ini adalah WebAssembly.Memory object
const u32_view = new Uint32Array(memory.buffer);

function updateFromWasm(offset, value) {
    wasm.update_element_data(offset, value); // Wasm menulis ke memori
    // Kita bisa membaca langsung dari memori setelah itu
    console.log("Value in Wasm memory:", u32_view[offset / 4]); // Karena Uint32Array, offset dibagi 4
}

b. Transferable Objects (dengan Web Workers)

Jika Anda memindahkan komputasi berat ke Web Workers (yang sangat direkomendasikan untuk Wasm agar tidak memblokir main thread), Transferable Objects adalah kunci performa. ArrayBuffer adalah Transferable Object.

Ketika Anda mengirim ArrayBuffer sebagai Transferable Object antara main thread dan Web Worker, data tersebut dipindahkan (bukan disalin) dari satu thread ke thread lain. Ini jauh lebih cepat daripada menyalin data besar.

// Main Thread
const worker = new Worker('worker.js');
const myData = new Uint8Array([1, 2, 3, 4, 5]);

// Kirim myData ke worker sebagai Transferable
worker.postMessage({ data: myData.buffer }, [myData.buffer]);

// myData sekarang "kosong" di main thread, kepemilikan dipindahkan ke worker
console.log(myData.length); // Output: 0

// worker.js
self.onmessage = (e) => {
    const dataBuffer = e.data.data; // Ini adalah ArrayBuffer yang dipindahkan
    const myData = new Uint8Array(dataBuffer);
    console.log("Received in worker:", myData); // Output: Uint8Array [1, 2, 3, 4, 5]
    // Lakukan komputasi Wasm dengan data ini
    // ...
    // Kirim kembali hasilnya, juga sebagai transferable jika perlu
    self.postMessage({ result: dataBuffer }, [dataBuffer]);
};

Penggunaan SharedArrayBuffer dan Atomics juga memungkinkan memori dibagi dan diakses secara bersamaan oleh beberapa thread (Wasm dan JavaScript di Web Workers), namun ini lebih kompleks dan memerlukan penanganan konkurensi yang hati-hati.

5. Strategi #3: Delegasi Event dan Pengelolaan State di Wasm

Untuk UI yang interaktif, pengelolaan event dan state sangat penting.

a. Delegasi Event di JavaScript

Daripada mendaftarkan banyak event listener di Wasm (yang berarti banyak panggilan Wasm-JS), biarkan JavaScript menangani event DOM dan hanya memberitahu Wasm tentang event yang relevan.

💡 Contoh Konkret: Jika Anda memiliki daftar item yang bisa diklik, pasang satu event listener click di elemen induk (misalnya, <ul>) di JavaScript. Ketika event terjadi, JavaScript akan mengetahui target elemen yang diklik dan mengirimkan informasi yang relevan (misalnya, ID item) ke Wasm dalam satu panggilan. Wasm kemudian bisa memperbarui state internalnya.

// JavaScript
document.getElementById('my-list').addEventListener('click', (event)