Blazorオープンソースコンポーネントライブラリ - Masa Blazor

公式の説明（Blazor）

Blazor を使用すると、JavaScript ではなく C# を使用して対話型の Web UI を構築できます。Blazor アプリは、C#、HTML、CSS を使用して実装された再利用可能な Web UI コンポーネントで構成されています。クライアントとサーバーの両方のコードは C# で記述され、コードとライブラリを共有できます。

Blazor は、.NET を使用して対話型のクライアント側 Web UI を生成するフレームワークです。

JavaScript の代わりに C# を使用して、リッチで対話型の UI を作成します。
.NET で記述されたサーバー側とクライアント側のアプリケーションロジックを共有します。
UI を HTML と CSS としてレンダリングし、モバイルブラウザを含む多くのブラウザをサポートします。
Docker などの最新のホスティングプラットフォームと統合します。

.NET を使用したクライアント側 Web 開発には、次の利点があります。

JavaScript の代わりに C# を使用してコードを記述します。
既存の .NET ライブラリエコシステムを活用します。
サーバーとクライアント間でアプリケーションロジックを共有します。
.NET のパフォーマンス、信頼性、セキュリティの恩恵を受けます。
Windows、Linux、macOS 上で Visual Studio を使用して生産性を維持します。
安定していて、機能が豊富で、使いやすい共通の言語、フレームワーク、ツールのセットに基づいて構築します。

このあたりで、読者の中には「なんだそれ」と思う方もいるかもしれません。確かに一部誇張されています。特に、VS が 3 つのプラットフォームで効率的に動作するという点は…うーん。残りは気楽に見守りましょう。

Blazor vs MVC

MVC とは

公式の説明：ASP.NET Core MVC は、"Model-View-Controller" デザインパターンを使用して Web アプリと API を構築するためのリッチなフレームワークです。

重要なポイント：Blazor は対話型の Web UI であり、MVC は Web アプリと API です。

対話型 Web UI とは

Google や Baidu で検索しても説明は見つからず、Wiki も困惑しています。

試しに理解してみましょう。対話型 Web UI の重点は「対話」にあります。Blazor の公式説明では、C# で JavaScript を置き換えるとされています。では、JavaScript の機能を見てみましょう。Baidu から引用します。

HTML ページに動的テキストを埋め込む
ブラウザイベントに応答する
HTML 要素の読み書き
サーバーにデータを送信する前にデータを検証する
訪問者のブラウザ情報を検出する。Cookie の制御（作成や変更など）

これらの基本機能により、ユーザーは静的ページを行き来する必要がなくなり、確かに体験は向上します。

Blazor の利点は何か

ある程度の対話機能を提供し、純粋な静的ページではなくなります。MVC でも JavaScript を使用して同じ効果を得ることはできますが、JavaScript を習得する必要があり、さらに jQuery、Angular、Vue なども学ぶ必要があるかもしれません。一方、Blazor が提供する対話機能は C# を使用します。

宣伝はこれくらいにして、本当に 100% C# で済むのでしょうか？それは難しく、互換性やパフォーマンスなど、さまざまな問題に直面します。では、使わなくてもいいのでしょうか？ちょっと待ってください、まだ続きがあります。

Blazor vs モダンフロントエンド（Angular、Vue など）

いくつかの観点から比較してみましょう。

デバッグ

Blazor：Visual Studio + F5、VS Code / コマンドラインツール + dotnet watch

WebPack よりはるかに速く、Vite と同程度です。

複雑でないシナリオでは Hot Reload は機能しますが、奇妙な問題が多すぎます。将来性はありますが、現時点では Ctrl + F5 で起動するか、コマンドラインを使用するのが良いでしょう。

VS 2022 の Ctrl + F5 は Hot Reload をサポートしています。

モダンフロントエンド：Webpack / Vite

オールインワンパッケージ

Vue を例にとると、Vue オールインワンパッケージには Vue CLI、Vue Router、Vuex が含まれます。

Blazor：

CLI：dotnet CLI
Router：Microsoft.AspNetCore.Components.Routing.Router
Vuex：Blazor の状態管理。違いは、WASM では状態がブラウザのメモリに保存されるのに対し、Server ではサーバーのメモリに保存されることです。また、Blazor の状態管理は .NET の機能を活用しており、ネイティブで永続化ストレージ、回線を越えた保存（Server 下でのサーバーメモリ共有）、ASP.NET Core の保護されたブラウザストレージ（Server 限定機能）をサポートしています。

コンポーネントライブラリ

