WebAssembly đã trở thành một trong tứ trụ của công nghệ web bên cạnh HTML, CSS và JavaScript. Khi mới xuất hiện, chỉ có một vài ngôn ngữ cấp cao như C, C++ hay Rust có thể thực thi trực tiếp trên trình duyệt web nhờ WebAssembly. Nhưng giờ đây, C# – một ngôn ngữ hướng đối tượng cấp cao của Microsoft đã có thể viết trực tiếp trên trình duyệt web nhờ có Blazor. Tại sao là Blazor chứ không phải WebAssembly?
Blazor là gì?
Ứng dụng Blazor là sự kết hợp các thành phần được xây dựng từ C#, HTML và CSS. Có hai mô hình thực thi Blazor là mô hình Server [Server-side Blazor] và mô hình Client [Client-side Blazor] hay còn được gọi là mô hình WebAssembly Blazor.
Mô hình Server được mô tả như hình sau:
Với mô hình này, mã Blazor vẫn ở trên Server và được kết nối đến trình duyệt web thông qua SignalR – một thư viện mã nguồn mở đơn giản hóa việc thêm tính năng thời gian thực đến ứng dụng web. Mô hình này được tích hợp trong ASP.NET Core.
Mô hình WebAssembly Blazor là mô hình chúng ta quan tâm vì với nó, chúng ta có thể viết C# trực tiếp trên trình duyệt web, và tất nhiên, phép màu này có được là nhờ WebAssembly. Có thể hiểu mô hình này trực quan như sau:
Nếu nhìn vào hình trên, chúng ta sẽ thấy cái gọi là Razor Components – là đặc trưng mới trong ASP.NET giúp phát triển ứng dụng web đơn giản và dễ dàng hơn mô hình MVC. Cho đến thời điểm này, mô hình WebAssembly Blazor chỉ là bản PreView cho ASP.NET Core 3.1 và sẽ được triển khai chính thức vào tháng 5 năm 2020 sắp tới. Lúc đó, chúng ta sẽ có một loạt bài viết tập trung về WebAssembly Blazor.
Tham khảo: Introduction to ASP.NET Core Blazor
Các phát triển ứng dụng web phổ biến nhất được thực hiện bằng cách sử dụng các khung javascript. Microsoft đã phát hành Blazor như một giải pháp thay thế thay vì sử dụng các khuôn khổ javascript [Vue, Angular, React, v.v.]. Trong bài viết này, chúng ta sẽ tìm hiểu thêm về Blazor .
Blazor là gì?
Blazor là một khuôn khổ đa nền tảng và mã nguồn mở mới để xây dựng giao diện người dùng tương tác phía máy khách và Nó được phát triển bởi nhóm ASP.NET của Microsoft. Bản phát hành đầu tiên của nó được thực hiện vào năm 2018.
- Nó được hỗ trợ bởi Windows, Linux và macOS.
- Nó cho phép khả năng viết giao diện người dùng web bằng cú pháp C # và Razor thay vì JavaScript. Bằng cách này, nó cho phép phát triển cả phần phụ trợ và giao diện người dùng với cùng một ngôn ngữ.
- Tên của nó là sự kết hợp của các từ Browser và Razor.
- Nó được sử dụng để phát triển giao diện người dùng web trong các ứng dụng phía máy khách và trong khi làm việc này, nó sử dụng hỗ trợ WebAssembly .
- Blazor cho phép chúng tôi làm việc với cả IDE nâng cao như Visual Studio và IDE nhẹ như Visual Studio Code.
- Các nguồn của Blazer được lưu giữ trong một kho lưu trữ riêng biệt cho đến khi Blazor hợp nhất với ASP.NET5.
- Bây giờ, bạn có thể tiếp cận các nguồn và sự cố của Blazor trong ASP.NET Core Repo
- Với sự trợ giúp của lắp ráp web, mã C # bạn viết cho phía máy khách sẽ hoạt động trong tất cả các trình duyệt hiện đại với Môi trường thời gian chạy .NET thay vì cài đặt một plugin hoặc thực hiện quá trình chuyển tải.
Các thành phần Blazor có thể được thực hiện bằng cách sử dụng cú pháp Razor với sự kết hợp của mã .NET. Tệp dao cạo được sử dụng để triển khai thay vì sử dụng tệp .cshtml. Việc xử lý sự kiện giao diện người dùng, liên kết dữ liệu và hiển thị cập nhật giao diện người dùng rất dễ thực hiện và hoạt động liền mạch với các thành phần Blazor.
Có hai phương thức lưu trữ để tạo ứng dụng web Blazor:
Máy chủ Blazor
Trong phương thức lưu trữ này, các thành phần Blazor được thực thi trên máy chủ ứng dụng ASP.NET Core. Tất cả các tương tác và cập nhật giao diện người dùng được xử lý qua kết nối SignalR . Các ứng dụng Blazor Server tải nhanh và dễ triển khai.
Blazor WebAssembly
Trong phương thức lưu trữ này, các thành phần Blazor được thực thi trên trình duyệt sử dụng thời gian chạy .NET dựa trên WebAssembly ở phía máy khách. Thời gian chạy .NET này được tải xuống bằng ứng dụng Blazor WebAssembly của bạn và cho phép chạy mã .NET bình thường trực tiếp trong trình duyệt. Không cần bổ sung hoặc chuyển đổi mã. Blazor WebAssembly hoạt động với tất cả các trình duyệt web hiện đại, cả máy tính để bàn và thiết bị di động. Tương tự như JavaScript, các ứng dụng Blazor WebAssembly chạy an toàn trên thiết bị của người dùng từ trong hộp cát bảo mật của trình duyệt. Các ứng dụng này có thể được triển khai dưới dạng các trang tĩnh hoàn toàn độc lập mà không cần bất kỳ thành phần máy chủ .NET nào hoặc chúng có thể được ghép nối với ASP.NET Core để cho phép phát triển web toàn bộ với .NET, nơi mã có thể được chia sẻ dễ dàng với máy khách và máy chủ .
Mối quan hệ với WebAssembly
WebAssembly thường được viết tắt WASM là một tiêu chuẩn mới có thể chạy trong các trình duyệt web hiện đại mang lại sự đa dạng về ngôn ngữ cho nền tảng web. Cùng với CSS, HTML và JavaScript, WASM là ngôn ngữ thứ tư chạy nguyên bản trong các trình duyệt hiện đại.
Nó là một ngôn ngữ giống như hợp ngữ cấp thấp có định dạng nhị phân nhỏ gọn giúp bạn có thể chạy mã được viết bằng nhiều ngôn ngữ như C / C ++, Java và Rust trên web với hiệu suất gần như nguyên bản.
Mục đích của WebAssembly là đơn giản hóa các ứng dụng hiệu suất cao trên các trang web. Tuy nhiên, định dạng của nó được thiết kế để thực thi và tích hợp trong các môi trường khác và cũng có thể chạy cùng với JavaScript.
Bắt đầu với các thành phần Blazor
Các tệp .razor được sử dụng để tạo các thành phần Blazor.
Cú pháp dao cạo được sử dụng trong tệp .razor.
Thay vì làm việc với Javascript, Jquery hoặc v.v. cho lệnh gọi api, việc ghi đè các phương thức vòng đời thành phần và phương thức thành phần có thể được triển khai trong phần @code.
Nếu bạn muốn đọc giải thích chi tiết hơn về cách bắt đầu với ứng dụng Blazor, bạn nên xem một bài đăng hay của Nishan Chathuranga Wickramaratha .
Những điều có thể làm được với việc sử dụng Blazor
Trong phát triển máy tính để bàn, web và ứng dụng di động trên nhiều nền tảng, Blazor cung cấp một tùy chọn thay thế cho các nhà phát triển. Bằng cách này, khu vực sử dụng .Net mở rộng và khả năng phát triển ứng dụng lai tăng lên. Để đưa ra một vài ví dụ về những điều này;
ElectronJs
Để tóm tắt về ElectronJs, như nó cũng đã được đề cập trong trang web chính thức của Electron, các nhà phát triển có thể xây dựng các ứng dụng máy tính để bàn đa nền tảng bằng Javascript, HTML. Ý nghĩa của javascript không chỉ là triển khai Javascript thuần túy, các nhà phát triển còn có thể sử dụng các khung công tác javascript như React, Angular, Vue, v.v.
Thay vì sử dụng javascript, Blazor cũng có thể được sử dụng để các nhà phát triển có thể tạo ứng dụng máy tính để bàn đa nền tảng với Electron và Blazor.
Xamarin
Việc phát triển một ứng dụng gốc với C # bằng Xamarin đã trở nên khả thi nhưng trong các ứng dụng này, Javascript được sử dụng để quản lý nhà nước, điều mà các nhà phát triển cần.
Nhờ Blazor, có thể phát triển di động với Blazor thay vì sử dụng Javascript trong dự án Xamarin.
Ứng dụng một trang [ SPA ]
Một trong những kỹ thuật phát triển của ứng dụng web là SPA [Ứng dụng trang đơn]. Do quản lý nhà nước trong SPA, cần sử dụng các framework Javascript như Vue, React, v.v.
Nhờ Blazor, giờ đây, mọi nhà phát triển C # đều có thể tạo ứng dụng SPA.
Tóm lược
Mặc dù Javascript là phổ biến nhất, các nhà phát triển .Net có thể phát triển các ứng dụng đa nền tảng với Blazor mà không cần rời khỏi thế giới .net để trở thành một nhà phát triển ngăn xếp đầy đủ. Blazor sẽ phát triển và lan rộng hơn nữa với .NET 5 framework. Tất nhiên, vì blazor vẫn đang trong giai đoạn phát triển nên nó có những thiếu sót so với các framework Javascript tương đương của nó.
Chúng ta sẽ cùng nhau theo dõi những bước phát triển của Microsoft trong lĩnh vực này.
Có rất nhiều dự án được hỗ trợ bởi WebAssembly đang được triển khai. Nhưng một trong những cách nhanh nhất là Blazor, một ngăn xếp .NET để xây dựng các ứng dụng web một trang. Microsoft đã phát hành phiên bản Blazor đầu tiên vào tháng 5 năm 2020. Bài viết này được viết với phiên bản xem trước trước đó.
Điều gì sẽ xảy ra nếu bạn có thể viết mã chạy nguyên bản bên trong trình duyệt, nhưng không phải là JavaScript? Nó sẽ nằm trong cùng một hộp cát và có cùng khả năng tương thích phổ quát. Và nó sẽ không cần một plugin rườm rà.
Đó là lời hứa của Blazor, một công nghệ của Microsoft đưa cả C # và .NET vào trình duyệt. Nó hoạt động theo kỹ thuật của mình bằng cách sử dụng WebAssembly, một đường ống hiệu suất cao biên dịch trước mã thành định dạng nhị phân, nhỏ gọn. Hơn hết, WebAssembly được hỗ trợ bởi mọi trình duyệt chính, bao gồm cả các phiên bản di động.
Bạn có thể tìm hiểu thêm về WebAssembly tại đây . Nhưng điều quan trọng cần rút ra là đây: trước khi có WebAssembly, về mặt kỹ thuật, có thể tạo ra một thứ giống như Blazor. Nhưng hiệu suất sẽ tụt hậu xa so với JavaScript, nó sẽ làm cho kết nối quay số của những năm 1990 trông tốt hơn.
Hai loại Blazor
Trước khi bạn tìm hiểu sâu hơn, hãy làm rõ điều gì đó. Thực tế có hai hương vị của Blazor. Như thường lệ, những người làm thương hiệu của Microsoft luôn chăm chỉ làm những gì họ giỏi nhất - sử dụng và tái sử dụng các tên sản phẩm mới, và gây ra sự nhầm lẫn rộng rãi trong quá trình này.
Hai phiên bản của Blazor có chung một mô hình lập trình giống nhau, nhưng nền tảng kỹ thuật của chúng hoàn toàn khác nhau:
- Blazor Server chạy mã của bạn trên máy chủ web, sử dụng môi trường .NET quen thuộc. Bí quyết là cách trình duyệt và máy chủ giao tiếp. Khi người dùng tương tác với trang, mã JavaScript sẽ gọi lại máy chủ nơi vòng đời của trang thực xảy ra. [Để tạo kết nối này, trang sử dụng API của Microsoft có tên là SignalR .] Sau khi mã phía máy chủ của bạn chạy, Máy chủ Blazor hiển thị trang và gửi các thay đổi trở lại trang web, trang này sẽ tự cập nhật tương ứng.
- Blazor WebAssembly chạy mã của bạn trong trình duyệt, sử dụng thời gian chạy .NET thu nhỏ được cung cấp bởi WebAssembly. Mã phía máy khách của bạn có quyền truy cập vào nhiều thư viện .NET quen thuộc và bạn viết mã đó bằng ngôn ngữ C # chính hãng. Có, bạn vẫn có thể gọi một API trên máy chủ web, giống như cách bạn làm trong một trang JavaScript. Nhưng trung tâm của ứng dụng [và tất cả giao diện người dùng của nó] được xử lý trong trình duyệt.
Kể từ bây giờ, khi tôi viết "Blazor", nó có nghĩa là "Blazor WebAssembly."
Kiến trúc của Blazor
Các lập trình viên có quan niệm sai lầm phổ biến nhất về Blazor là mã C # của họ được biên dịch thành WebAssembly, sau đó được gửi đến trình duyệt và sau đó được thực thi. Cách tiếp cận này không nằm ngoài câu hỏi - và những người tạo ra Blazor đã gợi ý rằng họ có thể thử kỹ thuật này trong tương lai. Nhưng đó không phải là cách Blazor hoạt động ngày nay.
Hiện tại, phần duy nhất của Blazor sử dụng WebAssembly là thời gian chạy. Tất cả các thành phần khác trong ứng dụng của bạn đều được biên dịch sang ngôn ngữ trung gian [IL], tiêu chuẩn bytecode cho .NET kể từ năm 2000. Nói cách khác, ứng dụng Blazor được biên dịch theo cách giống hệt như bất kỳ ứng dụng .NET nào khác trước khi được phân phối.
Vậy làm thế nào để tất cả kết hợp lại với nhau? Khi bạn truy cập một trang web sử dụng Blazor, trang sẽ bắt đầu bằng cách tải xuống thời gian chạy .NET được thu nhỏ. Sau đó, nó tải xuống ứng dụng của bạn và bất kỳ thư viện .NET nào khác mà ứng dụng của bạn sử dụng, tất cả đều ở IL gốc của chúng. Cuối cùng, thời gian chạy Blazor thực thi IL.
Không yêu cầu bạn phải viết mã phía máy chủ trong ASP.NET - hoặc bạn có thể viết bất kỳ mã phía máy chủ nào cả. Tất cả những gì bạn cần làm là biên dịch ứng dụng Blazor và đưa các tệp lên máy chủ web.
Bạn có thể nghĩ rằng kiến trúc Blazor có vẻ giống như việc đặt một máy ảo [cho .NET] bên trong một máy ảo khác [cho JavaScript]. Bạn sẽ không hoàn toàn sai. Sự khác biệt là WebAssembly cho phép thời gian chạy .NET tránh chi phí của JavaScript - cụ thể là các chu kỳ phân tích cú pháp, biên dịch và tối ưu hóa.
Về lý thuyết, hiệu suất của mã C # được thông dịch trong trình duyệt phải tốt— xét cho cùng, WebAssembly đã được sử dụng để chuyển trình giả lập và trò chơi 3D vào trình duyệt. Tuy nhiên, chúng ta có thể mong đợi một số loại thuế khởi động khi ứng dụng bắt đầu, vì nó cần tải xuống thời gian chạy Blazor. Chúng tôi sẽ xem xét kỹ hơn hiệu suất của Blazor sau khi chúng tôi xây dựng một trang đơn giản.
Thiết lập môi trường Blazor
Tuyên bố từ chối trách nhiệm: Nếu bạn chưa nhận ra, Blazor là một sản phẩm beta giai đoạn đầu trước khi phát hành. Các phần cơ sở hạ tầng quan trọng đang thay đổi và bạn sẽ không nhận được cùng mức hỗ trợ công cụ mà bạn nhận được với các loại dự án khác của Microsoft. Điều đó nói rằng, tôi đã thử tạo ứng dụng Blazor trong Visual Studio Community 2019 [phiên bản miễn phí] và VS Code. Blazor hoạt động trong cả hai môi trường mà chỉ gặp trục trặc nhỏ.
Nhìn chung, tôi thích trải nghiệm Visual Studio 2019 đầy đủ vì sự tiện lợi của nó - một cú nhấp chuột vào nút Run là đủ để biên dịch ứng dụng, khởi động IIS Express và khởi chạy trang tương ứng trong trình duyệt. IntelliSense cũng ít bị hỏng hơn. [Tôi đã nghe tin đồn về tiện ích mở rộng Blazor cho VS Code, nhưng tôi không muốn đi quá sâu vào cấu hình với phần mềm phát hành trước.]
Microsoft cung cấp hướng dẫn thiết lập đầy đủ cho cả hai phiên bản Visual Studio. Đây là những gì đã làm việc cho tôi:
- Cài đặt .NET Core 3.0 SDK .
- Cài đặt bản xem trước mới nhất của .NET Core 3.1 SDK . [Blazor sẽ được phát hành với .NET Core 3.1.]
- Cài đặt Visual Studio Community 2019 với khối lượng công việc “ASP.NET và phát triển web”. Lưu ý rằng bạn không cần phiên bản xem trước Visual Studio 16.4 ] để chạy Blazor, mặc dù điều đó cũng sẽ hoạt động.
Khi ứng dụng mới của bạn được tạo, bạn có thể chạy ngay lập tức. Bạn sẽ nhận được dự án demo đã rút gọn được hiển thị ở đây:
Trước khi bạn có thể làm bất cứ điều gì hữu ích hơn, bạn cần xem qua hậu trường và xem ví dụ này được xây dựng như thế nào.
Cái nhìn đầu tiên của bạn về một dự án Blazor
Có rất nhiều bảng điều khiển trong một dự án Blazor mới. Nếu bạn chưa lập trình với ASP.NET Razor, bạn có thể cảm thấy hơi mất hứng. [Tên “Blazor” xuất phát từ việc lấy mô hình “Razor” phía máy chủ ASP.NET và thêm “B” cho trình duyệt.]
Đây là chế độ xem mở rộng của Trình khám phá giải pháp trên ứng dụng Blazor mới:
Rất may, khá dễ dàng để loại bỏ sự lộn xộn. Các phần tiếp theo sẽ đưa bạn vào một chuyến tham quan viết tắt.
Bắt đầu từ gốc: wwwroot
Thư mục wwwroot chứa các tệp máy chủ web truyền thống - các trang HTML, CSS style sheet, hình ảnh và các tài nguyên khác. Index.html là điểm nhập cho ứng dụng của bạn. Không có gì xảy ra cho đến khi ai đó khởi chạy trình duyệt web và điều hướng đến trang này.
Nếu bạn nhìn vào bên trong index.html, đây là những gì bạn sẽ thấy:
Trang web mẫu này sử dụng thư viện kiểu Bootstrap đã được cho là cổ điển, chủ yếu là để đảm bảo rằng bạn có thể viết một bản demo Blazor hấp dẫn hợp lý mà không cần phải loay hoay thêm bất kỳ biểu định kiểu nào. Điều thú vị là index.html không sử dụng bất kỳ thư viện JavaScript nào, ngoại trừ một thư viện. Đó là blazor.webassembly.js, tập lệnh tải xuống thời gian chạy và khởi động toàn bộ quá trình.
Bạn cũng nên chú ý phần này. Điều này lưu giữ nội dung ban đầu - thứ mà Blazor hiển thị khi trang tải lần đầu tiên, trước khi nó có cơ hội tải xuống trong thời gian chạy. Có một sự chậm trễ đáng chú ý ở đây, vì vậy bạn nên thay thế thông báo “Đang tải” bằng một số loại GIF động hoặc thông tin dành riêng cho ứng dụng.
Theo thiết kế, mỗi ứng dụng Blazor chỉ có một tệp HTML được liên kết với nó. Đó là bởi vì các ứng dụng Blazor được thiết kế tốt nhất dưới dạng ứng dụng web một trang. Họ có ảo tưởng về việc tải các chế độ xem "giống trang" khác nhau, nhưng trình duyệt không thực hiện bất kỳ điều hướng thực sự nào. [Nếu đúng như vậy, bạn cần phải khởi động lại toàn bộ thời gian chạy của Blazor trên mỗi trang mới, đây sẽ là một cơn ác mộng về hiệu suất.]
Vì vậy, wwwroot chỉ cho bạn cách trang của bạn khởi chạy Blazor, nhưng Blazor chuyển mã ứng dụng của bạn ở đâu? Boilerplate là một đoạn mã nhỏ được tạo tự động trong các tệp Program.cs và Startup.cs. Bạn có thể xem các tệp này, nhưng không cần phải chạm vào mã của chúng. Điểm bắt đầu thực sự là trang Index.razor của Blazor.
Trang và bố cục
Blazor sử dụng hệ thống định tuyến của riêng mình dựa trên các trang ảo. Thông thường, trang đầu tiên là Index.razor, nhưng bạn có thể tự do tạo các trang khác khi bạn yêu cầu. Dự án Starter Blazor bao gồm hai trang nữa - Counter.razor và FetchData.razor - đó chỉ là những ví dụ. Không có gì đặc biệt về những cái tên này và không cần thiết phải giữ lại những tệp này.
Vậy điều gì xảy ra trong trang Razor? Đây là một cái nhìn nhanh về Index.razor:
Lệnh @page "/"xác định đường dẫn mà trang này xử lý. Nói cách khác, Index.razor là trang gốc - nếu bạn không yêu cầu một trang .razor cụ thể, bạn sẽ kết thúc ở đây. Nhấp vào một trong các liên kết điều hướng trong ứng dụng mẫu và bạn sẽ đến một trang Blazor khác với một @pagechỉ thị khác .
Phần còn lại của Index.razor là HTML thông thường, với một vài điểm kỳ lạ. Trước hết phần tử là một trình giữ chỗ. Nó yêu cầu Blazor chèn nội dung của tệp SurveyPrompt.razor, là một khối HTML cơ bản với liên kết khảo sát. [Tách nội dung khảo sát trong một tệp riêng biệt giúp bạn có thể sử dụng lại nó trên một trang khác.] Bạn cũng sẽ nhận thấy những gì không có trong trang Index.razor - cụ thể là thanh bên có menu điều hướng và tiêu đề màu xám với Về liên kết. Các chi tiết này được xác định trong một mẫu khác, được gọi là MainLayout.razor:
Mỗi trang đều có cơ hội sử dụng bố cục. Index.razor sử dụng MainLayout.razor vì đó là mặc định được đặt trong tệp App.razor. Tuy nhiên, bạn cũng có thể chọn một cái gì đó khác bằng cách thêm @layoutthuộc tính ở đầu trang, như sau:
@layout MasterLayoutKhi bạn đã sắp xếp thông qua các kết nối này, bạn sẽ còn lại với một hệ thống mô-đun được thành phần hóa cao. Bạn chưa tìm hiểu kỹ tất cả các chi tiết, nhưng bạn đã thấy đủ để đến với phần thực sự thú vị - mã!
Ứng dụng EightBall
Tôi quyết định cung cấp cho Blazor một cơn lốc với một ví dụ rất đơn giản. Tôi đã chọn một màn trình diễn của "quả cầu tám ma thuật" khét tiếng. Ứng dụng này không chỉ dễ xây dựng một cách đáng kinh ngạc mà nó còn là ví dụ đầu tiên tôi thực hiện trên một khuôn khổ khác khi nó mới ra đời cách đây nhiều năm - WPF .
Việc xây dựng ứng dụng EightBall không dễ dàng như tôi mong đợi. Đầu tiên, quy trình làm việc của mã Blazor không giống với JavaScript vani vì mã của bạn không thể truy cập trực tiếp vào HTML DOM. [Đây là một hạn chế hiện tại của WebAssembly.] Vì vậy, không có ý nghĩa gì nếu bạn ngẫu nhiên lấy các phần tử và thay đổi thuộc tính của chúng. Bạn có thể làm điều đó với một lớp tương tác JavaScript, nhưng nó trở nên xấu đi nhanh chóng. Bạn cần thêm một lớp chức năng JavaScript bổ sung để gọi, điều này rất quan trọng.
Thay vào đó, Blazor có các cơ chế riêng mà bạn có thể thực hiện để cập nhật trang. Thay vì sử dụng mô hình điều khiển, Blazor ủng hộ một hệ thống liên kết dữ liệu, như Razor và nhiều khung JavaScript hiện đại. Điều đó có nghĩa là cách dễ nhất để đưa một giá trị vào một điều khiển trong trang web của bạn là tính toán nó trong mã, đặt một biến và liên kết biến đó trong trang của bạn.
Đây là một ví dụ đơn giản. Nếu bạn có và bạn muốn xử lý nhấp chuột của nó bằng mã Blazor, bạn thêm một @ titlethuộc tính đặc biệt . [Blazor sử dụng @biểu tượng làm điểm đánh dấu khi nó can thiệp vào HTML thông thường.] Dưới đây là một ví dụ:
Ask the Eight Ball @code { void AskEightBall[] { } }@answer
Đây là trang Index.razor hoàn chỉnh:
Tôi đã thực hiện thêm một số thay đổi sau điều này. Tôi phải ràng buộc classthuộc tính của cái để tôi có thể chuyển nó giữa hai lớp, làm cho nó hiển thị trong quá trình “suy nghĩ” và sau đó biến mất. Tôi cũng đã thêm asynctừ khóa và Tasklớp C # để quá trình này diễn ra mà không khóa trình duyệt.
Tôi ước tôi có thể nói rằng cách tiếp cận này là không đau đớn, nhưng tôi đã gặp phải một số lỗ hổng khi cố gắng áp dụng các kỹ năng JavaScript của mình trong thế giới Blazor. Khả năng hiển thị hình ảnh thay đổi không phải lúc nào cũng hoạt động trừ khi tôi gọi phương thức HasStateChanged [] của trang [và thậm chí sau đó nó hơi kỳ quặc]. Mô hình không đồng bộ của C # không phù hợp với mong đợi của tôi từ JavaScript. Tôi đánh giá cao việc sử dụng HTML và CSS thực [chứ không phải là một số loại hệ thống giao diện người dùng thay thế, như XAML trong Silverlight], nhưng tôi đã thất vọng vì chuyển hướng cần thiết để truy cập các thuộc tính thông qua ràng buộc.
Vấn đề tương tác
Tôi quyết định so sánh trải nghiệm của mình với một ví dụ phức tạp hơn nhiều. Tôi đã chọn một bản sao Tiểu hành tinh chạy bằng Blazor [bạn có thể tự tải mã xuống hoặc chơi trực tuyến ]. Ở đây tôi đã tìm thấy một ứng dụng hoạt động trơn tru và quản lý một thủ thuật gọn gàng: nó đặt logic của nó vào thư viện lớp và sử dụng lại nó trong một số loại ứng dụng .NET khác nhau, bao gồm cả giao diện Windows Forms cổ điển. Đẹp!
Nhưng không phải mọi thứ đều hồng hào như vậy. Tôi cũng tìm thấy một lượng lớn mã tương tác JavaScript. Các tính năng chính, như phát âm thanh, không thể truy cập được trong Blazor. Vào cuối cuộc khám phá của mình, tôi buộc phải kết luận rằng ngay cả những người theo chủ nghĩa thuần túy C # cũng sẽ thấy dễ dàng hơn khi viết ứng dụng đó bằng JavaScript thuần túy.
Đây là thiếu sót thực sự đầu tiên của Blazor - một lớp cách nhiệt bổ sung khiến các nhà phát triển có kỹ năng JavaScript kém hiệu quả hơn. Theo thời gian, Blazor có thể sẽ cung cấp các lớp riêng bao gồm các tính năng JavaScript chính như lưu trữ cục bộ, định vị địa lý và quản lý lịch sử. Nhưng hiện tại, những thành phần chính này cần JavaScript interop, có nghĩa là phải làm việc nhiều hơn và phức tạp hơn.
Thuế tải xuống
Blazor là một công nghệ mới và các nhà phát triển làm việc với Blazor đang phải đối mặt với một số khó khăn ngày càng tăng. Nhưng Blazor cũng có một nhược điểm khác không liên quan gì đến mô hình lập trình của nó - kích thước của nó. Và vấn đề này không phải là một điểm yếu nhỏ, mà là một phần lớn và mềm ở dưới cơ.
Để khảo sát thiệt hại, tôi đã chạy ứng dụng EightBall của mình và xem xét hoạt động mạng trong các công cụ dành cho nhà phát triển của Chrome. Đây là ảnh chụp nhanh, đã tắt bộ nhớ cache và được sắp xếp theo kích thước tệp:
Ở đầu danh sách, tốc độ chỉ dưới một megabyte, là mono.wasm, thời gian chạy Blazor giúp mọi thứ hoạt động. Thành phần lớn nhất tiếp theo là mscorlib.dll, chứa một số thư viện lớp .NET cơ bản. Sau đó là GIF động mà ứng dụng sử dụng, tiếp theo là toàn bộ các tệp DLL .NET nhỏ hơn nhiều. Cuộn xuống danh sách và cuối cùng bạn sẽ tìm thấy DLL cho chính ứng dụng EightBall, EightBallApp.dll, chỉ lớn 10 KB. Tổng kích thước của mọi thứ được tải xuống trong yêu cầu đầu tiên này để khởi động ứng dụng và lấy tất cả mã là khổng lồ 2,6 MB.
Trong một số bối cảnh, 2,6 MB khó có thể đảm bảo cho việc suy nghĩ thứ hai. Nhiều trang web sử dụng hình ảnh lớn, GIF động hoặc video vượt qua mốc này. Nhưng kích thước lớn của Blazor còn hạn chế hơn thế, bởi vì không có gì có thể xảy ra cho đến khi thời gian chạy và mã của bạn được tải xuống toàn bộ. Cho đến lúc đó, bạn đang xem thông báo “Đang tải” [hoặc bất kỳ nội dung nào khác mà bạn đã đưa vào phần index.html]. Thông thường, điều đó có nghĩa là bạn đang bị trễ khởi động từ 2–4 giây.
Blazor có thể được cắt nhỏ hơn không? Không có khả năng tối ưu hóa nhiều hơn để loại bỏ chính thời gian chạy của Blazor. Tuy nhiên, có rất nhiều cuộc thảo luận về các thuật toán rung cây có thể thu nhỏ các tệp DLL .NET khác bằng cách xóa các phần mã không được sử dụng trong ứng dụng của bạn. Bộ nhớ đệm cũng có thể giảm bớt một phần của vấn đề bằng cách cho phép bạn tải xuống thời gian chạy một lần và sau đó sử dụng lại nó trên các yêu cầu và trang web khác. Nhưng cho đến khi tình hình kích thước được cải thiện, có một dấu hoa thị khổng lồ được gắn vào Blazor.
Công cụ đo điểm chuẩn
Do kích thước của thời gian chạy, hiệu suất yêu cầu đầu tiên của Blazor là kém. Nhưng một khi mọi thứ bắt đầu, nó sẽ hoạt động như thế nào?
Trước khi đi sâu vào câu trả lời, điều quan trọng cần lưu ý là hiệu suất là một điều khó đánh giá đối với bất kỳ ứng dụng nào và càng khó hơn đối với ứng dụng dựa trên trình duyệt. Điểm chuẩn có nên xem xét tốc độ chạy các thuật toán nhất định không? Mất bao lâu để cập nhật giao diện người dùng? Nếu bạn không xây dựng trò chơi, rất có thể cả hai chi tiết này đều không phải là chi tiết hạn chế hiệu suất. Bạn có nhiều khả năng gặp phải các vấn đề nằm ngoài tầm kiểm soát của mình - chẳng hạn như chờ phản hồi từ API máy chủ chậm.
Blazor vẫn là một công nghệ ở giai đoạn đầu, với rất nhiều tính năng tối ưu còn được thực hiện. Năm ngoái, một số điểm chuẩn cho thấy hiệu suất của nó đã làm tụt hậu JavaScript bằng hệ số 100 . Gần đây hơn, cùng một bộ tiêu chuẩn cho thấy Blazor chậm hơn JavaScript cổ điển khoảng mười lần:
Điều này không đáng lo ngại như bạn nghĩ, vì vẫn còn mặt số để vặn. Theo thời gian, thời gian chạy của Blazor sẽ được tối ưu hóa triệt để hơn. Đồng thời, việc triển khai WebAssembly của trình duyệt cũng sẽ được cải thiện. Vì lý do đó, những điểm chuẩn mờ nhạt này không phải là một mối quan tâm lớn. Chúng là sàn nhà, không phải trần nhà.
Suy nghĩ cuối cùng: Điều tốt, điều xấu và Microsoft
Không khó để hiểu được sự phấn khích đằng sau Blazor. Câu hỏi quan trọng nhất là gì: Liệu nó có tồn tại được không?
Nếu bạn đã viết mã trong hơn một vài năm, bạn đã thấy cái chết của nhiều công nghệ được thổi phồng nóng bỏng khác. Hãy xem xét Microsoft Silverlight, là một phiên bản .NET hỗ trợ plugin nhẹ hơn chạy trên bất kỳ nền tảng nào. Đó là công nghệ hiện đại hóa web dành cho khách hàng phong phú của tương lai, cho đến khi nó không phải.
Việc Microsoft là chủ sở hữu của Blazor là một nhược điểm không nhỏ. Có, Blazor là một framework mã nguồn mở hiện đại. Nhưng nó cũng thuộc sở hữu của một công ty có lịch sử lâu đời từ bỏ công nghệ mới sáng chói của ngày hôm qua cho một thứ khác. Vì lý do đó, hầu hết các nhà phát triển sẽ tiếp cận Blazor với sự thận trọng xứng đáng. Miễn là JavaScript có thể làm mọi thứ mà Blazor có thể làm, mà không có thêm thách thức về kích thước tải xuống, hiệu suất và ngăn xếp công cụ mới, hầu hết các nhà phát triển sẽ ở lại.
Điều đó không có nghĩa là Blazor không thể giành được vị thế trong tất cả các lĩnh vực này. Nó thậm chí có thể trở thành một lực lượng chi phối sự phát triển của các ứng dụng web .NET. Nhưng nếu tôi phải đặt cược ngày hôm nay, đây là những gì tôi muốn ngân hàng. WebAssembly là tương lai. Nhưng hiện tại, Blazor chỉ là một khả năng thú vị.
Để nhận email mỗi tháng một lần với những câu chuyện công nghệ hay nhất của chúng tôi, hãy đăng ký bản tin Young Coder .