Phát hành Wasmer 5.0

Backend thử nghiệm mới

• Đã bổ sung hỗ trợ cho V8, Wasmi, WAMR
• Giờ đây có thể dễ dàng tích hợp vào Wasmer bất kỳ trình thông dịch hoặc runtime nào hỗ trợ đặc tả Wasm-C-API
• Tích hợp V8 mang lại trải nghiệm gỡ lỗi xuất sắc thông qua trình gỡ lỗi V8 và Chrome Devtools
• Việc sử dụng V8 làm backend cũng đồng nghĩa với việc hỗ trợ gốc cho WebAssembly exceptions và garbage collection

Hỗ trợ iOS (được cung cấp thông qua các binding WAMR, Wasmi, V8)

• Wasmer mang WebAssembly lên thiết bị iOS thông qua chế độ trình thông dịch mới
• Tận dụng khả năng của V8, Wasmi và WebAssembly Micro Runtime (WAMR), giờ đây nhà phát triển có thể chạy liền mạch các mô-đun WebAssembly trên iOS
• Không cần thay đổi codebase, đồng thời cho phép viết ứng dụng hiệu năng cao trong hệ sinh thái Apple

Tinh gọn codebase

• Để phát hành Wasmer 5.0, trọng tâm được đặt vào việc làm cho codebase của Wasmer gọn nhất có thể
• Một số dependency mà Wasmer sử dụng đã không còn được bảo trì trong thời gian dài hoặc đã bị trùng lặp bởi các crate mới hơn và an toàn hơn
• Trong 2 năm qua, các binding Emscripten hầu như không còn được sử dụng, nên việc ngừng hỗ trợ và dọn dẹp dependency đã giúp xóa thuần 20.000 dòng mã khỏi codebase Wasmer

Cải thiện hiệu năng

• Giải tuần tự mô-đun hiện nhanh hơn tới 50% (tức là khi gọi Module::deserialize hoặc chạy mô-đun qua wasmer run)
• Những cải tiến này tận dụng bản cập nhật quan trọng của rkyv, thư viện giải tuần tự zero-copy được dùng để giải tuần tự mô-đun

Trình biên dịch được nâng cấp: Cranelift và LLVM 18

• Nhờ tích hợp Cranelift mới nhất, tốc độ runtime được cải thiện đáng kể, giúp các mô-đun WebAssembly chạy nhanh hơn bao giờ hết
• Wasmer 5.0 hiện bao gồm phiên bản LLVM mới nhất (18), cho phép nhà phát triển tiếp cận các tối ưu hóa mới nhất của toolchain
• Bản nâng cấp LLVM cải thiện khả năng tương thích và hiệu năng, cung cấp nền tảng vững chắc để biên dịch và chạy các mô-đun WebAssembly phức tạp
• Wasmer 5.0 cũng đi kèm hỗ trợ LoongAarch64 ở mức thử nghiệm
• Kết quả benchmark coremark với các phiên bản trình biên dịch mới nhất cho thấy LLVM và Cranelift trong Wasmer v5.0 nhanh hơn khoảng 8% so với v4.4.0

Ý kiến của GN⁺

• Việc phát hành Wasmer 5.0 có vẻ sẽ là một cột mốc lớn đối với hệ sinh thái WebAssembly. Đặc biệt, việc hỗ trợ iOS và cung cấp nhiều lựa chọn backend có thể mở rộng đáng kể phạm vi ứng dụng của WebAssembly sang cả mảng ứng dụng di động
• Bằng cách hỗ trợ nhiều runtime làm backend như V8, Wasmi, WAMR, các nhà phát triển giờ đây có thể chọn runtime phù hợp nhất với yêu cầu của mình. Điều này được kỳ vọng sẽ đóng góp lớn vào việc nâng cao tính linh hoạt và khả năng tương thích của WebAssembly
• Nỗ lực tối ưu hiệu năng thông qua việc tinh gọn codebase và áp dụng các trình biên dịch mới nhất cũng là điểm đáng chú ý. Điều này cho thấy Wasmer không chỉ dừng ở việc bổ sung tính năng mà còn liên tục đầu tư vào cải thiện chất lượng
• Mặt khác, việc ngừng hỗ trợ các binding Emscripten là điểm đáng tiếc, nhưng có vẻ là lựa chọn hợp lý khi nhu cầu dành cho chúng đã giảm do sự xuất hiện của các tiêu chuẩn mới như WASI và WASIX
• Tổng thể, Wasmer 5.0 là một bản phát hành thể hiện rõ sự phát triển của WebAssembly, và Wasmer được kỳ vọng sẽ tiếp tục là một trong những dự án chủ chốt dẫn dắt hệ sinh thái WebAssembly. Tuy vậy, vẫn cần những nỗ lực liên tục để nâng cao độ ổn định và mức độ trưởng thành của các tính năng còn đang ở giai đoạn thử nghiệm

[GN⁺]

Ý kiến trên Hacker News

• Biểu đồ hiệu năng trông rối rắm và như bị nguyền vậy. Có chỗ hiển thị theo thang log, và trong một số trường hợp rất khó hiểu họ đang muốn nói gì. Ví dụ, biểu đồ "Argon 2" hiển thị gần như mọi cột có cùng độ dài, nhưng từng cột lại được gắn các con số khác nhau tính bằng mili giây.
• Khi dùng V8 làm backend thì sẽ hỗ trợ xử lý ngoại lệ WebAssembly và garbage collection. Đang mong chờ thêm tin tức về việc này. Tò mò không biết wasm-gc có thể chia sẻ dữ liệu/chuỗi từ host giữa các mô-đun khác nhau trong cùng một runtime hay không, hay chỉ giới hạn trong một mô-đun duy nhất.
• Trên landing page của Wasmer rất khó hiểu họ làm gì. Họ nói là chạy mọi thứ ở mọi nơi, nhưng thực sự làm gì thì không rõ. Có vẻ là sản phẩm hướng tới lập trình viên, nhưng lại có nhiều buzzword hơn là giải thích kỹ thuật.
• Tôi hài lòng với Wasmtime, và đang vọc mô hình component của WASM cùng hệ thống plugin dựa trên WASI. Làm khá vui.
• Tôi vẫn chưa tìm ra trường hợp sử dụng nào thật sự tốt để áp dụng WASM vào dự án. Tình huống này hơi giống như có Raspberry Pi mà không biết dùng vào việc gì. Không rõ lý do thuyết phục để chọn WASM cho một dự án Rust bất đồng bộ.
• Ước gì có giải pháp không cần các header Cross-Origin Isolated. Tôi vẫn đang dùng phiên bản cũ.
• Tò mò liệu WASM có thể đóng vai trò là phương án thay thế ít tốn tài nguyên hơn cho ứng dụng Electron hay không. WASM không có quyền truy cập DOM, nhưng không rõ liệu điều đó có thể được bổ sung qua extension hay không.
• Tôi không hiểu giải pháp này giải quyết vấn đề gì. Chẳng phải mọi JavaScript runtime đều đã có sẵn engine WASM tích hợp rồi sao?
• Tò mò liệu giải pháp này có cho phép đánh giá mã Node.js một cách an toàn trong sandbox hay không.
• Biểu đồ hiệu năng rất khó đọc. Dấu phẩy và dấu chấm đều được dùng làm dấu phân tách hàng nghìn, và độ chính xác thì bị làm tròn một cách tùy tiện thành 1, 2 hoặc 3 chữ số.