ゼロから始めるBlazor：第1章 — Blazorとは何か？

ゼロから始めるBlazorの第1章へようこそ。このシリーズの目的と対象読者を説明したイントロ記事を見逃した方は、まずそちらをお読みください — 短いです。

この章では根本的な疑問に答えます：Blazorとは何か？ シンプルに聞こえますが、特に「Blazor」が年月を経てわずかに異なる意味を持つようになってきたため、答えにはいくつかの層があります。この記事の終わりには、Blazorが何であるか、.NETエコシステムにどのように適合するか、さまざまなレンダリングモデルが何であるか、そしてなぜJavaScriptフレームワークの代わりにそれを選ぶかもしれないかがわかるでしょう。

簡単な歴史

Blazorは2017年頃、MicrosoftのSteve Sandersonによる実験的プロジェクトとして始まりました。アイデアは挑発的でした：WebAssemblyを使ってブラウザでC#を実行し、JavaScriptの必要性を完全に排除するというものでした。それはプルーフ・オブ・コンセプトであり、名前はBlazerとRazor — Blazorが最終的にその上に構築されることになるテンプレートエンジン — の意図的な組み合わせでした。

この実験はMicrosoftが真剣に受け止めるほどの熱狂を生み出しました。Blazorは2019年9月のASP.NET Core 3.0の一部として出荷され、最初はBlazor Server — サーバーでC#コードを実行し、リアルタイムのSignalR接続を使用してブラウザにUI更新を送信するモデルとして登場しました。Blazor WebAssemblyはASP.NET Core 3.1の一部として2020年5月に続き、フレームワークに真のクライアントサイド実行をもたらしました。

.NET 6と7は開発者体験を洗練させました。そして2023年11月にリリースされた.NET 8は、MicrosoftがフルスタックウェブUIと呼ぶものでレンダリングモデルを根本的に再考しました。静的サーバーサイドレンダリング、ストリーミングレンダリング、インタラクティブサーバー、インタラクティブWebAssembly、そして新しいAutoモードが、単一プロジェクトの同じ屋根の下に共存するようになりました。.NET 9はこの基盤の上に構築し、粗い部分を整えました。

これが今日の現状です。

Blazorが実際に何であるか

本質的に、Blazorは**.NET向けのコンポーネントベースのUIフレームワーク**です。コンポーネントからUIを構築します — 状態を保持し、イベントに反応し、より大きな構造に合成できるC#とHTMLマークアップの自己完結型の部品です。ReactやVueで作業したことがある場合、そのメンタルモデルは馴染み深く感じるでしょう。重要な違いは、JavaScriptの代わりにC#を書くということです。

Blazorのコンポーネントは.razorファイルに記述されます。.razorファイルは、ASP.NET MVCビューですでに知っているかもしれないRazor構文を使用してHTMLマークアップとC#コードを混在させます。シンプルなコンポーネントは次のようになります：

@page "/counter"

<h1>カウンター</h1>
<p>現在のカウント: @currentCount</p>
<button @onclick="IncrementCount">クリックしてください</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

JavaScriptは見当たりません。@onclickディレクティブはボタンクリックをC#メソッドに結びつけます。@currentCount式は現在の値をレンダリングします。状態が変更されると、BlazorはDOMで何を更新するかを把握します。

これがコアです。それ以外のすべて — ルーティング、依存性注入、フォーム、HTTP呼び出し — このコンポーネントモデルの上に構築されています。

レンダリングモデル

ここには多くの混乱があるので、正確に見ていきましょう。今日の「Blazor」は単一のデプロイメントモデルではなく、レンダリングモードのファミリーを指します。違いを理解することが重要なのは、パフォーマンス、インフラ要件、そしてコンポーネントができることとできないことに影響するためです。

静的SSR

最もシンプルなモードです。RazorコンポーネントがサーバーでHTMLにレンダリングされ、そのHTMLがブラウザに送信されます。永続的な接続もなく、WebAssemblyもなく、デフォルトではクライアントサイドのインタラクティビティもありません。これは本質的にRazor Pagesが行うことですが、コンポーネントモデルを使用しています。

コンテンツの多いページ、ランディングページ、ライブインタラクティビティが不要なものに使用してください。

インタラクティブサーバー

コンポーネントコードがサーバーで実行されます。ブラウザとサーバー間にSignalR WebSocket接続が確立されます。ボタンをクリックしたり入力フィールドに入力したりすると、イベントがWebSocketを通じてサーバーに送られ、C#が実行され、差分が計算され、DOMの更新がブラウザに送り返されます。

利点： サーバーリソース（データベース、ファイルシステム、シークレット）への完全なアクセス。高速な初期ロード。小さなダウンロードサイズ。WebAssemblyサポートなしのブラウザでも動作します。

