Trang chủ Thủ Thuật Tại sao webassembly frameworks là tương lai của web

Tại sao webassembly frameworks là tương lai của web

0
15

Tại sao webassembly frameworks là tương lai của web

38432d41

WebAssembly là một cách mới để chạy mã trên web. Với các công ty công nghệ khổng lồ đằng sau nó, nó đã sẵn sàng để cách mạng hóa cách chúng ta viết các ứng dụng web, nhưng đi kèm với những điều kỳ quặc và hạn chế của riêng nó. Khung WASM có phải là đối thủ cạnh tranh khả thi với các thư viện JavaScript như React không?

WebAssembly là gì?

WebAssembly, hay WASM, là ngôn ngữ lập trình phổ quát thứ hai mà tất cả các trình duyệt web có thể hiểu và chạy. Tuy nhiên, bạn sẽ không tự viết kịch bản trong WebAssembly – đó là một ngôn ngữ lắp ráp cấp thấp, được thiết kế rất gần với mã máy được biên dịch và rất gần với hiệu suất gốc.

Wasm can be used as a portable compilation target for other languages

Điều kỳ diệu của WebAssembly là nó đủ thấp để nó thực sự là một mục tiêu tổng hợpdễ dàng . Bất kỳ ngôn ngữ nhanh hợp lý nào cũng phải đi qua trình biên dịch tại một số điểm, thậm chí các ngôn ngữ biên soạn JIT như JavaScript và thường có nghĩa là biên dịch đến x86 hoặc mã máy ARM để chạy trên bộ xử lý hiện đại.

Tuy nhiên, bạn cũng có thể biên dịch sang một định dạng khác; thông thường điều này kết thúc là một ngôn ngữ “cấp thấp hơn” gần với mã máy cuối cùng. Ví dụ: Java biên dịch đến mã bytecode Java được gửi đến thời gian chạy JVM và C# biên dịch đến Microsoft Intermediary Language (MSIL) được gửi đến thời gian chạy .NET. Bạn thậm chí có thể “chuyển đổi” ngôn ngữ, từ ngôn ngữ cấp cao này sang ngôn ngữ cấp cao khác, phổ biến nhất là các tiện ích mở rộng như TypeScript đến JavaScript, nhưng cũng có những ngôn ngữ kỳ lạ hơn mà bạn không mong đợi, như Python sang JavaScript, mặc dù điều đó thường lộn xộn và lỗi.

WASM chỉ là một ngôn ngữ trung gian dễ biên soạn. Trên thực tế, nó gần như chính xác cùng một khái niệm với Java bytecode và C # MSIL – cả hai định dạng này giúp dễ dàng chạy cùng một nền tảng mã chéo, sử dụng cùng một định dạng chạy trên thời gian chạy cụ thể được thực hiện cho mỗi nền tảng.

9bff4e33 1
AssemblyScript, một phiên bản của TypeScript được biên soạn cho WASM
Quảng cáo

Điều này có nghĩa là trong thực tế là JavaScript không còn là ngôn ngữ duy nhất bạn có thể chạy trên web. Trình duyệt web có thể chạy bất kỳ ngôn ngữ nào ngay bây giờ, nếu ngôn ngữ đó có trình biên dịch WebAssembly.

Ngay cả các ngôn ngữ máy tính để bàn truyền thống như C ++ và Rust cũng có thể được biên soạn xuống WASM một cách tương đối dễ dàng; AutoDesk đã có thể chuyển cơ sở mã C / C ++ 35 năm tuổi của họ sang WASM trong vài tháng và Google đã chuyển Google Earth, cả hai đều hiển thị các cảnh 3D phức tạp và chạy ở hiệu suất gần như bản địa. Công cụ trò chơi Unity cũng có thể chạy trong WASM.

WASM hiện đang chạy trong 94% trình duyệt người dùng, với IE, trình duyệt UC và hỗ trợ Opera Mini là những thứ chính giữ nó lại, như thường lệ. Tuy nhiên, nó được hỗ trợ bởi các nhà phát triển từ Mozilla, Microsoft, Google và Apple, và sự hỗ trợ của nó trong các trình duyệt hiện đại đang chuyển động nhanh chóng. Giống như hầu hết các tiêu chuẩn web, nó hiện đang được quản lý bởi tổ chức tiêu chuẩn W3C.

JavaScript không còn là lựa chọn duy nhất nữa

Tuyệt vời, vậy điều này có ý nghĩa gì đối với tất cả mọi người? Vâng, trong khi chạy DOOM 3 trong một trình duyệt web chắc chắn là một bản demo tuyệt vời, nó không chính xác thay đổi trò chơi.