主要な Bootstrap、Ant Design、Material Design などは両方にあります。ただし、モダンフロントエンドの長年の蓄積により、品質には差があります。

豊富さに加えて、Blazor は JavaScript から読み込んで呼び出すことができ、Angular、React などのコンポーネントを生成することもできます。

これは「C# で JavaScript を置き換える」という方針と矛盾するように見えますが、大きなエコシステムに溶け込むのも悪くないでしょう。

次の図は、Blazor が提供する inventory-grid コンポーネントが React で参照されている例です（もちろん Angular でも可能です）。

さらに驚くべきことに、React で再利用される Blazor コンポーネントは Hot Reload もサポートしています。Hot Reload の現状はさておき、この方向性だけでも Hot Reload の未来に期待できるでしょう。

React だけでなく、WPF にも再利用可能なコンポーネントを提供できます。

サードパーティライブラリ

フロントエンドでよく使われるライブラリをいくつか比較します。

ネットワーク：モダンフロントエンドは axios、Blazor は HttpClient
データ操作：モダンフロントエンドは Lodash、Blazor は Linq
時間：モダンフロントエンドは moment.js、Day.js、Blazor は DateTime ファミリー
リアクティブプログラミング：モダンフロントエンドは rx.js、Blazor は Rx.Net（使ったことはありませんが、理論上は .NET のものはほぼ使えるはずです。間違いがあればご指摘ください）
Mock：モダンフロントエンドは Mock.js、Blazor は Moq。もちろん、Mock 以外にもエンドツーエンドのものも両方にあります。

比較すると、.NET にはむしろ利点があるように見えます。では完璧かというと、そうでもありません。欠点も挙げましょう。

チャート：モダンフロントエンドは ECharts などがあり、Blazor は何も言いたくありません。

現時点では、Blazor には成熟した無料のチャートコンポーネントライブラリは確かにありません。しかし、Blazor は JavaScript と相互運用できるため、ECharts を呼び出すのは簡単で、少し手間がかかる程度です。

リッチテキストエディタ、ドラッグ＆ドロップ…
Blazor は不満そうにグループチャットを退出しました…

パッケージ管理

Blazor：NuGet
モダンフロントエンド：NPM、Yarn

パフォーマンス

データは直感的ではありませんが、まずは .NET Conf 2021 のデモのスクリーンショットをご覧ください。

定量データはありますか？あります。

動画アドレス：https://sec.ch9.ms/ch9/daba/468d5211-982b-4c86-8b51-e1c8824edaba/dotNETConfNewBlazorWebAssembly_high.mp4

AOT ですべて解決できるのでしょうか？そうでもありません。少なくともアプリケーションサイズは確かに大きくなりますが、だからといって AOT が特定のシナリオの問題を解決できないわけではありません。技術は常に、適切なシナリオで使用するために選択されるべきであり、盲目的に使用すべきではありません。

これで終わりですか？

もちろん違います。実際、この比較は Blazor にとって公平ではありません。なぜなら、Blazor は .NET の肩の上に立ち、さらに多くの利点を持っているからです。例えば、ネイティブのジェネリックサポート、DI、オブジェクト指向設計（TS もですが）、数え切れない .NET クラスライブラリ、クロスプラットフォームアプリケーション（MAUI）などです。

Blazor の欠点だけを見る必要はありません。.NET の上に立つフロントエンドがどこまで行けるのかを見るのも、私たちが期待していることではないでしょうか？

ここで、.NET の古参の大御所たちが「Silverlight！」と言い出すかもしれません。確かにそうですが、今回は WASM はプラグインのダウンロードを必要としません。

Web Assembly vs Server（サーバーサイドレンダリング）

Web Assembly：WebAssembly は新しいエンコード方式で、モダンなウェブブラウザで実行できます。これは低レベルのアセンブリのような言語であり、コンパクトなバイナリ形式を持ち、ネイティブに近いパフォーマンスで実行でき、C / C ++ などの言語のコンパイルターゲットとして、Web 上で実行できるようにします。また、JavaScript と共存できるように設計されており、両者が連携して動作することを可能にします。
Server（サーバーサイドレンダリング - SSR）：コンポーネントをサーバー上の HTML 文字列としてレンダリングし、ブラウザに直接送信し、最後にそれらの静的マークアップをクライアント上の完全に対話可能なアプリケーションに「アクティベート」します。

なぜ SSR を使うのか

サーバーサイドレンダリング (SSR) の主な利点は次のとおりです。

