WebAssembly là gì? Đừng dùng Wasm nếu bạn chưa hiểu 3 Trade-offs này

Khi nghe đến WebAssembly (Wasm), hầu hết các Developer đều nghe cùng một lời hứa hẹn: "Nó giúp chạy code C++/Rust trên trình duyệt với tốc độ gần như Native."

Nhưng nếu chỉ đọc những lời "quảng cáo" đó, rất có thể bạn sẽ rơi vào cái bẫy lớn: Cố gắng đưa Wasm vào mọi dự án React/Vue với kỳ vọng giao diện sẽ tự động "nhanh gấp 10 lần". Thực tế hoàn toàn ngược lại. Nếu dùng sai cách, Wasm thậm chí còn làm ứng dụng của bạn chậm hơn cả JavaScript thuần.

Bài viết này sẽ giải mã bản chất thực sự của WebAssembly, lý do nó ra đời, và quan trọng nhất: Khung tư duy (Mental Model) để bạn biết chính xác khi nào nên dùng và khi nào KHÔNG nên dùng Wasm trong thực tế.

1. Vấn đề thực sự: JavaScript Engine đang bị quá tải

Để hiểu lý do Wasm xuất hiện, chúng ta cần nhìn lại cách JavaScript (JS) vận hành.

Nhiều năm qua, các JS Engine như V8 (Chrome) hay SpiderMonkey (Firefox) đã phát triển vượt bậc nhờ công nghệ JIT (Just-In-Time) Compilation. Tuy nhiên, về bản chất, JavaScript vẫn là một ngôn ngữ có kiểu dữ liệu động (Dynamically Typed) và thông dịch (Interpreted).

Một luồng xử lý JS điển hình trên trình duyệt trải qua 4 bước:

[ JS Source Code ] 
       ↓ 
[ Parse → AST ]  (Tốn thời gian đọc & phân tích văn bản)
       ↓ 
[ Interpreter ]  (Tạo Bytecode)
       ↓ 
[ JIT Compiler ] (Biên dịch tối ưu dựa trên dự đoán Type)
       ↓ 
[ Machine Code ]

Nút thắt cổ chai (Bottlenecks) nằm ở đâu?

• Chi phí Parsing/Compiling lớn: Trình duyệt phải tải toàn bộ file text JS về, phân tích thành cây cú pháp (AST) rồi mới biên dịch. File JS càng nặng, Main Thread càng bị block.
• Rủi ro De-optimization: Engine JIT giả định một biến luôn là Number. Nếu trong lúc chạy, bạn đột ngột truyền vào một String, JIT sẽ vứt bỏ bản compiled code tối ưu đó và quay lại bước thông dịch ban đầu (De-optimization).
• Garbage Collection (GC) Pause: Bạn không thể kiểm soát khi nào GC chạy. Trong các ứng dụng xử lý đồ họa hay Game 60fps, một đợt GC ngắt đột ngột sẽ gây ra hiện tượng khựng/lag (Stuttering).

Khi người dùng muốn chạy các phần mềm phức tạp như Figma, Photoshop, Canva hay game 3D ngay trên trình duyệt, JavaScript đơn thuần chạm trán giới hạn về mặt kiến trúc.

2. Core Concept: WebAssembly là gì?

WebAssembly (Wasm) là một định dạng mã nhị phân cấp thấp (low-level binary format) được thiết kế để thực thi trên một máy ảo dạng Stack (Stack-based Virtual Machine).

Hãy hình dung Wasm không phải là một ngôn ngữ lập trình mới để thay thế JS, mà là một Compilation Target (đích đến biên dịch).

C++ / Rust / Go / Zig Code
          ↓  (Dùng LLVM / Compiler)
     .wasm Binary File
          ↓  (Browser Fetch & Instant Instantiate)
    Native Machine Code (CPU)

Mental Model đơn giản

Hãy coi ứng dụng Web của bạn như một ngôi nhà:

• JavaScript là đội ngũ Trang trí & Nội thất (Linh hoạt, dễ thay đổi, giỏi tương tác với môi trường xung quanh - DOM/Events).
• WebAssembly là chiếc Máy tính công nghiệp đặt ở góc phòng (Chỉ tập trung xử lý các phép toán siêu nặng, không biết trang trí nhà cửa, nhưng tính toán con số thì nhanh gấp hàng chục lần người thường).

3. Tại sao WebAssembly lại cực kỳ nhanh?

Wasm đạt tốc độ tiệm cận Native nhờ bỏ qua hầu hết các điểm yếu của JS:

1. Kích thước nhỏ & Fetch nhanh: File .wasm là bytecode nhị phân, đã được tối ưu dung lượng từ lúc build ở máy dev, nhỏ hơn rất nhiều so với file text .js.
2. Không mất thời gian Parse: Trình duyệt không cần tạo AST. Bytecode của Wasm được thiết kế để trình duyệt có thể vừa tải về vừa biên dịch thẳng ra Machine Code (WebAssembly.instantiateStreaming).
3. Mã hóa tĩnh (Statically Typed): Mọi kiểu dữ liệu đều được xác định rõ ràng từ đầu (i32, f64). Không có hiện tượng De-optimization.
4. Tự quản lý bộ nhớ (Linear Memory): Wasm không dùng Garbage Collector (ngoại trừ chuẩn WasmGC gần đây cho một số ngôn ngữ cấp cao). Bộ nhớ của Wasm là một mảng byte liên tục (ArrayBuffer), do lập trình viên (hoặc compiler C++/Rust) chủ động allocate/free.

4. Bức tranh kịch bản: Khi nào nên và KHÔNG nên dùng?