Cho đến nay, JavaScript là lựa chọn duy nhất của bạn để làm cho các trang web của bạn tương tác. Cho dù bạn yêu hay ghét nó, nó không bao giờ được thiết kế để được sử dụng như ngày nay. Đó là một ngôn ngữ kịch bản được thiết kế để thực hiện các nhiệm vụ tầm thường như làm cho các menu thả xuống hoạt hình và hơn 25 năm đã bị hack cùng nhau để chạy khối lượng công việc hiện đại. Chỉ thông qua việc sử dụng các công cụ JS hiện đại và tối ưu hóa biên soạn JIT thậm chí có thể được so sánh với tốc độ gốc.

Và vì vậy, khi các trang web phát triển để trở thành ứng dụng web đầy đủ, các khung máy khách JavaScript như React, Vue và Angular được hỗ trợ để đáp ứng nhu cầu. Tất nhiên, vẫn có các framework phía máy chủ – bạn đang đọc điều này từ WordPress, một framework PHP – nhưng khung máy khách cung cấp tăng hiệu suất rất lớn. Với khung khách hàng, DOM được cập nhật tự động sau khi nhấn nút hoặc tương tác với ứng dụng. Ngay cả các framework kết xuất máy chủ thời gian thực cũng phải thực hiện yêu cầu mạng để thay đổi bất cứ điều gì và trong trường hợp xấu nhất, phải làm mới toàn bộ trang.

Quảng cáo

Sự đổi mới mà web thực sự cần là đối thủ cạnh tranh thích hợp với các khung như React, được viết bằng ngôn ngữ không phải JavaScript.

Mặc dù tất cả các mã frontend của web được viết bằng JavaScript, mã phụ trợ thường không. Trong khối lượng công việc trung tâm dữ liệu hiệu suất cao, thường có lợi khi sử dụng các ngôn ngữ máy tính để bàn thích hợp như C #, C ++, Rust và Go. Rốt cuộc, những điều này thực sự có thể giúp bạn tiết kiệm tiền bằng cách yêu cầu ít máy chủ hơn để đáp ứng cùng một nhu cầu.

Tuy nhiên, nó cũng khiến bạn tốn tiền trong thời gian phát triển, vì bây giờ bạn phải đối phó với khả năng tương tác giữa phụ trợ C # của bạn và frontend JavaScript của bạn. Đơn giản là không thể chia sẻ mã, mô hình và thư viện có thể làm tăng độ phức tạp phát triển của bạn lên đến 2 lần so với một hệ thống thống nhất. Lý do này một mình là lý do tại sao các phụ trợ máy chủ NodeJS rất phổ biến, mặc dù nghe có vẻ như một ý tưởng khủng khiếp 20 năm trước.

Có khả năng viết mã C #, C++, Rust và Go chạy trên máy chủ và máy khách sẽ mở ra cánh cửa cho nhiều tùy chọn hơn và loại bỏ sự cần thiết của JavaScript như một ngôn ngữ lập trình gần như hoàn toàn. Trong khung máy khách WASM Blazor, việc sử dụng JavaScript được dành riêng cho khả năng tương tác với các gói khách hàng hiện có và kịch bản cơ bản.

Khung khách hàng WASM hoạt động như thế nào?

Vì WebAssembly chỉ là một cách để chạy mã trong một loại “môi trường WebAssembly”, bạn có thể nghĩ về nó giống như chạy một container Docker. Ví dụ: khung Blazor của Microsoft (cho đến nay khung máy khách WASM phổ biến nhất cho đến nay) có hai chế độ hoạt động:

  • Blazor Server, chạy tất cả các quá trình xử lý và kết xuất trên máy chủ và gửi bản cập nhật đến HTML DOM qua WebSocket và
  • Blazor WebAssembly, thực hiện chính xác điều tương tự, ngoại trừ bây giờ việc xử lý và kết xuất được thực hiện trên khách hàng, thông qua thời gian chạy .NET được biên dịch cho WASM.

Trong trường hợp thứ hai, kết nối WebSocket được thay thế bằng một liên kết trực tiếp đến DOM, thông qua JavaScript vì WebAssembly hiện không có cách nào để sửa đổi DOM trực tiếp mà không gọi API JS. Bạn cũng cần JavaScript trong mọi trường hợp để “khởi động” ứng dụng WASM, vì vậy JS sẽ không biến mất sớm.

21212c80

Quảng cáo

Ngoài ra, khung khách hàng WASM hoạt động nói chung giống như bất kỳ khuôn khổ nào khác và các chi tiết chính xác sẽ phụ thuộc vào việc thực hiện.