SEO の向上：検索エンジンのクローラーが完全にレンダリングされたページを直接表示できるため。
コンテンツ到達時間 (time-to-content) の短縮

いつ SSR を使うべきか

サーバーサイドレンダリング (SSR) を使用する際には、いくつかのトレードオフを考慮する必要があります。

開発環境の制約。ブラウザ固有のコードは、特定のライフサイクルフックでのみ使用できます。一部の外部拡張ライブラリは、サーバーレンダリングアプリケーションで動作させるために特別な処理が必要になる場合があります。
ビルド設定とデプロイに関する追加要件。任意の静的ファイルサーバーにデプロイできる完全な静的シングルページアプリケーション (SPA) とは異なり、サーバーレンダリングアプリケーションはサーバー側の実行環境が必要です。
サーバー側の負荷増加。

サーバーサイドレンダリング vs プリレンダリング (SSR vs Prerendering)

サーバーサイドレンダリング (SSR) の調査が、少数のマーケティングページ（例：/、/about、/contact など）の SEO 改善のみを目的としている場合、プリレンダリングが必要かもしれません。ウェブサーバーを使用して動的に HTML をコンパイルする代わりに、プリレンダリングを使用して、ビルド時に特定のルート向けの静的 HTML ファイルを生成します。利点は、プリレンダリングのセットアップがより簡単で、フロントエンドを完全な静的サイトとして扱えることです。

Blazor Server は Prerendering をサポートしています。

Blazor は Web Assembly と Server のどちらを選ぶべきか

.NET Conf 2021 の図をご覧ください。

まとめると：

Server は永続的な長い接続を必要とし、UI の遅延が大きくなります。
Web Assembly はダウンロードサイズが大きく、実行時のパフォーマンスが遅くなります。

私たちは何をしているのか

またまたよくある問題です。.NET のカバー範囲が広すぎるため、すべての問題を解決するのは困難です。私たちは利害を比較検討した後、.NET エコシステムに少しでも貢献できるでしょうか？

オープンソースのコンポーネントライブラリ

コンポーネントライブラリに戻りますが、現在市販のコンポーネントライブラリは少なくありません。なぜこの泥沼にさらに足を踏み入れる必要があるのでしょうか？

コンポーネントライブラリを開発したことのある人、またはソースコードに貢献したことのある人は、コンポーネントを書くのがいかに複雑かを理解しているはずです。また、デザインに対する美的感覚は人それぞれ異なります。自分が好きなデザインの実装が提供されていない場合、どうすればいいでしょうか？最初から書くのは大変です。そこで、私たちはあることを試みました。

まずは大まかな考え方をご覧ください。

アーキテクチャ図

簡単に分析します。

Blazor をベースに、Blazor Component という新しいコンポーネントライブラリを構築します。

その特徴は何でしょうか？

インタラクションのみを提供し、スタイルは提供しません。
Dom 構造を標準化します。
カスタマイズ可能なほとんどすべてのスロット（Vue から引用した概念）を公開し、スロットの Dom を置き換えることを許可します。

スロットとインタラクションの統一されたユニットテスト（現在 38%、短期目標は 80%、長期目標は 90% 以上）。
Material Design（Vuetify からスタイルを引用）に基づくサンプルプロジェクト。実運用に使用可能です（私たち自身の会社でも使用しており、世界のトップ 500 企業でも使用されています）。
特定の Design + スタイル制御プロパティ + 特殊なインタラクションをベースに、新しいコンポーネントライブラリを迅速に実装できます。

未来は期待に満ちています。私たちは次のような未来を願っています。

お恥ずかしながら、ByteDance の話題に便乗しました。

MASA Blazor

Blazor Component と Material Design に基づく Blazor コンポーネントライブラリ。

現在までに合計 68 の基本コンポーネントがあり、今後も増え続けます。
プリセットコンポーネント。.NET 機能と深く統合され、よく使われる複合コンポーネント（例：URL、パンくずリスト、メニューの 3 連動、高度な検索、i18n など）を提供します。
MASA Blazor Pro は、さまざまな一般的なシナリオ向けのプリセットレイアウトを提供します。
フルタイムのチームがメンテナンスし、Issue への迅速な対応。
有名企業が使用しており、将来の MASA Stack 製品ラインでも引き続き使用され、新機能が追加され続けます。
無料、オープンソース。

また、将来的には 1 クリックでのテーマ切り替え（コードでの切り替えはすでに提供）、プリセットレイアウト、データ表示コンポーネント、ワークフローコンポーネントなどをサポートする予定です。