Đây là phần quan trọng nhất dưới góc độ kiến trúc. Chi phí tích hợp Wasm không hề rẻ, nên việc ra quyết định cần dựa trên bài toán cụ thể.

🛑 3 Trade-offs lớn bạn PHẢI biết trước khi dùng Wasm:

1. Boundary Crossing Overhead (Chi phí vượt rào): Wasm không thể trực tiếp thao tác với DOM. Muốn đổi màu một cái button, Wasm phải truyền dữ liệu qua cầu nối JavaScript. Việc serialization/deserialization dữ liệu qua lại giữa JS và Wasm cực kỳ tốn chi phí. Nếu ứng dụng của bạn gọi Wasm liên tục hàng ngàn lần mỗi giây chỉ cho các phép tính nhỏ, nó sẽ chậm hơn JS thuần.
2. Memory Leak Risk: Vì Wasm (đặc biệt khi compile từ C/C++/Rust) quản lý bộ nhớ thủ công thông qua Linear Memory (ArrayBuffer), nếu bạn allocate bộ nhớ trong Wasm mà quên giải phóng, tab trình duyệt sẽ ngốn RAM khủng kíp cho đến khi crash.
3. Debugging khó khăn: Debug một file binary .wasm khó hơn nhiều so với việc đọc stack trace của JavaScript/TypeScript, dù hiện tại trình duyệt đã hỗ trợ Source Maps cho C++/Rust.

5. Ví dụ thực tế trong Production

Xử lý Video ngay tại Client với FFmpeg.wasm

Hãy tưởng tượng bạn làm tính năng cắt/nén video trên Web.

• Cách làm cũ (Pure JS): Tải toàn bộ video lên Server $\rightarrow$ Server chạy FFmpeg nén $\rightarrow$ Trả kết quả về Client. (Tốn tiền Server, tốn băng thông, người dùng chờ lâu).
• Cách làm hiện đại (Wasm): Dùng ffmpeg.wasm (bản C của FFmpeg được compile sang Wasm).

// Minh họa tư duy tích hợp Wasm vào JS
import { createFFmpeg, fetchFile } from '@ffmpeg/ffmpeg';

const ffmpeg = createFFmpeg({ log: true });

async function processVideo(videoFile) {
  // 1. Load Wasm binary vào Browser
  await ffmpeg.load();

  // 2. Ghi file vào bộ nhớ Linear Memory của Wasm
  ffmpeg.FS('writeFile', 'input.mp4', await fetchFile(videoFile));

  // 3. Chạy lệnh C/FFmpeg trực tiếp trên Client
  await ffmpeg.run('-i', 'input.mp4', '-vf', 'scale=640:-1', 'output.mp4');

  // 4. Đọc kết quả từ Wasm Memory ra Blob để hiển thị trên UI
  const data = ffmpeg.FS('readFile', 'output.mp4');
  const videoUrl = URL.createObjectURL(new Blob([data.buffer], { type: 'video/mp4' }));
  
  return videoUrl;
}

Tại sao kiến trúc này tối ưu? Toàn bộ quá trình encode video nặng nề diễn ra ngay trên CPU thiết bị của người dùng, tốn 0$ chi phí Server rendering và không làm nghẽn Main Thread nếu đưa Wasm vào Web Worker.

6. Common Mistakes cần tránh

• Lỗi 1: Dùng Wasm làm thuật toán đơn giản. Đừng cố biên dịch một hàm sort() hay filter() mảng vài trăm element sang Wasm. Chi phí gọi hàm vượt rào JS-Wasm sẽ nuốt chửng mọi lợi ích về tốc độ.
• Lỗi 2: Chạy Wasm trên Main Thread mà không có Web Worker. Các phép tính Wasm tốn hàng giây vẫn sẽ làm đơ (block) UI nếu bạn không đẩy nó xuống chạy ẩn dưới Web Worker.

Practical Takeaways (Hành động ngay)

1. Bạn không cần học C++/Rust ngay hôm nay: 90% nhu cầu Frontend hiện tại là sử dụng các thư viện Wasm đóng gói sẵn trên npm (ffmpeg/wasm, sql.js, tfjs-backend-wasm).
2. Nếu muốn tự viết Wasm với tư duy FE: Hãy thử AssemblyScript (Ngôn ngữ dùng cú pháp TypeScript nhưng biên dịch trực tiếp ra Wasm).
3. Quy trình chuẩn cho Performance Heavy App:

$$\text{JS (UI/Events)} \xrightarrow{\text{PostMessage}} \text{Web Worker} \xrightarrow{\text{Exec}} \text{Wasm Module}$$

Key Takeaways

1. Wasm bổ sung, không thay thế JS: JS xử lý UI và logic tương tác; Wasm gánh các bài toán tính toán nặng.
2. Thực chất là Bytecode: Wasm là file nhị phân cấp thấp, chạy trên máy ảo sandbox, đạt hiệu năng gần Native nhờ bỏ qua khâu parse văn bản và tối ưu bộ nhớ.
3. Cẩn trọng chi phí giao tiếp (Boundary Crossing): Truyền dữ liệu giữa JS và Wasm rất tốn kém. Hãy thiết kế sao cho chuyển dữ liệu 1 lần, tính toán hàng loạt trong Wasm, rồi trả về kết quả.
4. Always use Web Workers: Đưa module Wasm vào Web Worker để đảm bảo giao diện người dùng luôn mượt mà ở 60fps.
5. Chỉ dùng khi có Nút thắt hiệu năng (Performance Bottleneck): Đừng bổ sung độ phức tạp (complexity) vào hệ thống nếu các bài toán xử lý ở Client của bạn chỉ là hiển thị Form và Data cơ bản.