Ví dụ: Blazor giữ trạng thái nội bộ và kích hoạt kết xuất lại ứng dụng khi một nút được nhấp hoặc nhập liệu được thực hiện. Nó xây dựng HTML mới bằng cách sử dụng mã C # chạy trên WASM, và sau đó gửi HTML đó đến các API JavaScript để áp dụng cho DOM. Làm điều này trên WebAssembly mất tải xử lý khỏi máy chủ và làm cho máy khách nhanh chóng và đáp ứng. Ngay cả truy cập DOM thông qua JavaScript cũng chậm hơn một chút, nó vẫn là các giải đấu nhanh hơn so với giải pháp thay thế – truy cập DOM qua internet.

Liên quan:Khung web Blazor của Microsoft là gì và bạn có nên sử dụng nó không?

Chúng ta đang nói chuyện nhanh hơn bao nhiêu?

Câu hỏi “WASM nhanh hơn bao nhiêu?” rất khó để xác định. Nó rõ ràng là nhanh hơn về tổng thể, không có nghi ngờ gì về điều đó, nhưng trong một số trường hợp, nó phức tạp hơn thế.

Truy cập DOM vẫn là một vấn đề vì nó phải được thực hiện thông qua JavaScript, vì vậy nó sẽ chậm như JavaScript. Tuy nhiên, điều này sẽ sớm được khắc phục. Đôi khi, JavaScript có thể nhanh hơn trong các điểm chuẩn cụ thể mà trình biên dịch WASM có thể đang phải vật lộn, chỉ đơn giản là vì thực tế là JS có 25 năm lặp lại trình biên dịch đằng sau nó.

Đối với các ứng dụng hiệu suất cao cần nhiều sức mạnh xử lý, như trò chơi và ứng dụng, WASM thường nhanh hơn từ 1,5x đến 2 lần. Nhưng nó có thể là cùng một tốc độ. Nó cũng có thể chậm hơn 20% so với JavaScript. Nó cũng có thể nhanh hơn 10 lần cho một số chức năng. Có những điểm chuẩn ngoài kia hiển thị tất cả các kết quả này, vì vậy điều duy nhất có thể nói chắc chắn là số dặm của bạn sẽ khác nhau.

So với mã gốc, nó có khả năng luôn chậm hơn ngôn ngữ mà nó biên soạn. Vì vậy, trong khi nó có thể sẽ nhanh chóng, có rất nhiều cảnh báo, và bạn không nên sử dụng WASM với kỳ vọng nhận được hiệu suất gốc trên web.

Quảng cáo

Với tất cả những gì đã nói, WASM không cần hiệu suất điên rồ để trở thành một cuộc cách mạng. Nó chỉ cần làm việc, không chậm và hỗ trợ nhiều ngôn ngữ.

Những khung nào hoạt động ngay bây giờ?

Quan trọng nhất cho đến nay là Blazor, được phát triển bởi Microsoft. Đây là khung khách hàng WASM đầu tiên được hỗ trợ bởi một công ty lớn và có thể sẽ là chất xúc tác để WASM cuối cùng có được sự chấp nhận chính thống mà nó xứng đáng.

Blazor WASM chỉ mới một năm tuổi, với Blazor Server được phát hành cách đây 3 năm, nhưng điều tuyệt vời về Blazor là nó chỉ là một phần mở rộng của ASP.NET, một khung web 20 năm tuổi mà Microsoft đã không ngừng cải tiến. Bạn có thể sử dụng nhiều thư viện frontend đã được viết cho ASP.NET và nó có thể là khung duy nhất được hỗ trợ bởi một trình quản lý gói web cạnh tranh với NPM.

Đây cũng không phải là một dự án phụ – Microsoft đã thúc đẩy Blazor nhiều hơn là chỉ là một khung web; Đây là mô hình lập trình ứng dụng tiếp theo của họ. Họ đang làm việc trên Blazor Desktop, phát hành vào cuối năm 2021, hoạt động rất giống electron để chạy các ứng dụng web Blazor tương tự trên máy tính để bàn. Họ rõ ràng quan tâm rất nhiều đến nó, đó là tin tuyệt vời cho WASM nói chung.

Nếu bạn muốn tìm hiểu thêm, bạn có thể đọc hướng dẫn của chúng tôi về Blazor là gì và làm thế nào để bắt đầu sử dụng nó.

Khung sẵn sàng sản xuất khác là Yew, được xây dựng trên Rust, một ngôn ngữ hiện đại tương tự như C ++, ngoại trừ an toàn bộ nhớ do cách xử lý tài liệu tham khảo kỳ lạ. Yew nhanh, hỗ trợ một mô hình dựa trên thành phần như React và có khả năng tương tác với API JS.

Quảng cáo

