WebAssembly 3.0 đã chính thức ra mắt như một tiêu chuẩn mới, mang đến những tính năng quan trọng như hỗ trợ bộ nhớ 64-bit và thu gom rác. Tuy nhiên, việc phát hành này đã châm ngòi cho những cuộc thảo luận sôi nổi trong cộng đồng lập trình viên về các hình phạt hiệu suất và việc vẫn thiếu khả năng truy cập trực tiếp DOM.
Các tính năng chính của WebAssembly 3.0:
- Không gian địa chỉ 64-bit: Mở rộng từ 4GB lên 16 exabyte (web giới hạn ở 16GB)
- Đa bộ nhớ: Các module đơn lẻ có thể khai báo và truy cập nhiều đối tượng bộ nhớ
- Thu gom rác: Quản lý bộ nhớ tích hợp sẵn cho các ngôn ngữ cấp cao
- Tham chiếu có kiểu: Hệ thống kiểu dữ liệu nâng cao với phân kiểu con và đệ quy
- Tail calls: Các lời gọi hàm tiết kiệm không gian stack
- Xử lý ngoại lệ: Hỗ trợ ngoại lệ gốc trong WebAssembly
- Lệnh vector tối ưu: Các thao tác SIMD được tối ưu hóa hiệu suất
- Profile xác định: Thực thi có thể tái tạo cho các hệ thống blockchain/replay
 |
|---|
| Thông báo về WebAssembly 30, nổi bật các tính năng mới như bộ nhớ 64-bit và thu gom rác |
Bộ nhớ 64-bit đi kèm với chi phí hiệu suất
Tính năng được mong đợi nhất - không gian địa chỉ 64-bit - cho phép các ứng dụng có thể truy cập lý thuyết lên đến 16 exabyte bộ nhớ, mở rộng từ giới hạn 4 gigabyte trước đây. Đột phá này đặc biệt có lợi cho các ứng dụng chỉnh sửa video và các ứng dụng web phức tạp như Figma, xử lý các tệp với hơn một triệu lớp. Tuy nhiên, các lập trình viên đang phát hiện ra những nhược điểm hiệu suất đáng kể. Các bài kiểm tra hiệu suất ban đầu cho thấy WebAssembly 64-bit có thể chạy chậm hơn từ 10% đến 100% so với phiên bản 32-bit, với một số ứng dụng gặp phải tình trạng chậm hoàn toàn gấp 2 lần. Sự giảm hiệu suất xuất phát từ các yêu cầu kiểm tra giới hạn bổ sung mà không cần thiết trong các triển khai 32-bit, nơi các runtime có thể đơn giản phân bổ toàn bộ không gian địa chỉ 4GB.
Kiểm tra giới hạn: Một tính năng bảo mật xác minh việc truy cập bộ nhớ nằm trong giới hạn cho phép để ngăn chặn sự cố và lỗ hổng bảo mật.
So sánh Tác động Hiệu suất:
| Tính năng | Tác động Hiệu suất | Lý do |
|---|---|---|
| Bộ nhớ 64-bit | Chậm hơn 10-100% | Yêu cầu kiểm tra ranh giới bổ sung |
| Bộ nhớ 32-bit | Chuẩn | Có thể bỏ qua kiểm tra ranh giới trên máy chủ 64-bit |
| WebAssembly GC | Có khả năng nhanh hơn | Loại bỏ nhu cầu runtime GC được đóng gói |
| Đa bộ nhớ | Thay đổi | Phụ thuộc vào mẫu truy cập bộ nhớ |
Thu gom rác mở ra cánh cửa cho các ngôn ngữ cấp cao
WebAssembly 3.0 giới thiệu hỗ trợ thu gom rác tích hợp, cho phép các ngôn ngữ như Java, Kotlin, Scala và Dart chạy hiệu quả hơn mà không cần vận chuyển hệ thống quản lý bộ nhớ riêng của chúng. Cộng đồng coi đây là một bước ngoặt để giảm kích thước bundle và cải thiện hiệu suất cho các ngôn ngữ thu gom rác. Tuy nhiên, một số lập trình viên lo ngại về những hiểu lầm, lưu ý rằng đây không phải là viên đạn bạc để chuyển đổi bất kỳ ngôn ngữ cấp cao nào. WebAssembly GC được thiết kế có chủ ý ở mức thấp, yêu cầu thiết kế compiler cẩn thận để tận dụng các kiểu struct và array của nó.
Tình trạng hỗ trợ ngôn ngữ:
- Hiện đã được hỗ trợ với GC: Java , OCaml , Scala , Kotlin , Scheme , Dart
- Vẫn còn thách thức: C (thiếu hỗ trợ ref/interior pointer), Go (không tương thích runtime)
- Không bị ảnh hưởng: C , C++ , Rust , Zig (không sử dụng tính năng GC )
Truy cập DOM vẫn là mảnh ghép còn thiếu
Có lẽ cuộc thảo luận gây tranh cãi nhất xoay quanh việc WebAssembly vẫn tiếp tục thiếu khả năng truy cập trực tiếp DOM. Nhiều lập trình viên bày tỏ sự thất vọng rằng họ vẫn cần JavaScript như một trung gian để thao tác các phần tử trang web. Mặc dù tồn tại các giải pháp thay thế thông qua các ràng buộc JavaScript, các lập trình viên cho rằng điều này đánh bại mục đích sử dụng các ngôn ngữ thay thế cho phát triển web. Các nhà cung cấp trình duyệt duy trì rằng truy cập trực tiếp DOM sẽ tạo ra rủi ro bảo mật và độ phức tạp triển khai, ưa thích cách tiếp cận hiện tại nơi WebAssembly gọi vào các API JavaScript.
Truy cập trực tiếp DOM không có ý nghĩa gì như một tính năng WASM. Nó sẽ là tốt nhất là một tính năng trình duyệt web mà các nhà cung cấp trình duyệt cần triển khai bên ngoài WASM.
Các thách thức trải nghiệm lập trình viên vẫn tồn tại
Phản hồi từ cộng đồng tiết lộ những thất vọng đang diễn ra với các công cụ phát triển và tài liệu của WebAssembly. Các lập trình viên báo cáo khó khăn với các lỗi xác thực, tài liệu API kém và độ phức tạp của các toolchain hiện có như Binaryen. Một số đã tìm thấy thành công khi chuyển sang các công cụ dựa trên Rust như wasm-tools, trong khi những người khác ủng hộ việc viết WebAssembly bằng tay thay vì sử dụng các trừu tượng cấp cao.
Việc phát hành đại diện cho một bước tiến đáng kể cho các khả năng của WebAssembly, đặc biệt là cho các môi trường không phải web nơi các tính năng mới có thể tỏa sáng mà không có giới hạn trình duyệt. Tuy nhiên, các đánh đổi hiệu suất và các tính năng cụ thể web còn thiếu cho thấy rằng hành trình của WebAssembly để trở thành mục tiêu biên dịch phổ quát mà các lập trình viên hình dung vẫn còn những rào cản cần vượt qua.
Tham khảo: Wasm 3.0 Completed