Blazorを選ぶ基準はこれだ！ #JavaScript

選定基準

選定基準は、チームの技術スタックにほぼ100%依存します。

もし、あなたのチームの技術スタックが、、

Asp.Net系のみ => Blazorを選択してください

単純に学習コストの問題です。JavaScript(TypeScript)のSyntaxに慣れるのがかなり大変なようです。また、使い慣れたVisual Studioで開発できるというのもポイントです。

ただし、状況によってはJavaScriptで補完する箇所も出てくるので、バランス感覚が重要です。

調査は骨が折れます。最近のUpdateにエコシステムがついてこれていないように見えます。

JavaScript系のみ => JavaScriptを選択してください

Browser上で、Blazorでできないことがあっても、JavaScriptでできないことはないからです。

例えば、モーダルコンポーネントで背面のスクロールを無効にしたい場合、Blazorでは、bodyエレメントを直接操作できず、JavaScript経由で操作することになります。

また、文献含むエコシステムが圧倒的に多いです。だいたい同じ悩みを持った人を見つけることができます。

どちらも持っている => JavaScriptを選択してください

エコシステムが圧倒的だからです。メンバーも採用しやすいです。

どちらも持っていない => JavaScriptを選択してください

学習コストはかかる前提で、Asp.Netよりは低いと思います。私の好みもありますが、Asp.Netのドキュメントは中々頭に入ってきません。

豊富なエコシステムにより、チュートリアル関連も多いです。

if( Asp.Net && !JavaScript ) decide(Blazor) else decide(JavaScript)ですね。

Blazorを選択した場合、以下に記載の特徴をしっかりと理解しておく必要があります。

私はNext.Jsを主に扱っているのですが、Next.JsのSSR(Server Component)とは全く異なるもので、これらの特徴を理解するのに骨が折れました。

Blazorの特徴

Render mode

BlazorはComponentごとにRendering modeを持つことができ、それぞれ以下のようになっています。特に、Interactive Serverは、デプロイ環境の選定にまで影響します。

Static Server

静的なComponentで、razorファイル内の@code内で設定したボタンクリックイベント等は無効になります。

コンパイルエラーにはなりませんが、Browserでページを表示してボタンを押下しても何も反応しません。
ただし、<script></script>で作成したJavaScriptをコールすることは可能です。単純にHtml + JavaScriptの組み合わせでロードされるので当然といえば当然ですね。

Formイベントにも対応しており、EditFormを用いたバリデーション、Submitは可能となっています。

明示的に指定しない限り、Static ServerがデフォルトのRender modeになります。
Interactive Server

Dynamic Serverではないことをよく注意してください。従来のSSRのような、ページリクエストに応じて動的にページを生成するものではありません。

このモードで動くComponentは、BrowserサイドからHtmlイベントの通知を受け取り、ServerサイドでUIをレンダリングして、差分更新をBrowserに通知し、それをBrowserが再描画します。

つまり、ServerサイドはStatefullで、相互的な通信を許可する状態でなければいけません。Blazorでは、SignalRというWebSocketベースのプロトコルで相互通信を実現します。

ということは、デプロイ環境でロードバランサーを使うときは、Stickey Sessionが必須です。更に、ServerサイドもAWS Fargateなどのサーバーレスではダメで、Stateを維持できるServerを配置することが必要になります。

ちなみに、ServerサイドのStateはCircuitと呼ばれ、チュートリアルプログラムレベルでも、1Circuitで400KBほどメモリを占有するらしいです。
Circuitは、Browserのタブごとに生成されるので、例えば、私が5タブで同じアプリケーションを開いていても、5Circuitがしっかり消費されます。

Interactive WebAssembly
WebAssemblyを利用したBrowserサイドでの描画になります。Browserでイベント処理が行われ、描画がおこなわれます。

一般的なCSRです。Interactive Serverが特徴的過ぎですね。

Interactive Auto
これは、Interactive ServerとInteractive WebAssemblyを自動で設定するもので、状況に応じて選択されます。

初回リクエストでは、Interactive Serverとしてレンダリングが行われますが、2回目以降は、Interactive WebAssemblyとして動作します。これは、キャッシュやBrowserへのRuntime到着などにより左右されます。

これもInteractive Serverが関わってくるので、上述したデプロイ環境の制約を受けてしまいます。

PrerenderingとLifecycleイベント

ここもNext.Js脳では全く理解できなかったところなので、ご紹介します

razorコンポーネントは、レンダリングの度にLifecycleメソッドと呼ばれる様々な一連の処理がServerサイドで走ります。この処理は、Prerenderフェーズでも実行されます。

なんと、Static ServerやInteractive WebAssemblyといったServerサイドが全く関係なさそうなRender Modeでも実行されます。

ちなみに、以下のように記載するとPrerenderを抑制することができます。

component.razor

@page "/"
@rendermode @(new InteractiveWebAssemblyRenderMode(prerender: false))

<div>Component</div>

@code {}

最後に

Blazorでも、ReactでいうProviderや、Next.jsのLayout、Reduxのような状態管理の仕組みは存在しており、FWの機能を使って便利なことができる点は良いと思います。

Microsoftが激押ししているのも納得のフレームワークですね。

もし時間的な余裕があるのであれば、POCでしっかりめのアプリケーションをBlazorで作ってみることをお勧めします。

※これはAsp.Net Core 8.0時の記事です。