Blazor：技術紹介

今日、ASP.NETチームは、BlazorプロジェクトがASP.NET組織リポジトリに移動したことを発表しました 。 Blazorをサポート対象製品に開発できるかどうかを確認するために、実験段階を開始しています。 これは大きな前進です！







ブレイザーとは何ですか？ これは、.NETで記述され、WebAssemblyを使用して起動されるブラウザーアプリケーション用のフレームワークです。 リッチでモダンな単一ページアプリケーション（SPA）のすべての利点を提供すると同時に、サーバーおよびクライアントの共通コードに至るまで、.NETを最初から最後まで使用できます。 発表付きの投稿では 、主なアプリケーションのケース、用語などが詳細に説明されています。



この投稿では、これがどのように機能するかに興味がある人のために、技術的な詳細についてより深くお話したいと思います。

ブラウザで.NETを実行する

.NETでSPAフレームワークを構築する最初のステップは、何らかの方法でブラウザーで.NETコードを実行できるようにすることです。 最後に、WebAssemblyのおかげで、オープンスタンダードを使用して実行でき、任意のブラウザで（プラグインなしで）動作できます。



WebAssemblyは現在、モバイルブラウザを含むすべての主要なブラウザでサポートされています。 これは、ダウンロードされたデータの量を減らして実行を高速化するために最適化されたコンパクトなバイトコード形式です。 多くの開発者がそう思うかもしれないという事実にもかかわらず、WebAssembly は新しいセキュリティ問題を導入しません。これらは通常のバイナリファイル（x86 / x64など）ではないためです-これは同じことしかできないバイトコードを含む新しい形式ですおよびjavascript。



では、どのようにして.NETを実行できますか？ これは、 MonoチームがプロジェクトにWebAssemblyサポートを追加したためです。 ニュースを見逃した場合、Monoプロジェクトは2016年にMicrosoftの一部になりました。 Monoは、クライアントプラットフォーム（ネイティブモバイルアプリケーションやゲームなど）の公式.NETランタイムです。 WebAssemblyはクライアントプラットフォームの1つにすぎないため、Monoを使用することは非常に合理的です。



Monoは、 解釈モードとAOTの2つのモードでWebAssemblyで実行できます。

解釈

解釈モードでは、 MonoランタイムはWebAssemblyにコンパイルされますが、.NETアセンブリはコンパイルされません。 ブラウザはランタイムをダウンロードして起動します。ランタイムは、通常の.NETツールチェーンによってコンパイルされた標準の.NETアセンブリ（通常の.NET .dllファイル）をロードして実行できます。







これは、通常のCLRの場合、メインコアがネイティブコードにコンパイルされて配布され、.NETアセンブリを読み込んで実行する方法と似ています。 唯一の重要な違いは、デスクトップCLRがJITコンパイルを積極的に使用して実行を高速化するのに対して、WebAssemblyのMonoは従来の解釈モデルにより近く機能することです。

事前（AOT）コンパイル

AOTモードでは、.NETアプリケーションは、アセンブリされるとすぐに純粋なWebAssemblyバイナリに変わります。 ランタイムには解釈がありません-コードは通常のWebAssemblyコードのように実行されます。 このモードでは、Monoランタイムの一部（ガベージコレクションなどの低レベルの.NETサービス）をロードする必要がありますが、.NETファイルパーサーなどのコンポーネントを破棄できます。







これは、昔からngenユーティリティが .NETアセンブリをネイティブマシンコードにAOTコンパイルする方法、または最近登場した本格的なネイティブAOT .NETランタイム-CoreRTに似ています。

AOTに対する解釈モード

どちらのモードが良いですか？ まだわかりません。



ただし、解釈モードはAOTよりもはるかに高速な開発プロセスを提供することがわかっています。 コードを変更した後、通常の.NETコンパイラーでコードを再構築し、ブラウザーで更新されたアプリケーションを数秒で取得できます。 AOTのコンパイルには、数分かかる場合があります。



明白な考えは、解釈モードが開発の主なものであり、生産のためのAOTであるということです。



