- WebAssembly (Wasm) vẫn đang được sử dụng như một công nghệ cốt lõi trong nhiều sản phẩm thực tế khác nhau, và đóng vai trò quan trọng trong engine game, công cụ thiết kế, web container
- Bản thân ngôn ngữ này có cấu trúc ánh xạ hiệu quả lên phần cứng, và được thiết kế xoay quanh tính an toàn và tính di động
- Mô hình bảo mật có cấu trúc “deny-by-default”, cho phép cô lập ở cấp tiến trình và tốc độ thực thi nhanh
- Nó được ứng dụng trong nhiều môi trường thông qua hệ sinh thái plugin và hỗ trợ đa ngôn ngữ, nhưng vẫn chưa được chấp nhận ở mức thay thế toàn bộ trình duyệt
- Hiện tại, WebAssembly đã được tích hợp sâu ở cấp thư viện và runtime, và là một công nghệ đang được tiêu chuẩn hóa cũng như mở rộng tính năng rất nhanh
Các trường hợp sử dụng thực tế
- WebAssembly đảm nhiệm các chức năng cốt lõi trong Godot, Figma, Stackblitz, Squoosh.app, Zellij, Ruffle
- Godot dùng cho bản dựng game trên web, còn Figma dùng để chuyển đổi mã C++ sang dạng có thể chạy trong trình duyệt
- Stackblitz sử dụng Wasm cho web container, còn Ruffle khai thác Wasm như một trình giả lập Flash
- Tuy nhiên, rất hiếm các trang web quy mô lớn được xây dựng hoàn toàn trên nền Wasm; phần lớn chỉ sử dụng ở cấp tính năng cụ thể
Định nghĩa và tốc độ của WebAssembly
- WebAssembly là một ngôn ngữ (language), và khái niệm tốc độ không nằm ở bản thân nó mà phụ thuộc vào hiệu năng của engine
- Giống như JavaScript, runtime engine (V8, SpiderMonkey, v.v.) quyết định tốc độ thực thi
- WebAssembly có cấu trúc ánh xạ hiệu quả lên phần cứng hiện đại, và có thể được biên dịch hoặc thông dịch
Cấu trúc ánh xạ hiệu quả
- Wasm là bytecode gần với hợp ngữ, có thể được biên dịch lên hầu hết phần cứng mà không bị suy hao
- WAT (WebAssembly Text) là biểu diễn dạng văn bản của Wasm, gần như có thể chuyển đổi 1:1
- Nó tương tự bytecode của JVM, nhưng API nhỏ hơn và đảm bảo an toàn mạnh hơn
- Truy cập bộ nhớ là tường minh, và chỉ có thể sử dụng các tài nguyên được môi trường host cho phép
Wasm như một đích biên dịch
- Nhiều ngôn ngữ như Rust, C, Zig, Go, Kotlin, Java, C# có thể được biên dịch sang Wasm
- Các ngôn ngữ thông dịch như Python, PHP, Ruby cũng có thể chạy bằng bản dựng Wasm
- Trình duyệt mặc định đã tích hợp engine Wasm, và cũng có các runtime độc lập như Wasmtime, WasmEdge, Wasmer
- Một artifact Wasm duy nhất có thể chạy độc lập với phần cứng
Cấu trúc bảo mật và ứng dụng
- WebAssembly áp dụng mô hình bảo mật “deny-by-default”, chỉ cho phép truy cập bên ngoài thông qua import được khai báo tường minh
- Ngăn xếp luồng điều khiển ẩn, bộ nhớ tuyến tính, tập lệnh bị giới hạn mang lại khả năng cô lập mạnh
- Cloudflare dùng V8 isolate để cô lập việc thực thi mã dựa trên Wasm, còn Fermyon cung cấp thời gian khởi động ở mức dưới mili giây
- Ruffle khôi phục nội dung Flash một cách an toàn, Pyodide chạy Python bằng Wasm, còn Figma chạy plugin bằng QuickJS dựa trên Wasm
Tính di động và khả năng nhúng
- Runtime Wasm khá gọn nhẹ, và Zellij, Envoy, Lapce đã áp dụng Wasm cho hệ thống plugin
- Ngay cả trong môi trường có JavaScript engine, vẫn có thể dùng nhiều thư viện Wasm cho xử lý ảnh, OCR, engine vật lý, render, bộ công cụ media, cơ sở dữ liệu, parser
- Trong phần lớn trường hợp, người dùng không hề nhận ra mình đang dùng Wasm, vì nó hoạt động một cách trong suốt bên trong thư viện
Xem xét lại về tốc độ và kích thước
- Trình duyệt chạy Wasm bằng cùng pipeline với JS, nên vẫn tồn tại giới hạn hiệu năng do cấu trúc engine
- Hiệu quả có thể khác nhau tùy theo hệ thống kiểu của ngôn ngữ và mức độ tối ưu của compiler
- Chi phí ở ranh giới giữa host và chương trình cùng với việc tăng kích thước nhị phân được xem là nhược điểm
- Chuẩn WASI đang cố giảm bớt vấn đề này, nhưng việc chuẩn hóa kiểu chuỗi vẫn chưa hoàn tất
- Zig tạo ra nhị phân Wasm nhỏ nhất
- Trong môi trường native, hiệu năng có thể giảm do threading, IO, mức dùng bộ nhớ
Xu hướng phát triển ngôn ngữ và tiêu chuẩn
- Việc tiêu chuẩn hóa Wasm đang được thúc đẩy song song bởi nhóm làm việc W3C và Bytecode Alliance
- Bên sau đang dẫn dắt phát triển theo hướng công cụ như WIT, Component Model
- Các đề xuất tính năng mới đang được chấp nhận rất nhanh, và ở một số nơi vẫn có tranh luận về tốc độ cũng như định hướng
- Wasm đang lan rộng như một công nghệ tích hợp nội bộ hơn là để thay thế JavaScript
- Các framework như Blazor, Leptos sử dụng Wasm mà không cần trực tiếp xử lý JS
- Hiện tại, Wasm chủ yếu được các tác giả thư viện áp dụng, và lập trình viên thông thường vẫn có thể sử dụng mà không cần nhận biết cơ chế bên trong
- Tính khó tiếp cận của tài liệu học tập được xem là một rào cản, và các dự án học tập như
watlings đã được giới thiệu
1 bình luận
Ý kiến trên Hacker News
Tôi nghĩ Wasm đã đạt được phần lớn các mục tiêu đề ra khi nó được tạo ra
Cá nhân tôi đã dùng Wasm làm thành phần cốt lõi trong hàng chục dự án
Engine JS rất nhanh, nhưng Wasm vẫn cho mức độ kiểm soát CPU cao hơn và hiệu năng rất xuất sắc
Tuy vậy, nó đã không đáp ứng được kỳ vọng rằng sẽ thay thế hoàn toàn JS+HTML+CSS. Tôi cho rằng lý do lớn là thiếu DOM binding
Tôi cũng đã dùng các framework Wasm như Yew, nhưng cảm giác giống như một lớp chắp thêm khá gượng gạo lên trên JS
Tôi chưa dùng Blazor, nhưng tôi vẫn thấy viết bằng JS thoải mái hơn
Dù vậy, Wasm đang âm thầm chạy ở rất nhiều nơi, và tôi nghĩ đó mới là bằng chứng của thành công thực sự
Ví dụ, tính năng điều chỉnh tốc độ âm thanh trong trình duyệt đạt được mức hiệu năng chỉ có thể có khi chạy thư viện C++ bằng Wasm
Chỉ cần có DOM binding đúng nghĩa thì JS sẽ bị đẩy khỏi frontend trong vòng 10 năm
C# giúp chia sẻ code giữa backend và frontend dễ dàng, và template Razor cũng có hỗ trợ IDE tốt
Nhưng vì phải mang theo toàn bộ .NET CLR và BCL nên kích thước bundle rất lớn
Do khó truy cập DOM, Blazor dùng kiến trúc đặt một renderer Virtual DOM nhỏ ở phía JS
Hiệu năng ổn, nhưng vẫn chậm hơn JS viết tay
Bolero dựa trên F# cũng thú vị, nhưng khó thuyết phục cả team
Muốn tương tác với DOM thì cần một ngôn ngữ bậc cao phù hợp cho việc đó
JS làm tốt vai trò này, và bộ ba HTML/CSS/JS đã trở thành ngôn ngữ chung của phát triển UI
Cũng có những nỗ lực bỏ qua browser rendering để chuyển sang nền tảng canvas, nhưng đó vẫn chỉ là thị trường ngách
Một thế giới mà ngay cả website đơn giản cũng phải tải về runtime nặng vài MB thì thật kinh khủng
Nguyên nhân thực sự của sự chậm chạp không phải JS mà là DOM. Rốt cuộc thì vẫn phải tương tác với DOM
Tôi đã làm việc với WebAssembly trong vài năm và sắp công bố một framework dựa trên Wasm
Hệ sinh thái từng phát triển rất nhanh rồi đột nhiên chững lại, trong khi việc đưa vào WASI và Component Model lại gây thêm hỗn loạn
Mức hỗ trợ khác nhau giữa các engine khiến nhiều lúc phải lần mò qua lại giữa tài liệu, code và issue
Vấn đề lớn nhất là hỗ trợ JS/TS. Hiện tại cách tích hợp này gần như là một kiểu hack, nên không ổn định
Web Containers đã mang lại một số cải thiện, nhưng đã có nhiều lập trình viên chuyển sang Bun
Tiềm năng của Wasm là cực kỳ lớn
Về lý thuyết, nó có thể trở thành mục tiêu biên dịch chung cho mọi nền tảng
Nhưng thực tế chỉ dừng ở mức làm một vài tính năng của Figma chạy nhanh hơn, nên khá đáng thất vọng
Cấu trúc phát triển theo kiểu ủy ban cũng là giới hạn vì tiến độ quá chậm
Thời Native Client đã có thể làm app chạy ở tốc độ native, còn Wasm hiện giờ lại chậm hơn
Đáng lẽ cấu trúc JS binding cũng có thể áp dụng cho Wasm
Hơn nữa, Wasm cũng không nhanh hơn JS
HTML/CSS/JS đã chứng minh được tính hữu dụng, còn Wasm vẫn là một stack công nghệ xa lạ
Hệ sinh thái xoay quanh Docker đang cản trở tiến triển
Nhiều công cụ build trong hệ sinh thái JS được viết bằng Rust, và một số còn chạy trong trình duyệt bằng Wasm
React và hệ sinh thái npm cũng dùng Wasm ở bên trong
Nếu Wasm biến mất thì thế giới frontend JS sẽ bị rung chuyển mạnh
Tuy vậy, các native Wasm UI framework vẫn còn rất thiếu
Chúng vẫn phải phụ thuộc vào DOM và CSS, đồng thời phải truy cập browser API thông qua JS nên kém hiệu quả
Có thể điều khiển DOM bằng Rust hoặc Kotlin, nhưng Rust lại quá thấp cấp cho frontend
Cross-compile cho di động đang tăng dần, và JetBrains Compose Multiplatform là một ví dụ
Thứ cản trở sự phát triển của Wasm là tooling
Việc debug vẫn chỉ ở mức
printf, và plugin DWARF của Chrome cũng đã lâu không được cập nhậtQuá trình tạo file .wasm và thiết lập import/export cho từng ngôn ngữ rất phức tạp
Hỗ trợ GC cũng chưa hoàn chỉnh nên các hệ sinh thái như .NET phải tự mang theo GC riêng
WIT trông giống như một nỗ lực COM/CORBA/gRPC khác
Emscripten phức tạp và thiếu ổn định, còn wasi-sdk thì thiếu tính năng
Cả LLVM lẫn các engine đều tối ưu hóa chưa tốt, và tooling Wasm của Rust thực tế cũng gần như bị bỏ ngỏ
Thậm chí còn chưa có cách import module Wasm từ JS theo kiểu tiêu chuẩn
Hỗ trợ multithread cũng cần thiết lập header COOP/COEP nên không thể dùng trên GitHub Pages
Nếu tooling đã vượt qua mức “bản demo công nghệ”, nó hẳn đã được dùng nhiều hơn rất nhiều
Công ty chúng tôi, Leaning Technologies, sử dụng Wasm rất tích cực
Với WebVM, chúng tôi chạy binary x86 trong trình duyệt;
với BrowserCraft, chúng tôi chạy ứng dụng Java (bao gồm cả Minecraft);
và với BrowserPod, chúng tôi chạy container Node.js trong trình duyệt
Nó rất mạnh, nhưng là công cụ dành cho power user. Biên dịch logic frontend thông thường sang Wasm thì không hiệu quả
Tốc độ phát triển của CheerpJ rất ấn tượng, và có ý kiến cho rằng nếu nó xuất hiện sớm hơn 10 năm thì nền tảng web đã khác đi
Với những người không thích JS, việc tạo ra website không có JS mới chính là sức hút thật sự của Wasm
Tôi làm việc tại Dioxus, một framework Wasm dựa trên Rust
Vấn đề của Wasm frontend trước đây là thiếu các công cụ cơ bản như chia tách bundle, hot reload, debug symbol, tích hợp asset
Trong năm 2025, chúng tôi đã cải thiện đáng kể những điểm này, và việc tích hợp với các công cụ như Vite cũng tốt hơn
Nhờ các công cụ AI, tốc độ phát triển bằng Rust cũng đã nhanh hơn, và tôi kỳ vọng các framework Wasm sẽ được chú ý nhiều hơn trong tương lai
Có ý kiến cho rằng kích thước nhị phân của Wasm quá lớn
Trong môi trường DSL, việc tải xuống có thể mất từ vài giây đến vài phút
Lập luận là JS nhỏ hơn và còn có thể thực thi ngay trong lúc đang tải
Nếu build bằng Rust thì có thể giảm xuống mức 10~100KB
JS không thực thi trong lúc tải xuống, còn Wasm có thể khởi động nhanh hơn nhờ biên dịch streaming
Điều đó đồng nghĩa với việc triển khai lại những gì trình duyệt vốn đã cung cấp
Ví dụ, FSHistory triển khai giả lập x86 chỉ với 24KB
Chỉ là hệ sinh thái native vốn không quen với việc tối ưu kích thước code
Câu trong bài rằng “không có website lớn nào được làm bằng Wasm” không giống với trải nghiệm của tôi
Mục tiêu của các dự án Wasm vốn không phải là thay thế toàn bộ web app
Có vẻ mọi người đã đặt kỳ vọng sai rồi lại hỏi “tại sao chuyện đó không xảy ra”
Tôi thực sự đã áp dụng Wasm trong nhiều trường hợp thực tế
Có thể xử lý bằng cách cắt ra đúng phần cần thiết ở backend