6年前の記事の答え合わせ
この記事を書いている 2023年12月現在からさかのぼること、6 年近く前の 2018年3月に、以下の記事を書きました。
これはまだ Blazor が Steve Sanderson 氏個人の実験的プロジェクトだった当時、自分が Blazor に初めて出会ったときの衝撃を受けて、興奮冷めやらぬ内に Qiita に投稿した記事です。
あれから 6 年近く経ち、Blazor の状況はどう変わったのでしょうか。また、上記記事は当時の勘違いによる誤りも含まれています。そこで本記事では、上記「C# で Single Page Web Application が書ける Blazor が凄かった件」の記事内容を引用しながら、訂正や答え合わせをしてみたいと思います。
コンポーネントファイルの形式
Blazor の何がうれしいのか?
...
しかも Blazor では、ちゃんとクライアント側実装におけるコンポーネントとして機能するように調整されているのです。
Foo.cshtml を作成したら、それだけで、ほかの .cshtml 内にて<c:Foo>って書けるんです。
当然、<c:Foo>の箇所は、Foo.cshtml の実装内容でレンダリングされます。
Blazor のコンポーネントを記述するファイルの拡張子は、2019年9月の Blazor の正式リリースまでに、.cshtml から .razor に変更されました。
また、コンポーネントをマークアップする際の <c:... の名前空間プレフィクスも不要になりました。
Blazor WebAssembly の実行の仕組み
C# で書ける!
...
どうしてそんなことができるのかっていうと、C# のコンパイル結果である .NET の > IL コードを WebAssembly にコンパイルする Blazor ランタイムが最初にブラウザにロード＆実行されてて、こいつが仕事してるわけ。
IL コードを WebAssembly にコンパイルするのではなく、IL コードに対するインタープリターでした。これは記事作成当時の勘違いによる誤りです。
なお、2021年11月にリリースされた .NET 6 では、Blazor WebAssembly における AOT コンパイルの機能が追加され、ビルド時に WebAssembly ネイティブなコードを出力して、演算処理性能を向上させることもできるようになりました。
Blazor WebAssembly のアセンブリファイル形式
なので、実際、Blazor アプリをブラウザで開くと、System.dll とかがどんどんブラウザに HTTP GET で吸い上げられていきますw
本記事作成時点の最新版、2023年11月リリースの .NET 8 では、Blazor WebAssembly におけるアセンブリファイルの既定のファイルフォーマットが、PE フォーマットから WebAssembly モジュールフォーマットに変更され、ファイルの拡張子も .dll から .wasm になりました。
ルーティングの定義
ブラウザで .NET が動くだけじゃなく、SPA フレームワークとして形にしている
...
URL ルーティングも、なんの構成を記述しなくても URL セグメントがそのままコンポーネントにマップされるのが既定の動作のようです。
2019年9月の Blazor の正式リリースまでに、.razor 内で @page "..." ディレクティブで URL ルートを定義する仕様に変更されました。
VSCode による開発
ちなみに、Blazor アプリ開発は、dotnet CLI を使うことで、非 Windows OS 上でも、ターミナルと任意のエディタで開発はできるはずです。
が、現時点では、Windows OS 上で Visual Studio （Visual Studio Code ではなく）を使わないとこのような IDE 支援は得られない模様です。
（Visual Studio も、素の状態では無理であるようで、Blazor 用の拡張を追加しています）
2023年12月現在では、Visual Studio Code でも、コード補完をはじめとした支援機能を潤沢に得られ、macOS や各種 Linux ディストリビューション上での Blazor アプリケーション開発は十二分に実用レベルにあるのではないかと思われます。C# DevKit という Visual Studio Code 用拡張も登場し、ソリューションエクスプローラーが付属するなど、ますます開発体験が Visual Studio に似てきています。
また Visual Studio も現在の最新版 2022 では、既に Blazor をファーストレベルでサポートしており、とくに拡張を追加することなく Blazor アプリケーション開発が可能です。
番外編・JavaScript 開発における自動 import 補完
プロジェクトと名前空間を使ったアプローチなので、import 地獄から解放される!
これは Blazor 側の話ではなく、JavaScript 開発の側の話ですが、件の記事作成後ほどなくして、Visual Studio Code や言語サーバーなど、JavaScript 開発周りの開発者支援がメキメキ強化され、JavaScript 開発でも自動で import が補完されるようになり、大変快適になりました。
Blazor WebAssembly のダウンロードサイズ
ダウンロードサイズ
...
今回自分で試作したレベルだと、ダウンロードサイズが 16 メガバイト (!) にも達してます。
開発時は今もそれくらいか、むしろもっとサイズ大きくなりがちです。しかし、それは開発中の話です。配置用にリリース構成で発行処理したあとは、IL トリミングや Brotli 圧縮などの効果で、1桁メガバイトに収まることも少なくありません。
なお、件の記事でいうところの "Blazor" とは、現在で言うところの "Blazor WebAssembly" に該当します。Blazor Server であれば、常時接続が必要になる代わりに、コンテンツサイズは極小で、他の JavaScript ベースの SPA よりも小さいです。また、2023年11月リリースの .NET 8 からは、Blazor Server としてさくっと動作開始しつつ、裏でアセンブリファイルをダウンロードしておき、次回からは WebAssembly として動くというハイブリッドな動作形態、"Auto レンダーモード" も搭載されました。さらに同じく .NET 8 からの動作形態・Blazor SSR と混合・併用できるようになったこともあり、Blazor WebAssembly におけるコンテンツサイズが大きいという問題はさほど目立たなくなっていると思われます。
ただこれは AOT コンパイルなどの技術が活用されることで、ファイルサイズは激減する可能性もあります。
これは当時の誤解に基づく誤りで、むしろ逆です。2021年11月リリースの .NET 6 から使えるようになった AOT コンパイルを行なうと、演算処理性能は向上しますが、それと引き換えに、ビルド時間が長くなることに加え、サイズが2倍強に膨らみます。
正式リリース時期
今はまだ実験段階！
Blazor は、2018年2月に、Steve Sanderson 氏の個人プロジェクトから、ASP.NET Core 開発チームに移管されました。その後、まずは Blazor Server が 2019年9月に正式リリース。続く 2020年11月に Blazor WebAssembly も正式リリースしました。2023年11月リリースの .NET 8 では、Blazor SSR もリリースされ、ASP.NET Core MVC や Razor Pages の担当領域であった MPA 開発にも進出する勢いです。
達成目標に挙げられた機能一覧
でも、Blazor の GitHub リポジトリの README を読む限りは、網羅するつもりの機能一覧 (下図) は鼻息荒いですw
. Routing
· Layouts
. Forms and validation
. Dependency injection
. JavaScript interop
. A component model for building composable UI . Live reloading in the browser during development
· Server-side rendering
. Full .NET debugging both in browsers and in the IDE
. Rich IntelliSense and tooling
. Ability to run on older (non-WebAssembly) browsers via asm.js
. Publishing and app size trimming
上記リストに記載されている、2018年時点で達成目標に挙げられた各種機能ですが、2021年11月リリースの .NET 6 で、1点だけを除きすべて達成されました。達成されなかったのは「Ability to run on older (non-WebAssembly) browsers via asm.js」、つまり、WebAssembly をサポートしないブラウザで asm.js を使ってフォールバック動作させる、という点のみです。現在では、Blazor Server もありますし、また、WebAssembly が使えない Web ブラウザも実質ないに等しいでしょうから (一部の塩漬け環境とかは例外的にあるでしょうけど)、もうこの達成目標は意味を成さなくなりましたね。
おわりに
6年前の記事の答え合わせは以上となります。
Blazor が実験的プロジェクトだった頃から 6 年が経過し、Blazor もかなり成熟してきました。「キワモノすぎ」「どうせ Silverlight の二の舞でしょ」とも言われてきた Blazor ですが、どうしてどうして、2023年11月に開催された Microsoft 公式のオンラインイベント ".NET Conf 2023" ではクライアント Web アプリ開発のカテゴリではもう Blazor 一色でした。
もちろん Blazor は決して「銀の弾丸」ではないですし、クライアント Web アプリ開発業界でのシェア率は低いのでしょう。とはいえ、やはり層によっては、他に代わるもののない最適かつ強力なフレームワークとして、その存在感を示していると感じています。
また、長い視点で見たときには、Blazor とていずれは廃れる日が来るのでしょう。でもそれは Blazor に限らずどのようなフレームワークにもあることです。むしろこの 6 年、大きな破壊的変更もなく順当に進化と機能拡充を進めてきた Blazor は、安定かつ長生きしそうな予感もします。
ということで、まだまだ当面は Blazor とともに、ソフトウェア開発で価値提供を続けていきたいと思います。
Happy Coding! :)