しかし、驚くべきことに、解釈モードは思ったよりもはるかに高速であるため、これはすべて完全に間違っている可能性があります。 そして、ネイティブモバイルアプリケーションに.NETを使用するXamarinの担当者から、AOTアセンブリとは異なり、通常の（非AOT）.NETアセンブリは非常に小さく、非常に圧縮可能であると聞きました。 違いを客観的に評価する機会が得られるまで、両方のオプションを検討します。

Blazor、SPAフレームワーク

ブラウザーで.NETを実行できることは良いスタートですが、十分ではありません。 生産的なアプリケーション開発者になるには、UIの作成/再利用、状態管理、ルーティング、単体テスト、アセンブリの最適化など、標準的な問題に対する一貫した一連の標準ソリューションが必要です。 .NET開発者が期待するように、これらはすべて.NETとC＃言語の強みを中心に設計され、既存の.NETエコシステムを最大限に活用し、最高のツールサポートを提供する必要があります。



Blazorは上記のすべてです。 React、Vue、Angularなどの今日の最高のSPAフレームワークと、Razor PagesなどのMicrosoft UIスタックに触発されています。 私たちの目標は、Web開発者に.NETで最適に機能するものを提供することです。

コンポーネント

最新のすべてのSPAフレームワークでは、アプリケーションはコンポーネントから構築されます。 通常、コンポーネントは、ページ、ダイアログ、タブのセット、またはフォームなどの何らかのUI要素です。 コンポーネントは、プロジェクト間でネスト、再利用、共有できます。



Blazorでは、コンポーネントは.NETクラスであり、直接（つまり、C＃クラスとして）、またはより一般的には、Razorマークアップページ（.cshtmlファイル）として記述できます。



2010年頃に登場したRazorは、マークアップとC＃コードを組み合わせるための構文です。 これは開発者の生産性のために特別に作成されたもので、 インテリセンスを完全にサポートすることで、式なしでマークアップとC＃を切り替えることができます。 次の例は、RazorファイルMyDialog.cshtmlで説明されている単純なダイアログコンポーネントを示しています。