asm-dom là một thư viện được viết cho C ++, điều đó không làm nhiều hơn là kết nối mã C ++ với DOM. Rõ ràng bạn sẽ cần phải mang theo khung của riêng bạn ở đây, nhưng hầu hết các nhà phát triển đủ điên rồ để viết các ứng dụng web trong C ++ có thể sẽ làm điều đó bằng mọi cách. Nó cũng có hỗ trợ để trở lại asm.js, một phiên bản đầu tiên của những gì WebAssembly đã cố gắng trở thành. Về cơ bản, nó là một tập hợp con của JavaScript bị giới hạn chỉ sử dụng số nguyên (tức là chỉ byte, không phải đối tượng), giúp chuyển mã C ++ dễ dàng hơn, vì về cơ bản đó là tất cả các mã C ++ sử dụng vào cuối ngày. Có hỗ trợ này không hữu ích lắm mặc dù có rất ít môi trường sẽ không hỗ trợ WASM nhưng sẽ hỗ trợ asm.js.

Vugu là một framework được viết trong Go, hỗ trợ các thành phần và được mô phỏng theo cú pháp Vue, nhưng vẫn là thử nghiệm. Ngoài ra còn có Vecty, cũng là một khuôn khổ Go phổ biến.

Cách tạo C# Client Web Apps với Khung web Blazor của Microsoft

Tương lai của WebAssembly

Tất cả điều này đã tập trung vào các khung web của khách hàng sử dụng WASM để thao tác DOM và xây dựng các ứng dụng. Nhưng, bạn cũng có thể chuyển toàn bộ ứng dụng máy tính để bàn lên web. Đó là những gì Uno làm – sử dụng WASM để chạy các ứng dụng Universal Windows Platform (UWP) trực tiếp trong một container web, điều này cũng đi kèm với lợi ích bổ sung là hoàn toàn đa nền tảng. Nó thực sự là một chút kỳ lạ như thế nào điều này hoạt động tốt, và thực sự cảm thấy như bạn đang sử dụng một ứng dụng Windows gốc. Bạn có thể tự kiểm tra nó trong phòng trưng bày của họ.

c0afeba4

Có rất nhiều thứ cho hệ sinh thái WASM hơn là những điều này. Nếu bạn muốn tìm hiểu thêm, bạn nên đọc qua bản tổng hợp tuyệt vời trên GitHub, trong đó liệt kê một loạt các dự án phổ biến.

Đáng chú ý nhất mà chúng tôi không đề cập ở đây là WASI – một cách để chạy WebAssembly một cách di chuyển trên bất kỳ hệ thống nào bằng cách sử dụng giao diện hệ thống được tiêu chuẩn hóa. Khi WASM ngày càng trở nên hiệu quả hơn, WASI có thể chứng minh là một cách khả thi để chạy bất kỳ loại mã nào trên bất kỳ loại hệ thống nào, tương tự như cách Docker hoạt động nhưng không hạn chế về hệ điều hành. Trên thực tế, Solomon Hykes, người tạo ra Docker, đã hết lòng ủng hộ nó:

WebAssembly chỉ mới vài tuổi. Nó vẫn còn nhiều chỗ để phát triển, và vẫn đang tăng tốc. Không phải là không hợp lý khi năm năm nữa, các khuôn khổ như Blazor và Yew sẽ phổ biến như React, Angular và Vue.

Quảng cáo

Điều này có thể được lập luận là phân mảnh hệ sinh thái web, nhưng WASM là nền tảng chéo. WAPM, một người quản lý gói WASM, có thể trở thành cách để chia sẻ thư viện giữa các khung của các ngôn ngữ khác nhau.

Trong mọi trường hợp, các khung web chạy trên WebAssembly có tiềm năng rất lớn và với việc Microsoft đích thân ủng hộ một khung, chúng tôi tự tin rằng chúng là tương lai của web.

How to Mount Your Microsoft OneDrive in Linux

Cách gắn Microsoft OneDrive của bạn trong Linux

How to Use lsof in Linux (With a Practical Example)

Cách sử dụng lsof trong Linux (Với một ví dụ thực tế)

How to Run PHPMyAdmin in a Docker Container

Cách chạy PHPMyAdmin trong container Docker

How to Handle Web Push Notifications in Websites and PWAs

Cách xử lý thông báo đẩy web trong trang web và PWAs

How to Develop on a Remote SSH Server With Visual Studio Code

Cách phát triển trên máy chủ SSH từ xa với mã Studio trực quan

How to Monitor the Resource Usage of Docker Containers

Cách giám sát việc sử dụng tài nguyên của Container Docker

Dịch từ: https://www.cloudsavvyit.com/13696/why-webassembly-frameworks-are-the-future-of-the-web/

BÌNH LUẬN

Vui lòng nhập bình luận của bạn
Vui lòng nhập tên của bạn ở đây