欠点： すべてのユーザーインタラクションがサーバーへの往復を必要とし、レイテンシが増加します。サーバーリソースはアクティブな接続数に応じてスケールします。接続が切断されるとアプリが劣化します。

基幹業務アプリ、内部ツール、オフライン機能よりもサーバーサイドデータアクセスが重要なアプリに使用してください。

インタラクティブWebAssembly

.NETランタイムがブラウザにダウンロードされ、アプリが完全にクライアントで実行されます。初期ダウンロード後、アプリは完全にオフラインで動作し、すべてのインタラクションが即座です — UIロジックのためのサーバー往復がありません。

利点： 真のクライアントサイド実行。オフライン動作。アプリロード後のサーバー負荷軽減。

欠点： より大きな初期ダウンロード（.NETランタイム + アプリ）。より遅い最初のロード。サーバーサイドデータにアクセスするにはAPIが必要です。

オフライン機能を持つアプリ、即時の応答性が必要なツール、UIにサーバー処理が不要なシナリオに使用してください。

Autoモード

.NET 8で導入されました。アプリはインタラクティブサーバーモードで開始します（高速な初期ロード、WebAssemblyのダウンロードを待たない）。WebAssemblyファイルがバックグラウンドでダウンロードされると、以降の訪問は自動的にWebAssemblyモードに切り替わります。

これにより、サーバーモードの高速な最初のロードと、最終的にはWebAssemblyの完全なクライアントサイド実行の両方が得られます。理解するのが最も複雑なモデルですが、多くのアプリにとって実用的なデフォルトです。

同じアプリでモードを混在させる

.NET 8以降では、アプリ全体に対して単一のレンダリングモードに縛られません。マーケティングランディングページは静的SSRにできます；認証されたダッシュボードはインタラクティブサーバーにできます；データ視覚化ウィジェットはインタラクティブWebAssemblyにできます。フレームワークが遷移を処理します。

このシリーズでは、インタラクティブサーバーから始めます。なぜなら、最も簡単に動作させることができ、最も直感的なメンタルモデルを持っているからです。他のモードは進めながら探求していきます。

BlazorとJavaScriptフレームワークの比較

React、Angular、またはVueで開発したことがある場合、おそらくこれが気になる比較でしょう。

類似点は本物です。 BlazorのコンポーネントモデルはReactのそれと意図的に似ています。props（Blazorではパラメータ）、ローカル状態（@codeブロックのフィールド）、ライフサイクルフック、そして同じ一方向データフロー / イベントアップの通信パターンがあります。Reactを知っていれば、数時間以内に慣れるでしょう。

重要な違いは言語です。 BlazorではC#を書きます。ビジネスロジック、バリデーションルール、データモデルをBlazorフロントエンドとASP.NET Coreバックエンドの間で共有できます。すでにC#にあるUserクラスをTypeScriptで重複して作成する必要はありません。

エコシステムのギャップは現実ですが縮まっています。 npmエコシステムは巨大です。UIコンポーネントのNuGetエコシステムは小さいですが、大幅に成長しています。特定のチャートライブラリやドラッグ＆ドロップウィジェットが必要な場合、JavaScriptにはまだより多くのオプションがあります。しかし、ほとんどの基幹業務アプリケーションにとって、.NETの世界で利用可能なものは十分以上です。

JavaScriptの相互運用性は必要な時のために存在します。 BlazorではC#からJavaScriptを、JavaScriptからC#を呼び出すことができます。.NETラッパーがないブラウザAPIや既存のJSライブラリを使用したい場合、相互運用が利用できます。レイヤーを追加しますが、苦痛ではありません。

正直な答え： チーム全体がJavaScript開発者であり、SEO、パフォーマンス、npmエコシステムが重要な公開製品を構築している場合はJavaScriptにとどまってください。チームが.NET開発者であり、内部または基幹業務アプリケーションを構築しているか、フロントエンドとバックエンド間のコード共有が重要な場合は、Blazorは説得力のある選択です。

一緒に進めるために必要なもの

このシリーズの残りのために必要なもの：

• .NET 9 SDK — dot.netからダウンロード
• IDE — Visual Studio 2022（Communityエディションは無料）、C# Dev Kit拡張機能付きのVS Code、またはJetBrains Rider
• C#の基本的な知識 — クラス、プロパティ、インターフェース、async/await

以上です。Node、npm、webpackは不要です。

次回

第2章では、最初のBlazorアプリをスキャフォールドし、プロジェクト構造を確認し、ローカルで実行できることを確認します。最後には動作するアプリと各ファイルが何をしているかの明確な全体像を持てるようになります。

そこでお会いしましょう。