<div class="my-styles"> <h2>@Title</h2> @RenderContent(Body) <button onclick=@OnOK>OK</button> </div> @functions { public string Title { get; set; } public Content Body { get; set; } public Action OnOK { get; set; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコンポーネントを使用すると、ツールキットは何を伝えるべきかを知っています。







ステートフルコンポーネント、ステートレスコンポーネント、高次コンポーネントなどのSPAフレームワークの一般的なパターンなど、多くのデザインパターンをこの単純な基盤上に構築できます。 コンポーネントを相互に投資し、手続き的に生成し、ライブラリ間で分割し、ブラウザを必要とせずに単体テストを実行し、一般に良い生活を送ることができます。

インフラ

新しいプロジェクトを作成するとき、Blazorはほとんどのアプリケーションに必要な基本サービスを提供します。

• パターン
• ルーティング
• 依存性注入
• 遅延読み込み（つまり、必要に応じてアプリケーションの一部を読み込む）
• 単体テスト

アーキテクチャの重要な側面はすべてオプションです。 何かを使用しない場合、公開時に最終ビルドから削除されます。



もう1つの重要なポイント-フレームワークの中核にあるのは、最下位レベルの一部のみです。 たとえば、ルーティングとテンプレートシステムは同じではありません。これらはユーザー空間に実装されます。つまり、このコードは、内部APIを使用せずにアプリケーション開発者が作成できます。 したがって、ルーティングまたはテンプレートシステムが気に入らない場合は、自分のものに置き換えることができます。 現在のプロトタイプテンプレートシステムは約30行のC＃コードであるため、必要に応じて簡単に把握して書き換えることができます。

展開

明らかに、Blazorのターゲットオーディエンスの大部分はASP.NET開発者です。 彼らのために、サーバーの事前レンダリングなどの追加機能を備えたBlazorでのUIの透過的なホスティングのためのミドルウェアをリリースします。



.NETをまったく使用しない開発者も同様に重要です。 Node.js、Rails、PHP、またはその他のサーバーテクノロジーを好む開発者、またはサーバーレスアプリケーションを作成する開発者にとってBlazorを実行可能にするために、サーバー上に.NETは絶対に必要ありません。 Blazorアプリケーションをビルドした結果は、静的ファイルのみを含むdistフォルダーです。 Githubページから、クラウドストレージから、Node.jsサーバーを介して、一般的にはあらゆるものを通じてそれらを配布できます。

共通コードとネット標準

.NET標準は、.NETランタイムが提供する機能または.NETアセンブリが必要とする機能のレベルを記述する方法です。 .NETランタイムがnetstandard2.0以前をサポートし、 netstandard2.0以降を対象としたアセンブリがある場合、このランタイムでこのアセンブリを実行できます。



WebAssemblyのMonoは、 netstandard2.0以上をサポートします （リリース日によって異なります）。 これは、バックエンドアプリケーションとブラウザアプリケーションの両方で.NETライブラリを使用できることを意味します。 たとえば、ビジネスロジックモデルクラスを含むプロジェクトがあり、サーバーとクライアントの両方で使用できます。 そして、もちろん、NuGetからパッケージをダウンロードできます。



ただし、すべての.NET APIがブラウザーで意味をなすわけではありません。 たとえば、任意のTCPソケットをリッスンすることはできないため、 System.Net.Sockets.TcpListenerは何も役に立ちません。 また、ブラウザアプリケーションでSystem.Data.SqlClientを使用しないでください。 そして、これは問題ではありません。第一に、ブラウザーは、人々がWebアプリケーションを作成するために本当に必要なAPIをまだサポートしているためです。第二に、.NET標準にはそのような場合の処理​​メカニズムがあります。 特定のプラットフォームに適用できないAPIを呼び出すと、基本クラスシステム（BCL）はPlatformNotSupported例外をスローします。 最初はこれが問題を引き起こす可能性がありますが、NuGetパッケージの作成者は、時間の経過とともに、ライブラリを変更してさまざまなプラットフォームをサポートするようになります。 .NETが世界で最も急速に成長しているアプリケーションプラットフォームに移行したい場合は、この段階に進んでください。

JavaScript / TypeScript互換

C＃/ F＃でブラウザアプリケーションを記述している場合でも、誰かのJavaScriptライブラリまたは独自のJavaScript / TypeScriptコードを接続して、新しいブラウザAPIを呼び出す必要がある場合があります。



WebAssembly標準はJavaScriptと対話するように設計されており（これは驚くべきことではありません）、これは.NETコードで簡単に使用できるため、非常に単純でなければなりません。



他の人のJavaScriptライブラリを操作するために、完全なインテリセンスを備えたC＃コードでTypeScript型定義を使用する可能性を調査しています。 これにより、約1000個の最も一般的なJSライブラリの統合が非常に簡単になります。



.NETから外部ライブラリまたはJS / TSコードを呼び出すための現在のアプローチは、名前付き関数をJS / TSファイルに登録することです。 例：

 //  JavaScript Blazor.registerFunction('doPrompt', message => { return prompt(message); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...そして、.NETから呼び出すためのラッパーを作成します。

 //  C# public static bool DoPrompt(string message) { return RegisteredFunction.Invoke<bool>("doPrompt", message); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

registerFunctionアプローチには、WebpackのようなJavaScriptビルダーでうまく機能するという素晴らしいボーナスがあります。



また、時間と神経を節約するために、Monoチームは.NETで標準のブラウザAPIを転送するライブラリの開発に取り組んでいます。

最適化

歴史的に、.NETは、アプリケーションのサイズがそれほど大きくないプラットフォームに焦点を合わせてきました。 ASP.NETアプリケーションの重量が1MBでも50MBでも、それほど違いはありません。 これは、デスクトップまたはモバイルアプリケーションにとっては中程度の問題です。 ただし、ブラウザの場合、ダウンロードサイズは非常に重要です。



防衛面では、WebAssembly上の.NETは一度だけダウンロードされる可能性が高いと言えます。 結局、標準のHTTPキャッシュ（またはサービスワーカーのような派手なもの）を使用して、ユーザーがランタイムコアを一度だけ読み込むようにすることができます。 また、CDNを使用すると、ユーザーは1つのダウンロードの結果を複数のアプリケーションで一度に使用することもできます。



これはすべて良いことですが、それだけでは十分ではないと思います。 ランタイムの重量が20MBの場合、1回限りのダウンロードであっても、それでも大きすぎます。 結局のところ、これはブラウザのプラグインではありません-標準に基づいて構築された標準のWebアプリケーションです。 最初の起動でさえ高速になります。



そのため、ダウンロードサイズの削減に多大な労力を費やしました。 最適化には次の3つのフェーズがあります。

1. Monoランタイムの減少

Monoランタイムには、多くのデスクトップ固有の機能が含まれています。 Blazorには、完全なディストリビューションよりも大幅に縮小されたMonoの簡易バージョンが含まれることを期待しています。 手動で最適化を試みたところ、基礎となるアプリケーションの動作を中断することなく、 .wasmランタイムファイルの約70％を削除できました。

2.公開時のILコードの削減

リンカー.NET IL （ Monoリンカーに基づく）は、静的分析を実行し、.NETライブラリのどの部分をアプリケーションから呼び出すことができるかを判断し、他のすべてを削除します。



これはJavaScriptのツリーシェーキングに似ていますが、唯一の違いはILリンカーがはるかに正確であり、個々のメソッドレベルで機能することです。 これにより、システムライブラリから未使用のコードをすべて削除できます。これにより、ほとんどの場合に大きな違いが生じ、多くの場合、アプリケーションのサイズがさらに70 +％削減されます。

3.圧縮

最後に、最も明白なのは、サーバーがHTTP圧縮をサポートすることです。 これは通常、ボリュームのさらに75％をカットします。



もちろん、.NET Webアプリケーションは、単純なReactアプリケーションほど小さくなりません。 私たちの目標は、平均的な接続の通常のユーザーがキャッシュからの後続のダウンロードは言うまでもなく、非常に小さくすることです。

では、なぜこれがすべて必要なのでしょうか？

好むと好まざるとにかかわらず、Web開発は今後数年間で大きく変わります。 WebAssemblyにより、Web開発者はこれまでよりもはるかに多くの言語とプラットフォームのリストから選択できます。 そしてこれは良いことです-私たちの世界はついに成長しています。 サーバーソフトウェアとネイティブアプリケーションの開発者は、問題を解決するのに最適な言語とパラダイムを常に選択でき、チームの文化に対応し、既存の知識によって強化されています。 HaskellまたはLispで金融アプリケーション用の機能を書くことを夢見ていますか？ 少し低レベルのCが必要ですか？ あなたはApple開発者で、Swiftの知識を使い続けたいですか？ これらはすべてWebに反映されます。



心配しないでください。 これは、これらすべての言語を知る必要があるという意味ではありません。 これは、私たち全員が普通のソフトウェア開発者になることを意味します。 現在のブラウザプログラミングの知識は関連性と価値がありますが、アイデアを表現したり、他の開発者コミュニティとの接点を増やしたりする新しい方法があります。



そして、私たちのイニシアチブは、.NETを何年も遅れずにこの動きの最前線に置くことです。

現状

試してみたい衝動を感じますか？ 遅くなりました-私たちはまだプロジェクトの非常に初期の段階にあります。 これまでのところ、ダウンロードの準備ができているものはなく、上記の多くは開発プロセスにあります。 ほとんどの人はリラックスして待つ必要があります。最初のプレアルファビルドは約1か月で表示されます。



現時点では、BlazorはASP.NETチームの実験であることに注意してください。 本格的なサポート対象製品にできるかどうかを理解するには、数か月かかります。 まだ何も約束していませんので、Blazorを中心にビジネスプランを立てないでください！



興味がある場合は、 リポジトリを見て、それを収集してテストを実行し、 チャットしてください 。 // TODOコメントを検索してプルリクエストを送信したり、クールな機能に関するアイデアを共有したりすることもできます。

---

翻訳者から

最後に、興味深いリンクをいくつか紹介します。

• Blazorの作業デモ （開発者ツールをチェックしてください ！）
• NDCオスロでの最初のBlazorプロトタイプのデモンストレーション
• Blazorの発表に専念するSteveとのASP.NET Community Standup