Microsoft-ui-xaml: ディスカッション：WinUIとElectronJSおよびクロスプラットフォーム（WinUIを拡張して、WinUIの代わりにElectronJSを使用する理由を排除します）

同じことが新しいXboxベータアプリにも当てはまります。 栄光の店としてオープンしたばかりの400MBを使用しています。 Microsoft Storeは、アクティブなときに117MBしか使用しません。

マイクロソフトがクロスプラットフォームのUIフレームワークを開発するまで、すべてのプラットフォームで単一のUIとコントロールの設計が可能になり、ElectronJSとその類似品が使用され続けます。

ElectronJS / Teamsの驚異的なスピードの例：
まず、比較として、Microsoft Outlookを開いて、受信トレイ（非常に多数のメッセージを含む受信トレイ）に最新のメッセージを表示するのにかかる時間を計測しました。 ほんの数秒しかかかりませんでした。実際には非常に速かったので、正確な測定値を取得するのに十分な速さでストップウォッチを停止できませんでした。
次に、Microsoft Teamsを開いて、同僚とのチャットで最新のメッセージを表示するのにかかる時間を計りました：27秒！ この時間は、チャットペインに存在するメッセージと画像の数に応じて多かれ少なかれ長くなる可能性があります。

（更新9- 2019年11月： _新しいバージョンのTeamsがリリースされ、最新のチャットメッセージの表示にかかる時間が改善されました。前述の27秒の例では、以前のバージョンのTeamsについて説明しています。Microsoftスタッフに感謝します。この改善に取り組んだメンバー。_）

先週、Teamsの[ヘルプ]アイコンをクリックしてから、[フィードバックを送信]をクリックしてメッセージを入力しました。 驚くほど遅かったです。キーボードのキーを押すたびに、各文字が表示されるまでに数秒かかりました。 （ただし、今日「フィードバックを与える」を再度テストしたところ、先週よりもはるかに遅れが少なかったため、この特定の問題を再現するのは難しいようです。）

チームがWinUIを使用して作成されている場合、これらの速度の問題やその他のさまざまな異常なバグは発生しません。 たとえば、WinUIアプリはWindows設定で構成された日付/時刻の書式を使用しますが、Teamsが英語に設定されている場合、Teamsは常に12時間の米国の日付/時刻の書式を使用し、Windowsの設定を無視します。これはWindowsの方法ではありません。アプリは動作することになっています。 それから私は今日チームの言語を変更することをテストしました、そしてそれは_「グリッチがありました、チームは回復しています」_と言いました。 そして、チャットペインのメッセージ内のいくつかの画像を読み込めませんでした。

同様に、チームがWinUIを使用して作成された場合、5つのチームプロセスは作成されません。

@mdtauk

マイクロソフトがクロスプラットフォームのUIフレームワークを開発するまで、すべてのプラットフォームで単一のUIとコントロールの設計が可能になり、ElectronJSとその類似品が使用され続けます。

私は一般的に同意しますが、たとえばMicrosoft OneNoteはWindows、Android、Macで利用できますが、ElectronJS（AFAIK）を使用せず、次のようなひどいパフォーマンスに悩まされることはないため、この話にはそれ以上のものがあるはずです。チーム。

@mdtauk

マイクロソフトがクロスプラットフォームのUIフレームワークを開発するまで、すべてのプラットフォームで単一のUIとコントロールの設計が可能になり、ElectronJSとその類似品が使用され続けます。

私は一般的に同意しますが、たとえばMicrosoft OneNoteはWindows、Android、Macで利用できますが、ElectronJS（AFAIK）を使用せず、次のようなひどいパフォーマンスに悩まされることはないため、この話にはそれ以上のものがあるはずです。チーム。

Microsoftには、プラットフォームごとにアプリを構築し、可能な限りコードを共有するためのリソースがありますが、共有UIは使用していません。

複数のプラットフォーム（Windows、iOS、Android、Web）を対象とするUnoプラットフォームを使用して、現在UWP API、後でWinUIを使用して高性能アプリパッケージを作成することに反対する意見を聞きたいと思います。 Microsoftのすべてを使用します-VS、C＃、Xaml、Xamarin、mono、.Net .. ..
一部の人がそれを回避する主な理由は、Microsoftから直接来たものではありませんか？

複数のプラットフォーム（Windows、iOS、Android、Web）を対象とするUnoプラットフォームを使用して、現在UWP API、後でWinUIを使用して高性能アプリパッケージを作成することに反対する意見を聞きたいと思います。 Microsoftのすべてを使用します-VS、C＃、Xaml、Xamarin、mono、.Net .. ..
一部の人がそれを回避する主な理由は、Microsoftから直接来たものではありませんか？

これは数年前にはもっと良い議論だったでしょうが、アプリやシステムの構築に投資しようとしている多くの企業は、開発しているプラ​​ットフォームがマイクロソフトのような膨大なリソースを持つ大企業のサポートと長寿を持っていることを知る必要があります。

その議論の問題は、過去10年間で、Microsoftがプラットフォームとユーザーベースを放棄し、WindowsがMicrosoft内でレガシーまたは優先度の低下に移行していることを示していることです。

したがって、接続されたサービスを実行したい場合、または積極的に開発されており、将来的に強力なサポートがあるように見えるプラットフォームに焦点を当てたい場合、新しい開発者がWebプラットフォームに移行したことを非難することはできません。

同時に、Adobeのようにレガシーアプリを使用している大企業がいくつかあります。そのため、それらを使用してプラットフォームを移動することはほぼ不可能です。 カスタムソフトウェアを使用する愛好家や企業もあ​​ります。

Microsoftは、.NETとWin32のサポートでうまくいっています。 そして、WinUIはWin32と.NETを許可するチャンスかもしれませんが、最新のUIを備えています。

Silverlight、WinRT、UWP-はすべて放棄されました。 （UWPは技術的にはそうではないことは知っていますが、WinUIはおそらく代替品と見なされます）。

Zune、Windows Media Centre、Windows Phone 7、Windows Phone 8、Windows8-熱狂者と彼らが伝道しようとした人々を失望させます。

MicrosoftがWinUIをどのように位置付け、Windowsの将来を確実に保護するかは、_絶対に不可欠_です。

WinUI for Desktopは有望に見えますが、少なくともそのXAMLのサブセットがWeb上で実行できる必要があると思います。 新しいSilverlightと同様ですが、.NET5およびWebAssemblyで実行されるWeb上のWinUI。

Silverlight、WinRT、UWP-はすべて放棄されました。 （UWPは技術的にはそうではないことは知っていますが、WinUIはおそらく代替品と見なされます）。

Zune、Windows Media Centre、Windows Phone 7、Windows Phone 8、Windows8-熱狂者と彼らが伝道しようとした人々を失望させます。

同意する。
私のSilverlightの一部が信じられません（web0アプリはまだ一部のユーザーによって毎日使用されています。
マイクロソフトをフォローすることはますます困難になっています。 Uno Platformの背後にいる人々は、彼らのパンとバターのアプリビジネスをサポートするためにそれを開発して維持しています。 多くの貢献者がいるオープンソースです。 私は、マイクロソフトの迷路や混乱をうまくナビゲートする方法をよく知っている一流のドライバーと一緒に非常に良いバスを便乗していると感じています。

私の2セント：UWPとWinUIの唯一の希望は、何も残らなくなる前に、すぐにクロスプラットフォームでWebに組み込まれるようにすることです。
Unoプラットフォームは、すばやく簡単で、おそらくこれを実現するための最も安全な方法でもあります。
@zipswichが述べたように、UnoはずっとMicrosoftでした。 コーディングガイドライン、ツール、言語の選択、およびレンダリングで、Fluent-designに対応しています。
たとえば、Xamarinよりも100倍Microsoftに偏っています。 ReactやElectronは言うまでもなく、すべての醜いHTML＆CSSまたはJSテクノロジーMSは、お世辞や不正行為に夢中になっています。

また、C＃は、.NETStandardにUIフレームワークがないサーバー言語にすぎません。
この状態が長く続くと、Dartまたは他のテクノロジーがサーバー言語になり、完全に引き継がれます。
クライアントとサーバーの両方で単一言語のコードベースを使用できるようにするための犠牲として、人々は厄介な言語（JS）を喜んで使用していることがわかります。 C＃は、XAMLと同じようにフェードする可能性があります。または、緊急救助が行われた場合、XAMLと一緒に勝つことができます。

宇野が未来になるとは思いません。 これはXamarin.Formsと非常によく似ており、Xamlフレームワークを取り除いたものであり、多くの機能が不足しており、いくつかのハックと回避策を使用して、すべてのプラットフォームに統合できるように複雑な追加機能が追加されています。 確かにそれを使用することはできますが、使用できるコントロールと使用できるAPIには非常に制限があります。 主な問題は、各プラットフォームのネイティブコントロールでXamlUIを実現しようとすることです。 これは常に問題があり、すべてのプラットフォームで機能する機能のごく一部しか残されていません。

将来的には、実際のWinUIを使用し、プラットフォームのネイティブ3Dエンジンに実装された各プラットフォームに実際のレンダラーを提供する予定です。 これにより、完全な機能セット、WinUIのすべての優れた機能、ネイティブパフォーマンス、クロスプラットフォームでの実行が可能になります。

実際、Microsoftはすでにこのようなものを非常にうまく実行しています。UWPUIは主にSilverlightコードに基づいており、Microsoftはすべての主要なプラットフォーム用のSilverlightプラグインを持っていました。つまり、これらすべてのプラットフォーム用の基本的なレンダリングエンジンがすでにあります。 今ではUWPにSilverlightと比較して多くの追加があるため、これらは最新ではありません。 しかし、それは上に構築できる基盤です。

マイクロソフトには、これを実現するためのリソースが確かにあります。 これは人々が望んでいることであり、これは彼らがすべきことです。

C＃はXAMLのようにフェードする可能性があります>

C＃に関するこの声明に絶対に同意しないでください。 C＃はXAMLよりもはるかに大きいです。 あなたがBlazorをフォローしているなら、あなたはこれが真実ではないことを知っているでしょう。 Blazorは、主にUWP / Xamarinを使用している私にとって、そして一般的にビジネスユーザーを対象としたC＃開発者にとってはゲームチェンジャーだと思います。

WinUI x-platformがあればいいのですが、Web / x-platformへの最も簡単な道はBlazorだと思います。特に、Blazorが部分クラスもサポートしているので、既存のコードのほとんどをそのまま使用して、ブレイザー。 いくつかの問題は、Sqlite、Shared Projects、およびReactiveUIの代替となる可能性があります。 既存のMVVMアーキテクチャを使用して、Blazorにかなり簡単に移植できるはずです。

私にとって最も重要な障害は、UWPでの.netコア3のサポートの欠如です。 MSにとって、開発者エクスペリエンスでBlazor + UWPを調整することが重要だと思います。 UWPチームがそれに取り組んでいることを私は知っています。

また、UWP / WInUIアプリでBlazorページを表示したいと思います。 ハイブリッドUIモデルは、UWPアプリでうまく機能するため、利用可能な最高のUIアセットを使用できます。 （html5とXAML）また、意味のあるUWPとBlazorの間でUIの取り組みを複製しません。

現在、ElectronはJavascript、HTML + CSSを使用しています。 ElectronをBlazorで使用できない理由はありません=> C＃、HTML + CSS + gRPC

ただし、使用できるコントロールと使用できるAPIには非常に制限があります。

@lucasf宇野を食べたことがありますか？ 適切なUWPAPIがない場合に備えて、UnoではXamarinを介したネイティブAPIの使用が許可されていることをご存知ですか。 ハードウェアコーデックを使用し、低レイテンシを必要とするリアルタイムビデオストリーミングアプリでも、Unoベースのアプリで使用するネイティブAPIはごくわずかです。

ただし、使用できるコントロールと使用できるAPIには非常に制限があります。

@lukasf宇野を食べたことがありますか？ 適切なUWPAPIがない場合に備えて、UnoではXamarinを介したネイティブAPIの使用が許可されていることをご存知ですか。 ハードウェアコーデックを使用し、低レイテンシを必要とするリアルタイムビデオストリーミングアプリでも、Unoベースのアプリで使用するネイティブAPIはごくわずかです。

@zipswich Unoの標準のXamlコントロールのセットはかなり小さく、完全なUWPまたはWinUI3が提供するものに近いものではありません。 優れた/複雑なUIを実現するには、通常、追加のプラットフォーム固有のネイティブUIコントロールとコードを埋め込む必要があります。 したがって、最終的には、複数のUIプラットフォーム（Uno Xaml、ネイティブAndroid、ネイティブiOS、ネイティブWindowsまたはWebAssemblyなど）が混在していることに気付くでしょう。 これは、私が優れた開発者エクスペリエンスと呼んでいるものではありません。

WinUI用のネイティブxプラットフォームレンダラーがある場合、プラットフォーム固有のものが含まれていない、完全なWinUI機能セットを備えた単一のUIしかありませんでした。 また、WinUIは、期待どおりに、完全なパフォーマンスでGPU上に直接レンダリングします。 AndroidコントロールやiOSコントロールを追加する必要はありません。 これは、xプラットフォーム開発がどのように見えるべきかです。

MicrosoftTeamsのMicrosoftプログラムマネージャーにElectronJSからWinUI / UWPに切り替えるよう説得するために、WinUIに欠けているもの（およびそれをどのように改善できるか）は何ですか？

素晴らしい質問です。 これを行うと、膨大な数のユーザーが非常に満足するでしょう。

大きな要因は、フレームワークを比較するパフォーマンス測定値の欠如です。 UWPとElectronで実行される同等のアプリを比較し、速度とメモリ使用量を比較するページで十分です。 これは他のフレームワークにも拡張できます。 このコストからユーザーへの影響、コード統合のメリット、およびメリットは、財務コストと比較検討することができます。

この研究の現在の欠如は、非効率的なフレームワークが普及するのを助けています。

正直に言うと、MSが「WinUI」（ Windows UI）をクロスプラットフォームにする計画があるとは思えません。 その上、現在オープンソースであるという事実は、通常、マイクロソフトがそれを重要/戦略的技術と見なしていないことを意味します。 彼らは、コミュニティのリソースを活用して、内部の人員を減らしながら、それを維持しようとしています。 誤解しないでください。WinUIがオープンソースになり、Microsoft開発者がWinUI 3.0に移行するためにプラットフォームに取り組んでいることを常に感謝しています。これは、ネイティブとネイティブの両方のWindowsプレゼンテーションプラットフォームを統合するための素晴らしいステップです。管理対象アプリ。 マイクロソフトがWindowsを未来と見なしているとは思わないし、クロスプラットフォームにすることに興味を持っているとは思わない（もちろん、それが本当なら彼らの間違いだ）。

開発者に標準以下の技術の使用を強制しない真のクロスプラットフォーム開発フレームワークは、世界が必要としているものです。 ここのほとんどの人は同意しているようです。 それが主に意味するのは：

• プラットフォームのネイティブデザインと同じようにレンダリングできるコントロールライブラリとマークアップ（XAML）（iOS、Androidなどのコントロールスタイルのみが必要です）
• WPFのようにマネージコードで記述する必要があります。 C ++のベースレイヤーのみ、コントロールはC＃以外のものであってはなりません。
• レンダリングは、Metal / Vulcan / DirectXを使用して実行する必要があります（Unoのような既存のコントロールの上ではありません）
• 入力はXプラットフォームの方法で再実装する必要があります
• アクセシビリティは大きな問題ですが、残念ながらUnoのアプローチを使用するとはるかに簡単に解決できます

それが私たちの望みなら、WinUIはそれを実行しないと思います。 それがネイティブに実装されているという事実と方法（間にあるCOM / .netレイヤー）だけでは、このクロスプラットフォームを採用するのは非常に難しいでしょう。 代わりに、UNOとAvaloniaがあります。 アバロニアはトンネルの終わりにある本当の光ですが、彼らには資源がありません。 現在、多かれ少なかれ可能であるのは、Avaloniaレンダリング技術をWPF（管理対象部分）のバックエンドとして使用することです。 これにより、真のクロスプラットフォームUIフレームワークが短時間で提供されます。 問題は、WPFがデスクトップ用に設計されており、WPF / Silverlightを電話サイズのデバイスや最新のタッチ/インタラクティブ入力に適したものにするために、多くの作業がUWPに費やされたことです。

正直なところ、この時点で、私たち全員がAvaloniaにお金とコードの寄付を投げただけでよいと思います。 私たちはMicrosoftにクロスプラットフォームUIを長い間求めてきましたが、それらはWebテクノロジ自体に切り替えることに満足しています。 Microsoftは現在、XBoxなどのUWPアプリをElectronやWebテクノロジーに変換しています。 アプリはMicrosoftStoreでも販売されていません。

皮肉なことに、Microsoftは、優れたアプリを構築するために必要なツールを開発者に提供したため、過去に非常に成功していました。 これはユーザーを引き込み、非常に建設的なフィードバックループがあります。 ある時点でそれは忘れられました。 現在、開発者は標準以下のテクノロジーに頼っています（HTML / CSSは元々アプリ用に設計されていませんでした...ドキュメントマークアップ用でした！）しかし、アプリを1回開発して、ElectronとWebで実行するだけで節約できます現在の機能、システム統合、およびパフォーマンスの犠牲をはるかに上回っています。

皮肉なことに、Microsoftは、優れたアプリを構築するために必要なツールを開発者に提供したため、過去に非常に成功していました。 これはユーザーを引き込み、非常に建設的なフィードバックループがあります。 ある時点でそれは忘れられました。 現在、開発者は標準以下のテクノロジーに頼っています（HTML / CSSは元々アプリ用に設計されたことはありません...ドキュメントのマークアップ用でした！）

よく言った。 BASICに加えて、私はQuickCからMicrosoftIDEを使い始め、次にVC ++ ... Microsoftは、着実で一貫性のある、ある程度予測可能な方法で進化、革新を行っていました。 私たちはそれをフォローしようとしましたが、それは私たちをフォローすることになっている人々の傾向に従っているようです。 私は以前、一流の研究大学のインターンに、作業を依頼されたエンタープライズアプリにMicrosoftテクノロジを使用するように指示していました。 抵抗はゼロでした、そして彼らは喜んでマイクロソフトのものをすぐに拾いました。 マイクロソフトが最近の子供たちの様子を見ていて、それをフォローしているのではないかと思っていました。

アプリはMicrosoftStoreでも販売されていません。

悲しいことに本当です。 ただし、開発テクノロジーではなく、（ユーザーとパブリッシャーにとって）最悪のアプリストアのせいです。 アプリのUWPバージョンとAndroidバージョンの1日あたりのダウンロード率：1： 20 。 それらは開発するのにほぼ同じ量の努力を要します。 これは誇張ではありません。 昨日のダウンロードデータを見てみました。 Beanカウンターで働いていたとしたら、収益がほとんどないUWPバージョンに多大な労力を費やしたため、すぐに解雇されます。

悲しいことに本当です。 ただし、開発テクノロジーではなく、（ユーザーとパブリッシャーにとって）最悪のアプリストアのせいです。

@zipswich 、はい、良い点があります。 私は、マイクロソフトが内部で販売数を確認し、エコシステムが（正しく）死にかけていると想定していました。 これにより、私たちが話している基礎となる開発テクノロジーのタイプが廃止されたため、投資を開始して他の方向に進んでいることを彼らに納得させます。 実際、ほとんどのMicrosoftアプリ開発者は、過去20年間のUI技術の進歩を忘れて書かれていないクロスプラットフォームフレームワークの明確な必要性を理解できます（WPFは、登場したときは本当にゲームチェンジャーでした）。

クロスプラットフォームが必要なだけでなく、強力でスケーラブルな言語とマークアップを使用して実行され、最初から意味のあるスコープ（アプリ、優れたコントロールカタログを対象）を持つものが必要です。 しかし、それについてはもうマイクロソフトに頼ることはできないと思います。 彼らは、他の分野で時間/リソースを費やすと、より高い利益が見られることを明らかにしました。

収益がほとんどないUWPバージョンに多大な労力を費やしたことで、すぐに解雇されます。

聞いたことがありますが、私もMicrosoftStoreにある自分のアプリに基づいてその発言をしました。

@roblooそこにはいくつかの良い点がありますが、私は実際にはあなたをフォローしていません。 ここにいくつかの考えがあります：

• Microsoftは、.NET Core、ASP.Net Core、EFCoreなどの他のオープンソースフレームワークにも多大な労力とリソースを費やしてきました。 明らかに、彼らはオープンソースのクロスプラットフォーム開発（少なくともサーバーアプリケーションの場合）に将来を見込んでいます。 また、リソースをAOTコンパイルに投入するため、.NET CoreはiOSおよびAndroidにもコンパイルできます（JITが許可されていない場合）。 ですから、WinUIがオープンソースになっているという理由だけで、WinUIが死んでいると言っているのをフォローすることはできません。 つまり、それは本当かもしれませんが、あなたの唯一の議論が「彼らがそれをオープンソースにしているから」であるならば、これはあまり説得力がありません。

• QtはクロスプラットフォームのUIフレームワークであり、ネイティブC / C ++で実装されています。 ハードウェアアクセラレーションによるOpenGL / Direct3Dレンダラーを備えているため、外観は同じで、すべてのプラットフォームで優れたパフォーマンスを発揮します。 プラットフォーム固有のコードは必要ありません。すべてのコントロールは、iOSやAndroidを含むすべてのプラットフォームで実行されます。 では、Qtがそれを実行できるのであれば、iOSとAndroidでWinUIを実行することが技術的に不可能なのはなぜですか？ WinUIは、Qtと同様に、ネイティブC ++であるWinRTに実装されています。 内部的には、少数のCOMテクノロジ（IUnknownインターフェイスとCOMファクトリシステム）のみを使用します。 それを抽象化したり、他のプラットフォームに必要なものを再実装したりするのはそれほど難しいことではありません。 WinUIコードでCOMコードが直接使用されているとは思いません。

• Silverlightは同じテクノロジーを使用し、xプラットフォームで利用可能でした。

• Windowsは依然としてナンバーワンのデスクトップOSであり、家庭だけでなく（特に）企業でも頻繁に使用されています。 Officeライセンスと組み合わせると、Microsoftに多くの堅実な収益をもたらします。 すべての主要なUI開発プラットフォームを死なせた場合、この収益は失われます。 WinFormsとWPFはすでに機能していないため、WindowsでアクティブなUIプラットフォームはWinUIだけです。 彼らが完全なWindows / Office / Enterpriseシステムを廃止したいとは思わないので、WinUIを廃止したいとは思わない。

• WinUIをオープンソースにすることは、Microsoftだけでなく、開発者にとっても素晴らしいことです。

• UWPが死ぬ可能性があります。 多くの開発者は、すべての愚かな制限のためにそれを避けています。 Windowsストアはリモートで成功していません。 Windows Phoneは死んでおり、それがUWP全体を開始する主な理由でした。

• WinUI 3.0を使用してデスクトップアプリにWinUIを導入し、それをオープンソースにすることは、実際には、WinUIを強制終了するのではなく、保存するためのステップになる可能性があります。

私は、マイクロソフトが内部で販売数を確認し、エコシステムが（正しく）死にかけていると想定していました。 これにより、私たちが話している基礎となる開発テクノロジーのタイプが廃止されたため、投資を開始して他の方向に進んでいることを彼らに納得させます。

@roblooそうである必要はありません。 最高のモバイルプラットフォームであるWindowsPhoneを殺したのは、最悪のアプリストアだとずっと言ってきました。

彼らは1つの石で2羽の鳥を殺すことができます：有能な第三者に店をアウトソーシングし、.Netネイティブの悪夢を終わらせます。 それは彼らのコストを削減し、（私は信じています）2倍、4倍... Windowsアプリはすぐにダウンロードされます。 UWPアプリの問題の90％以上は、.Netネイティブの悪夢にのみ関連しています。

@lukasfあなたは私が言っていたことの多くを誤解したと思います。

WinUIがオープンソースになっているという理由だけで、WinUIが死んでいると言っているのをフォローすることはできません。

WinUIが死んでいるとは決して言えません。 私は、マイクロソフトがおそらくそれをもはや重要で戦略的な長期的な製品とは見なしていないと言った。 彼らは他の分野（サービスとクラウド）でより高い利益を見ているので、株主にとってより高い利益がある場所で彼らの時間を過ごすことを確実にしています。 つまり、WinUIを大幅に成長させてクロスプラットフォームにし、「死んだ」のではなく、生き続けるだけだと思います。 （私はUWP / WinUIの誰かではありません）死んだ時流です）。 また、私が述べたWinUI 3.0で、Microsoftが素晴らしいことをしていることを強く感じています。 これにより、win32ネイティブおよびマネージドのすべてのWindowsを1つのUIフレームワークに統合できます。

では、iOSとAndroidでWinUIを実行することが技術的に不可能なのはなぜですか

技術的には何でも可能です。 Windows専用に設計・実装されているので非常に難しいと言っていました。 また、クロスプラットフォームを採用するのは非常に難しいと思うものとして、マネージコードとの通信方法の例を示しました。 私がここで間違っていたら、それは私たち全員にとって良いことです。

Silverlightは同じテクノロジーを使用し、xプラットフォームで利用可能でした。

そして、Silverlightは、技術的に不可能だったためではなく、もはや私の最も重要なポイントである優れたビジネスケースではなくなったために死んでいます。 デスクトップとモバイルの開発を引き継いでいるのと同じHTML / CSS / JSテクノロジーで死んだことにも注意してください。

すべての主要なUI開発プラットフォームを死なせた場合、この収益は失われます。

これはおそらくいくつかの異なる方法で議論される可能性がありますが、おそらく非常に迅速にトピックの範囲から完全に外れます（私はすでに行っていることを知っています）。 結論として、もちろん、MicrosoftはすべてのWindowsUIプラットフォームを死なせるわけではありません。 あなたはまだWindows用のアプリを書かなければなりません...私は他のことを言ったことはありません。

WinUIをオープンソースにすることは、Microsoftだけでなく、開発者にとっても素晴らしいことです。

「WinUIがオープンソースになったことをうれしく思います。Microsoftの開発者がWinUI3.0に移行するためにプラットフォームに取り組んでいることに感謝しています」という意図は、オープンソースが多くの人にとって素晴らしいと思うという私の感情を伝えることでした。私が触れなかった理由の。 例として、UnoConfで述べたように、現在ソースにアクセスできるUnoプラットフォームでさえ素晴らしいです。

UWPが死ぬ可能性があります。

待って、どちら側にいるの？ はは。 しかし、真剣に私はWinUI / UWPは本質的に同じものだと考えており、UWPはWinUIにわずかに進化し、開発者にとって大きな問題はありません。

WinUI 3.0を使用してデスクトップアプリにWinUIを導入し、それをオープンソースにすることは、実際には、WinUIを強制終了するのではなく、保存するためのステップになる可能性があります。

私はあなたに同意し、他のことを言うつもりはありませんでした。 しかし、私はいくつかのより大きな全体像の傾向を見ていて、それをクロスプラットフォームにすることについても話していました。

@zipswich

彼らは1つの石で2羽の鳥を殺すことができます：有能な第三者に店をアウトソーシングし、.Netネイティブの悪夢を終わらせます。 それは彼らのコストを削減し、（私は信じています）2倍、4倍になります。

良いニュースは、Microsoftがすでに.netネイティブを殺すことを決定したことです。 技術的には、.netの仕様に従わなかった多くのばかげた制限がありましたが、これはあなたが精通しているように思えます。 これは、Windows Phoneの起動とパフォーマンスの問題を修正するために迅速/汚い方法で行われたものであり、Windows Phoneが死んでから、戻って修正することは決してありませんでした。

現在、Microsoftは、MonoテクノロジとLLVMを使用して完全で高性能なAOTコンパイルを開発しています。 これは来年までに発表されるはずであり、WebAssemblyを使用するクライアント側のBlazorにも役立ちます。 Miquel de Icazaは、今年初めにUnoConfでそれについて触れた良いプレゼンテーションを行いました： https ：//www.youtube.com/watch？v = tYk2us6W6Gg（彼は最初のプレゼンターです）。

@roblooさて、私はいくつかの点であなたを間違えたかもしれません。

では、iOSとAndroidでWinUIを実行することが技術的に不可能なのはなぜですか

技術的には何でも可能です。 Windows専用に設計・実装されているので非常に難しいと言っていました。 また、クロスプラットフォームを採用するのは非常に難しいと思うものとして、マネージコードとの通信方法の例を示しました。 私がここで間違っていたら、それは私たち全員にとって良いことです。

Silverlightは同じテクノロジーを使用し、xプラットフォームで利用可能でした。

そして、Silverlightは、技術的に不可能だったためではなく、もはや私の最も重要なポイントである優れたビジネスケースではなくなったために死んでいます。 デスクトップとモバイルの開発を引き継いでいるのと同じHTML / CSS / JSテクノロジーで死んだことにも注意してください。

ここでの私のポイントは、Silverlightはすでにクロスプラットフォームで実行されていたということです。 マネージコードで使用できます。 Windows8のUWPXaml UIレイヤーは基本的にSilverlightであり、新しい名前空間といくつかのメタデータが追加されています。 今では進化していますが、最初は明らかに新しい名前空間を持つSilverlightXamlでした。 そのため、当時Silverlightクロスプラットフォームを実行できれば、WinUIクロスプラットフォームも実行できます。 そして、これが「非常に難しい」とは思わないが、マイクロソフトのような大企業にとってはかなり簡単だと思う。 彼らはすでにSilverlightXaml用のクロスプラットフォームレンダリングレイヤーを持っていました。 最新のWinUIを実行できるように、更新するのはそれほど難しくありません。

UWPが死ぬ可能性があります。

待って、どちら側にいるの？ はは。 しかし、真剣に私はWinUI / UWPは本質的に同じものだと考えており、UWPはWinUIにわずかに進化し、開発者にとって大きな問題はありません。

WinUIは単なるXamlUIレイヤーですが、UWPは完全なアプリフレームワークとシステムAPIレイヤーであり、Windowsストアに関連付けられており、従来のデスクトップアプリと比較して多くの制限があります。 したがって、これらは2つの非常に異なるものです。 MicrosoftがUWPとWindowsストアに未来を見ているかどうかは本当にわかりません。 厳しいUWPの制限を修正せず、Windowsストアの問題に実際に取り組んでいないからといって、私はあまり楽観的ではありません。 ただし、UWPから使用するかデスクトップアプリから使用するかに関係なく、何らかのUIフレームワークが必要です。これはWinUIになります。 そして、彼らが本当にそれを成功させたいのなら、彼らはそれをクロスプラットフォームにしなければなりません。 そうしないと、他のフレームワークに移動し、ある時点でWindowsプラットフォームを完全に離れてしまう可能性があります。 WinUIをクロスプラットフォームにすることは、開発者がWindowsに固執するための手段になります。

ここでの私のポイントは、Silverlightはすでにクロスプラットフォームで実行されていたということです。 マネージコードで使用できます。 Windows8のUWPXaml UIレイヤーは基本的にSilverlightであり、新しい名前空間といくつかのメタデータが追加されています。 今では進化していますが、最初は明らかに新しい名前空間を持つSilverlightXamlでした。 そのため、当時Silverlightクロスプラットフォームを実行できれば、WinUIクロスプラットフォームも実行できます。 そして、これが「非常に難しい」とは思わないが、マイクロソフトのような大企業にとってはかなり簡単だと思う。 彼らはすでにSilverlightXaml用のクロスプラットフォームレンダリングレイヤーを持っていました。 最新のWinUIを実行できるように、更新するのはそれほど難しくありません。

当時、UWP / Win8にSilverlightベースが使用されていた歴史を知りませんでした。その場合、定義可能であれば、これがどれほど実現可能かについてより楽観的になります。 訂正ありがとうございます！

WinUIは単なるXamlUIレイヤーですが、UWPは完全なアプリフレームワークとシステムAPIレイヤーであり、Windowsストアに関連付けられており、従来のデスクトップアプリと比較して多くの制限があります。 したがって、これらは2つの非常に異なるものです。

はい、あなたは正しいです、そして私は私の言葉遣いをもっと慎重に選ぶべきでした。 確かに、アプリモデルとパッケージングのUWPは今のところ存在し続けます。 ただし、UIレイヤーは、私が通信しようとしていたWinUIに切り替わります。 .netネイティブが置き換えられることで、今後数年間でさらに多くの変更があると思いますが、UWPで導入されたパッケージング/アプリモデル/ APIはまだ何らかの形で存在します。 しかし、マイクロソフトがここで未来を見ないかもしれないことに私は間違いなく同意します。 ありがたいことに、XAMLとC＃がまだ存在する限り、新しいアプリケーションモデルへの移行、またはパッケージ化/配布は通常比較的迅速です。 アバロニアだけが終わったら...

そして、彼らが本当にそれを成功させたいのなら、彼らはそれをクロスプラットフォームにしなければなりません。 そうしないと、他のフレームワークに移動し、ある時点でWindowsプラットフォームを完全に離れてしまう可能性があります。 WinUIをクロスプラットフォームにすることは、開発者がWindowsに固執するための手段になります。

私もあなたに100％同意し、同じいくつかの場所を述べました。 しかし、いくつかの理由でそれは起こらないだろうという結論に達しました。

私はコメント投稿者が言っていることに十分に反対することはできません：

WinUI 3.0はクロスプラットフォームである必要があります！

1）理論上のクロスプラットフォームプロジェクトが安定している次のN年ではなく、今すぐUIフレームワークが必要です。
2）OSにできるだけ近いUIフレームワークが必要です。 クロスプラットフォームでは、常にトレードオフがあります。 機能の最小公分母、またはカスタムレンダリングによる一貫性のないコントロールレンダリング。

私の考えでは、解決策は、WinUI 3.0（Fluentを維持し、レンダリングやヒットテストなどの作業がほとんどない場合）の上に構築するか、WinUIコンポジションをゼロから構築する別のフレームワークを用意することです。最高のパフォーマンスが必要で、すべてのレンダリングとヒットテストを自分で行うことを気にしない場合（一貫性がないという潜在的なコストがかかります）。

私は数日前にそれらの行を見たのを覚えています：
「オペレーティングシステムは、もはや私たちにとって最も重要なレイヤーではありません。私たちにとって最も重要なのは、アプリのモデルとエクスペリエンスです。」
したがって、WinUIが最高のGUIエクスペリエンスであることは明らかであり、WPF、UWP、およびWindows10の最高のエクスペリエンスと同様になると思います。

しかし、Webとその古いjavaScript + HTMLがどこでも使用されていることは明らかであり、それらのWebフレームワークとスタックは、優れているためではなく、電話のWebブラウザーやデスクトップのWebブラウザーですぐに利用できるために大量に使用されています。 メモ帳でHTMLファイルを作成し、alert（ 'Hello World'）;を使用してScriptタグを配置できます。 そして、あなたはアプリを持っています。

したがって、WebAssemblyを使用して.NET + XAMLに置き換えることは可能であり、必要でさえあることがわかります。 今日のjavaScriptと同じように、.NETがどこにでもある必要があります。

Silverlightは希望の光でした...そして今WebAssemblyを使用すると、Silverlightに戻ることが可能であることがわかります。

私はこれに満足します：
WinUIは完全なOSベースのGUIであり、少なくともそのXAMLのサブセットをWebBrowserで実行できます。

したがって、UNOチームは非常に重要であると考えており、近い将来Microsoftに参加して、WinUIであるこの素晴らしい取り組みに力を合わせることを望んでいます。

@MarkIngramUK Yesssss

WinUIを、ネイティブWindows開発を検討しているすべての人にとって最良のUI選択にします。 終了：

• 入力検証とネイティブデータグリッドコントロール
• 他の〜170の機能提案はここにあります
• 他の〜300のオープンチケット
• .NET Native> .NET Coreの移行（.NET Core 3 + 5、.NET Standard 2.1以降、およびC＃8の場合...）
• 新しいAOTコンパイラ
• より一貫性のある流暢な設計ガイドラインをフラッシュして公開する
• スタイル/テーマシステムを洗練する
• 気を散らす構図機能（傾斜、アクリルの多用、表示）を強調せず、奥行きと影のシステムとアニメーション（明瞭さをもたらし、ユーザーをガイドする）に重点を置きます。

これらは、WinUIを将来Electronと比較して検討している人々にとってより魅力的なものにするものです。

ケーキのアイシングは次のようになります。

• CSS <-> XAMLスタイリングの同期を維持するのに役立つツール
• 他のプラットフォームで.NETコードを最大限に再利用するために、アプリロジックをビューから分離するためのガイドライン
• HTML> XAMLコントロールの1回限りの大まかな翻訳を生成して、開発者がネイティブのWinUIアプリで開始するようにするためのツール（ほとんどの開発者がXAMLアプリで開始し、HTMLに向かうことを望んでいると想定するのではなく）

2. We need a UI framework that is as close to the OS as possible. With cross-platform, there is always a trade off. Either lowest common denominator for functionality, or inconsistent control rendering due to custom rendering.

@MarkIngramUK Silverlightはクロスプラットフォームであり、フル機能であり、すべてのプラットフォームでまったく同じようにレンダリングされました。 Qtはクロスプラットフォームであり、フル機能を備えており、すべてのプラットフォームでまったく同じようにレンダリングされます。 コントロールを別のプラットフォームのネイティブコントロールに内部的に変換してコントロールを実現しようとすると、一貫性のないレンダリングと最小公分母のコントロールしか得られません（これは、XamarinとUnoが行おうとしていることです）。 コントロールレベルではなく最下位レベル（GPUレンダリングレイヤー）で抽象化を行うと、完全なコントロールセットを使用してすべてのプラットフォームで100％同じ出力を得ることができます。 コントロールセットはすでに存在し、WinUI 3.0であり、今でも素晴らしいものです。 欠落しているのは、他のプラットフォームのレンダリングレイヤーの実装だけです（古いSilverlightソースから部分的に取得できます）。

クロスプラットフォームのアプリ開発をしたいです。 しかし、XamarinもUnoも私には魅力的ではなく、JS / HTMLとそれに基づくすべてのものが本当に好きではありません。 残念ながら、実際にWindows Storeでお金を稼ぐつもりなら、WindowsStore専用に開発するのは悪い選択です。 少なくとも私はそれに関してかなり悪い経験をしました、そしてそれからマイクロソフトがWindows Phoneエコシステムを殺した後、私は多かれ少なかれそれを終わらせました（いくつかの小さな「ただの楽しみ」プロジェクトにもかかわらず）。 WinUIがクロスプラットフォームに移行する場合は、すぐに新しいアプリの作業を再開します。

現在のすべてのクロスプラットフォームフレームワークには、多かれ少なかれ厳しい制限や不十分な開発経験があります。 MicrosoftがWinUIをクロスプラットフォームにすることができれば、それは本当に画期的なテクノロジーになる可能性があります。 Xamarinは、そのすべてのエッジとコーナー、および制限にもかかわらず、すでにかなり成功しています。 WinUIが、完全な機能セットと一流のVisual Studio開発エクスペリエンスを備えたすべてのプラットフォームで実行されるとしたら、どれほど成功するか想像してみてください。

@lukasf 、これが私のポイントです：

Silverlightはクロスプラットフォームであり、フル機能であり、すべてのプラットフォームでまったく同じようにレンダリングされました。

すべてのプラットフォームで同じレンダリングをしたくありません。 各アプリケーションがターゲットプラットフォーム上の他のアプリケーションと一致しているように見せたいです。 そのため、ネイティブコントロールはラッピングが必要ですが、それが最小公分母につながります。

@MarkIngramUK私はそれを次のように見ています：シンプルなアプリはプラットフォームのストックUIコントロールに固執します。 優れたアプリには独自のルックアンドフィールがあります。 ストックプラットフォームのコントロールは必要ありません。 Spotify、Netflix、または複数のプラットフォームで利用できるその他の優れた成功したアプリをご覧ください。 彼らのコントロールを見ただけでは、彼らが使用しているプラ​​ットフォームを知ることはできません。

クロスプラットフォームアプリは、すべてのプラットフォームでまったく同じように見え、同じように感じられるようにしたいと思います。

@MarkIngramUK理論を超えた現実に触れてくれてうれしいです。 これが私にとっての現実です。昨日、複数のプラットフォームをターゲットにする必要があったSL / WP> WinRT> UWPから進化したアプリがたくさんあります。 私はPhonegap / Cordovaを調べ、Xamarinの探索に多くの時間を費やし、最終的にはあきらめました。 使い始めてすぐに、いろいろな理由で宇野に恋をしました。 現時点では、C＃とXamlに適した、現在使用できる他の有望な実用的なXプラットフォームテクノロジを知りません。 WinUIが1、2、または3年後にXプラットフォームAPIに進化すると、一流のUnoの人々がUnoをUWPからWinUIに移行し、それに応じて、すべてのUnoベースのアプリを迅速に移行できるようになります。 今は何も心配する必要はありません。
決して、ここで興味をそそる理論的な議論に反対しているわけではありません。 あらゆる種類のアイデアを聞くのが大好きです。

WinUI / MSをBlazorプロジェクトから活用して、WinUIを「Blazorネイティブ」アプリとしてレンダリングすることはできませんか？

Steve SandersonがBlutterを発表し、Blazorを使用してGoogleのFlutterをレンダリングできることを知っています（これはXMLベースのUIです）。 Blazorチームは、さまざまなUIフレームワークを活用するために、UIレンダリング側に優れた技術を持っているようです。 BlazorがFlutterを処理できる場合は、同等のWinUI / Sillverlightタイプを処理できるはずです。

可能性は、断片化の少ないMSエコシステムであり、Webから始まり、統合された.net5を使用するネイティブアプリのxプラットフォームで終わるはるかに強力です。

@lukasf ：

@MarkIngramUK私はそれを次のように見ています：シンプルなアプリはプラットフォームのストックUIコントロールに固執します。 優れたアプリには独自のルックアンドフィールがあります。 ストックプラットフォームのコントロールは必要ありません。 Spotify、Netflix、または複数のプラットフォームで利用できるその他の優れた成功したアプリをご覧ください。 彼らのコントロールを見ただけでは、彼らが使用しているプラ​​ットフォームを知ることはできません。

クロスプラットフォームアプリは、すべてのプラットフォームでまったく同じように見え、同じように感じられるようにしたいと思います。

アプリの両方のアプローチを組み合わせています（https://affinity.serif.com）。 ダイアログのボタンの順序（Windowsは通常OK、キャンセル、macOSはキャンセル、OK）、角の丸いボタン、ホバー状態、チェックボックスとスイッチ、レイアウトなど、一般的なプラットフォーム標準を採用しない場合、お客様は非常に声高になります。そうです、表面的には、私たちのアプリはWindowsプラットフォームとmacOSプラットフォームで同じように見えますが、微妙な違いがあります（レンダリングとUIの相互作用）。 また、ネイティブAPIを使用してホストプラットフォームを最大限に活用しているため、最小公分母の問題が発生することはありません。

上記の議論は誤解を招くと思いますが、WinUIはMicrosoftが提供する最低レベルのUIフレームワークです。 クロスプラットフォームライブラリが必要な場合は、その上に構築します。 これは、「Win32はクロスプラットフォームである必要があります！」と言うのと同じです。 いいえ、Win32はWindowsプラットフォームに最適なフレームワークである必要があります。 ここでも同じ議論です。WinUIはWindows10プラットフォームに最適なフレームワークである必要があります。

@MarkIngramUKは書いた：

WinUIは、Microsoftが提供する最低レベルのUIフレームワークです。 クロスプラットフォームライブラリが必要な場合は、その上に構築します。

これは、詳細にもよりますが、実際に成功する可能性のある実用的な解決策として私を驚かせます（必ずしも唯一の解決策ではありませんが）。 2つの層：

1. Microsoft WinUI：クロスプラットフォームではありません。
2. Microsoft CrossXYZ-UI：クロスプラットフォーム。 Windowsの内部実装は、WinUIを使用して記述されます。

このような2層のソリューションは、元のメッセージで述べた問題を軽減するのに役立ちます。

複数の異なるオペレーティングシステムのサポートを維持するための作業量/困難さが増すため、WinUIの新しいバージョンが大幅に遅れる可能性があります。 たとえば、「この新しいバージョンのWinUIは、Windowsのみでデバッグを終了し、Android、MacOS、Apple iOSではまだデバッグを終了していないという問題を除いて、すでに数か月前にリリースできたはずです。」

過去のクロスプラットフォーム開発の経験によると、この2層ソリューションは、個別のクロスプラットフォーム「CrossXYZ」をサポートおよび支援する目的でWinUIにさまざまな変更/追加を実装すると、より成功することに注意してください。 -UI "レイヤー。 そうでなければ、WinUIがクロスプラットフォームレイヤーを支援するために何もしない場合、私の経験では、これは通常、クロスプラットフォームレイヤーがプログラミングと信頼性を困難にし、遅延させる歪んだフープを飛び越えることを余儀なくされることを意味します。

階層化理論によると、WinUIはWinUIを使用する「CrossXYZ-UI」レイヤーを認識または気にする必要はありませんが、その理論は実際には機能が不十分であるため、WinUIは「CrossXYZ-UI」レイヤーを支援しますが、WinUI内の「CrossXYZ-UI」に依存関係を作成するという恐ろしい考えを意味するのではなく、「CrossXYZ-UI」でのみ使用されるWinUI内の特別なプライベートフックを意味するのではありません。 "。 2つの層は、クリーンな方法で分離しておく必要があります。 WinUIのAPI設計の決定を行う場合、これらの決定は、個別の「CrossXYZ-UI」レイヤーへの影響を考慮し、WinUIが「 WinUIを直接使用するアプリだけでなく、CrossXYZ-UI "レイヤー。

Xamarinがすでに上記の2層方式で動作しようとしているかどうかはわかりませんが、動作している場合は、WinUIが個別のクロスプラットフォーム層をサポート/支援するという考えの一部を現在除外していると思います。 MicrosoftがXamarinをMicrosoftTeamsやその他のさまざまなMicrosoftアプリで使用するのに十分なほど信頼していなかった場合、Xamarinを信頼することは困難です。

以前は、正常に機能し、パフォーマンスの良いクロスプラットフォームソフトウェアを公開していましたが、技術的な理由でクロスプラットフォームの作業をキャンセルすることになりました。 たとえば、Linuxバージョンのソフトウェアを使用している顧客は、ソフトウェアの価格を0ドルにする必要があると主張しました。 したがって、Linuxバージョンの作成と保守のコストは、Linuxを使用する「顧客」からの収入の0ドルをはるかに上回り、明らかに持続不可能でした。

アプリ開発者として、理論的にクロスプラットフォームアプリを作成できるからといって、必ずしもそうする必要があるとは限りません。 興味深いことに、最近のクロスプラットフォームの議論で、人々はAndroidについて言及しているが、Linuxについては言及していないことに気づきました。 このシフトの最大の理由の1つは、おそらく前述の$ 0の問題です。

Re Unoプラットフォーム：

Unoが信頼できる優れた技術設計と実装を持っていたとしても、同様の0ドルの問題や不十分な収入のために、Unoが数年以内に消滅し、最終的に燃え尽き症候群やプロジェクトのキャンセルまたは停滞を引き起こす可能性があるというリスクと心配があります。 あるいは、ある日、ウノの最も重要な開発者が突然新しい趣味/興味/執着を獲得してウノへの興味を失ったり、新しい仕事/雇用者でウノに取り組む時間がなくなったりします。 @mdtaukが言ったように：

アプリやシステムの構築に投資しようとしている多くの企業は、開発しているプラ​​ットフォームがマイクロソフトのような膨大なリソースを持つ大企業のサポートと長寿を持っていることを知る必要があります。

@mdtaukの他のコメントにも同意します：

その議論の問題は、過去10年間で、Microsoftがプラットフォームを放棄していることを示していることです。

はいMicrosoftは、プラットフォームのキャンセルにより、ある程度の評判/信頼性/信頼性を失いました。 マイクロソフトは、さらなるキャンセルによって評判と信頼性がさらに失われないように注意する必要があると思います。 既存のプラットフォームの新しいバージョンは、新しいプラットフォームよりも優れています。

既存のプラットフォームのメジャーな新しいバージョンで重大な変更を導入する必要がある場合でも、評判/信頼性/信頼性の喪失を伴う新しいプラットフォームよりも優れています（または悪くはありません）。 アプリ開発者にとって、新しいプラットフォームに切り替えるコストは非常に高く、時には完全に手ごろな価格ではないため、Microsoftがプラットフォームをキャンセルするときはいつでも、それは非常に悪いニュースであり、アプリ開発者とMicrosoftの間の関係/パートナーシップを損ないます。

2層アプローチが非常に魅力的であることがわかった場合は、今すぐ続行してXamarinまたはUnoを使用できます。 そのようなフレームワークを待つ必要はありません。それらはすでに存在し、非常にうまく機能します。 ただし、AndroidまたはiOSをターゲットにするとすぐに、WinUIのすべての利点と改善点が失われます。 NavigationView、AppBars、SemanticZoomなどはもうありません。このリポジトリで行われることはすべて、クロスプラットフォームでは利用できません。クロスプラットフォームは最小公分母を意味するためです。 特にWindowsプラットフォームをターゲットにしている場合にのみ、これらを使用できます。 そのため、AndroidまたはiOSのネイティブコントロールを使用して、すべてのクールなWinUIを手動で再実装する必要があります。

それが良さそうな場合は、XamarinまたはUnoを使用してください。 このような3番目のフレームワークは必要ありません。 しかし、私にはこれはまったく良く聞こえません。 すべてのプラットフォームで完全な機能を備え、すべてのプラットフォームを直接ターゲットにするために使用できる、優れたコントロールセットを備えた1つのフレームワークが必要です。 複雑で重複したUI定義を使用して、アプリのナビゲーションなどを各プラットフォームに個別に再実装したくありません。 私にはそれは恐ろしい考えのように聞こえます。 WinUIがレンダラーアプローチを使用するクロスプラットフォームである場合、すべてのプラットフォームでそのすべての機能とすべての改善点を直接使用できます。 また、そのターゲットでコントロールをiOSのように見せたい場合は、iOSResourceDictionaryを適用するだけで済みます。 ネイティブコントロールや重複するUI実装をいじることなく、問題は解決しました。

「他のプラットフォームのレンダラーが更新されなかった」ため、リリースが遅れるという議論は非現実的な議論です。 レンダリングレイヤーは、「長方形の描画、線の描画、テキストの描画」などの低レベルの描画コマンドで機能します。 WinUIに新しいコントロールを追加する場合は、コントロールロジックを記述し、グリッド、境界線、テキストボックスなどを使用するコントロールテンプレートを提供します。 新しいコントロールはレンダラーの更新を必要としません。レンダラーは非常に低レベルで、変更率が非常に低くなります。 新しいブラシやエフェクトを追加する場合など、レンダラーに触れる必要があるのはまれなケースです。 Qtはレンダラーアプローチを使用しており、最も人気のあるクロスプラットフォームUIフレームワークの1つです。 このアプローチは彼らにとって非常にうまく機能しているようです。

@lukasf

すべてのプラットフォームで完全な機能を備え、すべてのプラットフォームを直接ターゲットにするために使用できる、優れたコントロールセットを備えた1つのフレームワークが必要です。

WinUIクロスプラットの作成に費やされたすべてのエンジニアとドルは、Windows上のWinUIをより良くするために使用できたはずのエンジニアとドルです。

「他のプラットフォームのレンダラーが更新されなかった」ため、リリースが遅れるという議論は非現実的な議論です。

iOS、Android、MacOS、Linux、およびWindows 7/8で動作する完璧な1：1レンダリングエンジンを作成するのは簡単な作業ではありません。 アプリとフレームワークが依存するWindows10APIは非常に多くあります。 基本的に、完全に新しいアプリフレームワークを作成することになります。

また、この最近のRedditスレッドを見てください： C＃のユーザーインターフェイスに何を使用すればよいですか？

文字通り、WinUIについての言及はなく、UWPを使用するための1つの半分の推奨事項です。 開発者は、必要となるすべての巨額の投資を考慮して、WindowsでWinUIをクロスプラット化しようとするずっと前に、熱心に使用する必要があります。

@lukasf 、

今すぐ続行して、XamarinまたはUnoを使用できます

以前の投稿でそれをほのめかしましたが、ターゲットとするプラットフォームごとに個別のフロントエンドを作成します。 Windows（WPF）、macOS（Cocoa）、iOS（UIKit）。

コントロールをそのターゲットでiOSのように見せたい場合は、iOSResourceDictionaryを適用するだけです。 問題が解決しました

ユーザーがOSを更新し、自分のアプリを除くすべてのアプリの外観が変わるまで。

レンダリングレイヤーは、次のような低レベルの描画コマンドで機能します...

クロスプラットフォームのレンダリング以上のものが必要です。 ウィンドウ管理、入力、テキスト処理、レンダリング、システム統合（タスクバー/ Aeroピークなど）。 WinUIのフォーカスをWindowsのみからクロスプラットフォームに変更しようとしても、極端な遅延が発生しないという方法はありません。

レンダリングに関しては、WinUIはWindows.UI.Compositionに基づいて構築されているため、その下位レベルのライブラリをクロスプラットフォームのライブラリに完全に置き換える必要があります。できれば、抽象化によるパフォーマンスの低下が発生しないようにしてから、移植してください。他のプラットフォームにそれを。 または、 Windows.UI.Compositionに依存しないようにWinUIを完全に書き直します。 繰り返しますが、小さな仕事はありません。

繰り返しになりますが、私はクロスプラットフォームライブラリに反対していません。 それらは目的を果たします、私はWinUIが1つになるべきではないと思います。

@lukasf

クロスプラットフォームは最小公分母を意味するからです。 …...すべてのプラットフォームで完全な機能を備えた、すべてのプラットフォームを直接ターゲットにするために使用できる、優れたコントロールセットを備えた1つのフレームワークが必要です。

すべてのプラットフォームで完全な機能を備えたものが必要です-私も-素晴らしいですね。 夢-しかし、あなたと私がそれを望んでいるからといって、それが可能で実用的でなければならないという意味ではありません。 願いと結果は大きく異なる可能性があります。 願いは完全な機能である可能性がありますが、結果はあなたが述べたのとほとんど同じ問題、つまり最小公分母になります。 あなたのアイデアにはメリットがありますが、あなたが言及した最小公分母の問題の犠牲者になることを免れません。

WinUIがレンダラーアプローチを使用するクロスプラットフォームである場合、すべてのプラットフォームでそのすべての機能とすべての改善点を直接使用できます。

本当にすべての機能とすべてのプラットフォームでのすべての改善？ WinUIをクロスプラットフォームのレンダラーに基づいているだけで、このような印象的な目標を達成できると確信していますか？ 解決策はとても簡単ですか？ 実際には、次のように、レンダラーよりもはるかに多くのことが必要になるため、アイデアを実際よりもはるかに簡単に見せていると思います。

• ウィンドウ管理に加えて、フライアウト、ポップアップ、コンテキストメニュー、モーダルダイアログ。
• 管理と解像度を表示し、変更に対応します。
• 入力デバイス（キーボード、マウス、ジェスチャー付きタッチスクリーン、ペン）。
• アニメーション。
• フォントとスタイル、レンダリングだけでなく、情報と測定値の取得。 また、Unicodeテキスト処理。
• ドラッグアンドドロップ。
• テキストだけでなく、さまざまな形式で機能するクリップボードの切り取り/コピー/貼り付け。
• MS Teamsのチャットペインのひどいスクロールパフォーマンスとは異なり、優れたパフォーマンスでスクロールします。
• 画像リソースなど、アプリパッケージ内に保存されている（さまざまな種類の）リソースの読み取り/読み込み。
• オーディオとビデオの再生。
• アクセシビリティのためのスクリーンリーダーなどの自動化。
• OSで現在構成されているものと一致するテーマ/外観。
• 国際フォーマット、マウスとキーボードの設定など、GUIに影響を与えるさまざまなOS設定の取得。
• モバイルデバイスとタブレットとデスクトップをサポートするための問題。
• そして、他のさまざまなものに加えて、プロジェクトのサイズとリリース日を見積もるときに簡単に忘れられる何百もの詳細。

あなたのアイデアにはまだメリットがあると思いますが、それはあなたが思ったよりもはるかに難しく、はるかに明確ではありません。 また、WinUIの開発と進行が大幅に遅くなる可能性があります。

WinUI / MSをBlazorプロジェクトから活用して、WinUIを「Blazorネイティブ」アプリとしてレンダリングすることはできませんか？

@pinox 、はい、確かに可能ですが、Blazor Nativeは、Unoをターゲットにしない限り、クロスプラットフォームにはなりません（これは私の個人的な好みです）。

クロスプラットは間違いなく私たちが考えたものであり、さまざまなクロスプラットフォームフレームワークアーキテクチャについてかなり徹底的な調査を行いました。 このスレッドの全員が持っているのと同じ結論に達しました。つまり、両方のソリューションに長所と短所があり、お客様はかなり分割されています😃

@lukasf現在宇野に存在する「最小公分母」はリソース制限の問題であり、階層化によるものではないと思います。 私は間違っていると証明されたいのですが、問題は解決でき、将来悪化することはないと思います。

ネイティブに見えるUIコントロールとウィンドウのレンダリングを提供するXAMLのサブセットがあります。または、macOS、iOS、Android、Linuxでレンダラーを所有し、すべてのプラットフォームで同じ「Fluent」コントロールとテンプレートをレンダリングできます。

ネイティブOSで動作するようにCoreWindow / App Window実装のある種のバリアントを作成することは別として、ウィンドウ内のすべてをレンダリングすることができます。

WindowsではDirectXですが、AppleにはMetalがあり、LinuxにはOpenGLがあります。 開発者は、ネイティブファイルのIOや通知などを処理するために、ある種のIFステートメントを実行する必要がありますが、Xamarinはそれを支援します

@ stevenbrix- @ Pinoxのアイデア_「WinUIをBlazorネイティブアプリとしてレンダリングする」_に返信したようですが、Pinoxの_その他_のアイデアについてどう思いますか？ 興味深いことに、 @ Pinoxも次のように書いています。

現在、ElectronはJavascript、HTML + CSSを使用しています。 ElectronをBlazor => C＃、HTML + CSS + gRPCで使用できない理由はありません。

@ Pinox- 「ElectronC＃」は「ElectronJS」よりもはるかに理にかなっているように見えることに同意しますが、提案したようにC＃とBlazorを使用する場合、MSTeamsアプリはおそらくElectronを必要としないと思いますBlazorがElectronに完全に取って代わるので、もう？ 私は誤解される可能性があります-Electronがサポートする機能については十分にわかりません。 ただし、ElectronJSに現在Blazorに欠けている便利な機能がある場合、この欠けている機能は、Blazorの次のバージョンでサポートされる可能性があります。

ですから、Blazorについて言及することで重要なポイントを提起したと思います。 MS Teamsアプリの適切な解決策は、ElectronJSからBlazor + WebAssemblyに切り替えることかもしれません。 それは本当に面白いです。

MS TeamsアプリがElectronJSからBlazorに切り替わった場合、WinUIの一部を使用する場合と使用しない場合があります。 すでに始めたように、BlazorとWinUIの間の接続または非接続のいずれかをさらに調査することができます。 面白い！

Silverlight、WinRT、UWP-はすべて放棄されました。 （UWPは技術的にはそうではないことは知っていますが、WinUIはおそらく代替品と見なされます）。

私の理解では、UWPはランタイムですが、WinUIはGUI /ウィジェットレイヤーなどです。つまり、Win UIはUWPAPIなしでWin32または.NETで実行されます。

私を悩ませているのは、UWPが実際にはかなり有能なAPIであるということです。 Win32ほど強力ではありませんが、Android（たとえば）と比較すると、非常に安全です。 開発者は、一貫したオブジェクトモデル、API、鈍感ではないなどの統一されたランタイムAPIがあるという点を見逃していると思います。ここにいる他の誰かが、90年代以前にWin32アプリを作成しましたか。 .NETが登場する前の00年代？ ネイティブプラットフォームAPIの使用はひどいものでした。

目前の問題に戻ると、WinUIクロスプラットフォームを絶対に見たいと思います。 COMなどに関連付けられていることについての投稿があります... AppleのCoreFoundationプラグイン（CFPlugin）フレームワークはCOMに基づくIIRCであるため、リフトとシフトはAppleプラットフォーム用のレンダラーを作成するのと同じくらい簡単です。 より論理的なことは、プラットフォームの違いをファサードし、高レベルのWinUIオブジェクトを維持することです。

私は、主にWindowsを対象とした、Microsoftによるまとまりのあるクロスプラットフォームの取り組みを望んでいますが、モバイル、Linux、およびmacOSと完全に互換性のあるオブジェクトモデルとXAML方言を購入しました。 .NET Coreには、すでに素晴らしいクロスプラットフォームエコシステム（GUIを除く）があります。 有能なXAMLフレームワークを強化すれば、特にビジュアルがネイティブに見える場合は、すべてのクライアント側の開発に頭を悩ませることはありません。 たとえば、MacではCommandBar-> NSToolbarの外観、MacではNavigation View-> NSOutlineViewなどです。

私の2cの価値はありますが、これに大きな焦点が当てられています。

また、マイクロソフトがWindowsベースの電話で再び市場に参入することを期待しています（息を止めませんが）。 一貫性のあるクロスプラットフォーム環境であることは、この目標に大いに役立ちます。

私はこの議論を興味深く見守っていきます。

Silverlight、WinRT、UWP-はすべて放棄されました。 （UWPは技術的にはそうではないことは知っていますが、WinUIはおそらく代替品と見なされます）。

私の理解では、UWPはランタイムですが、WinUIはGUI /ウィジェットレイヤーなどです。つまり、Win UIはUWPAPIなしでWin32または.NETで実行されます。

技術的には、WinRT（Windowsランタイム）がランタイムであり、UWP（ユニバーサルWindowsプラットフォーム）はそのランタイムの上に構築されていると思います。 また、UWPはXAMLを1つのUIフレームワークとして使用することをサポートしています。

WinUIはUWPのXAML部分になりますが、Win32コードで使用できるように拡張され、XAMLアイランドを介したWPFおよびWinFormsフレームワークとの相互運用が可能になります。

私を悩ませているのは、UWPが実際にはかなり有能なAPIであるということです。 Win32ほど強力ではありませんが、Android（たとえば）と比較すると、非常に安全です。 開発者は、一貫したオブジェクトモデル、API、鈍感ではないなどの統一されたランタイムAPIがあるという点を見逃していると思います。ここにいる他の誰かが、90年代以前にWin32アプリを作成しましたか。 .NETが登場する前の00年代？ ネイティブプラットフォームAPIの使用はひどいものでした。

UWPは、バッテリー寿命、セキュリティ、ID、ストア検証への最新のアプローチで構築されています。これは、開発者がmacOS、iOS、Androidなどのプラットフォームに期待するすべてのものです。 これらの固有の品質により、多くのフォームファクターやデバイスタイプで機能します。

目前の問題に戻ると、WinUIクロスプラットフォームを絶対に見たいと思います。 COMなどに関連付けられていることについての投稿があります... AppleのCoreFoundationプラグイン（CFPlugin）フレームワークはCOMに基づくIIRCであるため、リフトとシフトはAppleプラットフォーム用のレンダラーを作成するのと同じくらい簡単です。 より論理的なことは、プラットフォームの違いをファサードし、高レベルのWinUIオブジェクトを維持することです。

クロスプラットフォームですでにサポートされている.NETCoreのサポートを考慮に入れると、UIレイヤーが欠落している部分になります。 WinUIは当初完全にWindowsに焦点を当てていますが、うまくいけば、Microsoftは、プラットフォームが独自のレンダリングを置き換えて、同じUIを複数のプラットフォームで実行できるようにリファクタリングできるようになります。

私は、主にWindowsを対象とした、Microsoftによるまとまりのあるクロスプラットフォームの取り組みを望んでいますが、モバイル、Linux、およびmacOSと完全に互換性のあるオブジェクトモデルとXAML方言を購入しました。 .NET Coreには、すでに素晴らしいクロスプラットフォームエコシステム（GUIを除く）があります。 有能なXAMLフレームワークを強化すれば、特にビジュアルがネイティブに見える場合は、すべてのクライアント側の開発に頭を悩ませることはありません。 たとえば、MacではCommandBar-> NSToolbarの外観、MacではNavigation View-> NSOutlineViewなどです。

WindowsをPlatformNativeのコントロールと概念に変換するこの方法でそれを見始めるとすぐに、XamarinFormsになります。 Identitcal UIをどこでも実行できるようにするのではなく、最小公分母のアプローチをターゲットにします。

私の2cの価値はありますが、これに大きな焦点が当てられています。

また、マイクロソフトがWindowsベースの電話で再び市場に参入することを期待しています（息を止めませんが）。 一貫性のあるクロスプラットフォーム環境であることは、この目標に大いに役立ちます。

私はこの議論を興味深く見守っていきます。

この話の1つは、まだ詳しく説明されていませんが、UWPアプリをAndroidにコンパイルして実行できるようにすることです。これにより、SurfaceDuoで実行されるアプリの問題が解決されます。

Astoriaプロジェクトがありました... Windowsブリッジ上のAndroid。これは、AndroidアプリがMicrosoftStoreにアクセスできるようにするためにWindowsに提供される可能性があります。 Microsoftが独自のAndroidコードベースを取得すると、見込み客の想像が容易になります。

@Pinoxのアイデア「WinUIをBlazorネイティブアプリとしてレンダリングする」に返信されたようですが、Pinoxの他のアイデアについてどう思いますか？ 興味深いことに、 @ Pinoxも次のように書いています。

現在、ElectronはJavascript、HTML + CSSを使用しています。 ElectronをBlazor => C＃、HTML + CSS + gRPCで使用できない理由はありません。

「ElectronC＃」は「ElectronJS」よりもはるかに理にかなっているように見えることに同意しますが、提案したようにC＃とBlazorを使用する場合、MSTeamsアプリはおそらくElectronを必要としないと思います。 Electronを完全に置き換えますか？ 私は誤解される可能性があります-Electronがサポートする機能については十分にわかりません。 ただし、ElectronJSに現在Blazorに欠けている便利な機能がある場合、この欠けている機能は、Blazorの次のバージョンでサポートされる可能性があります。

@verelpode私が理解しているように、Electronは常に写真に写っている必要があります。 チームが仮想的にBlazorに移行する場合でも、今日のようにスタンドアロンのクライアントアプリが必要であり、Electronが最も理にかなっています。 理論的には、私が間違っていれば誰かが私を訂正することができますが、Blazor + WebAssemblyに切り替えると、Electronで実行しているときにアプリのパフォーマンスが大幅に向上します。 彼らのパフォーマンスの問題は何よりもアーキテクチャの問題によるものだと思いますが、VS CodeはElectronアプリであり、そこでのパフォーマンスに非常に感銘を受けています。

WebAssemblyはWebBrowserの外部でも実行される可能性があることに注意してください...
Blazorは、ASP.Netからの方法であり、.NETをWebBrowserに導入する実験だと思いますが、最も完全なパスは、.NET Core、Xamarin、UWP / WinUI、およびUNO上のXAMLです。 WinUI / Windows 10の完全なXAMLとそのXAMLの一部は、Webでも実行できます。

@verelpode @stevenbrix私の理解では、BlazorはElectronのネットワーク上で実行されます。 したがって、gRPCを使用して.netコアからElectronに直接移動します。 そのため、gRPCチャネルは電子と通信し、私が想定しているJSレンダラーではなくなります。 私が間違っている場合は、私を訂正してください。 WASMは関係していません。

Electronで直接gRPCを使用して速度が向上するのを見るのは本当に興味深いでしょう。 私の考えでは、最適化すると大規模になる可能性があります。

スティーブサンダーソンのユーチューブクリップで、彼はWASMを使用しないことに言及しています（ビデオの53:13分）
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

gRPCの部分をどこで読んだか思い出せません。とにかく、ElectronでgRPCを使用するWinUIに相当するSilverlightのようなものが可能かどうか、コミュニティを調査しますか？ いわばネットワーク上にWASMはありません。

@verelpode @stevenbrix私の理解では、BlazorはElectronのネットワーク上で実行されます。 したがって、gRPCを使用して.netコアからElectronに直接移動します。 そのため、gRPCチャネルは電子と通信し、私が想定しているJSレンダラーではなくなります。 私が間違っている場合は、私を訂正してください。 WASMは関係していません。

Electronで直接gRPCを使用して速度が向上するのを見るのは本当に興味深いでしょう。 私の考えでは、それは巨大になる可能性があります。

スティーブサンダーソンのユーチューブクリップで、彼はビデオにWASM（53:13分）を使用しないことに言及しています。
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

ありがとう@Pinox！ 見ているようです！ あなたが説明していることは、私にはサーバーサイドのBlazorのように聞こえます。私は、ブラウザーで実行され、DOMを直接操作するクライアントサイドについて考えたり話したりしていました。 そんなことを言うことで足を口に入れることができたので、そのビデオを見るまではもう言いません😄

@stevenbrixあなたは正しいかもしれませんが、これがサーバー側のレンダリングではないと仮定して、electronアプリはオフラインで実行されます。

私の推測では、JSレンダラーがgRPCを使用してElectronと通信した場合、ブレイザーレイザーエンジンを使用して同じことを行うことができます。

gRPCは.netcore3.0の新機能です。 Blazorは.netコア3をサポートしています。
そのため、.net core 3のgRPCは、「共通リンク」（gRPC）を使用して、既存のJSテクノロジーをc＃に置き換える可能性を開きます。 賢い動きMS;））

しかし、これがサーバー側のレンダリングではないと仮定すると、electronアプリはオフラインで実行されます。

@ Pinox-ええ、それは私を少し困惑させます。 https://github.com/ElectronNET/Electron.NETを使用していると思いますが、それは純粋に推測です

MS TeamsアプリがElectronJSからBlazorに切り替わった場合、WinUIの一部を使用する場合と使用しない場合があります。 すでに始めたように、BlazorとWinUIの間の接続または非接続のいずれかをさらに調査することができます。 面白い！ >>

@verelpodeこの画像を非常にエキサイティングなものにしているのは、Blazorの「リーチ」です。 アプリの人として、これまでのBlazorでの限られた経験は、=>非常にパフォーマンスが高く、ほとんどアプリのように感じられると言えます。 画像を見ると、ロードマップにはほぼ確実にネイティブプラットフォームとしてWinUIが含まれています。 （現在はコミットされていませんが）

彼らがBlazorNative側でフラッターを機能させることができれば、BlazorチームがReactNativeプラットフォームを接続してそれらすべてのネイティブプラットフォームに到達するのを妨げることになります。 Blazorは、C＃開発者があらゆるものに簡単に接着することができます。

私にとっての短期的な目標は、既存のWinUIを補完するHTMLUIを使用してバスに乗ることです。
WinUI / XamarinとBlazorの間には、私にできないことはほとんどありません。 1つのコードベース、3つのUIフレームワーク。 オプションが無限にあるように見えるので、これがどこに行くのかを見るのは非常にエキサイティングです。

私にとって、究極は常に超高性能の.netコア（C＃）=> Blazor ??? =>ネイティブUI-それは究極のエンジニアリング作業になります。

これは非常に刺激的な議論だと言わざるを得ません！ たくさんの異なる見解や議論、私も知らなかったたくさんの事実（「Blazor + Native UI ?? Wow」）。

@stevenbrixがすでに述べたように、異なるフレームワークでまったく同じUIを実行したい人（レンダラーアプローチ）と、ネイティブコントロールを使用して各プラットフォームでレンダリングしたい人の間でコミュニティに分裂があるようです。 どちらのアプローチにもメリットとデメリットがあります。 @stevenbrixに同意します。十分な人員があれば、「最小公分母」の問題を克服できます（たとえば、プラットフォームXでネイティブに使用できないWinUIコントロールは、そのプラットフォームXの一連の低レベルのネイティブコントロールによってUnoで内部的に実現できます。または部分的なカスタムレンダリングを使用）。 そうすれば、ほぼ完全なWinUIコントロールセットを使用できるようになりますが、それでもネイティブレンダリングを取得できます。 残念ながら、GitHubに多数の未解決の問題があることを考えると、Unoのリソースは現在かなり限られているようです。

ここで明らかなことは、コミュニティには魅力的で高性能なクロスプラットフォームフレームワークに対する高い需要があるということです。 そして、現在利用可能なフレームワークはどれも、（分割された）コミュニティの2つの側面のいずれも実際には満たしていません。 マイクロソフトが状況を改善する計画があるかどうかを確認することは非常に興味深いでしょう。

マイクロソフトは、Surface DuoとNeoが間近に迫っているため、SurfaceDuoとSurfaceNeoの両方で実行されるクロスプラットフォームアプリを開発する方法について適切なストーリーを考え出す必要があります。 たぶん、MicrosoftはUnoを購入し、適切に資金を提供する必要があります。そうすれば、これらの未解決の問題をすべて修正し、制御サポートを追加できます。 または、WinUI用のAndroidレンダリングレイヤーを開発します。 ホリデー2020に向けてデバイスが計画されているため、物事はすぐに動き始める必要があります。

@lukasf

十分な人的資源があれば、「最小公分母」の問題を克服することができます

十分な人的資源...私はあなたのメッセージのすべてに同意しますが、 @ kmgallahanが言及した重大な欠点も強調したいと思います。

WinUIクロスプラットの作成に費やされたすべてのエンジニアとドルは、Windows上のWinUIをより良くするために使用できたはずのエンジニアとドルです。

クロスプラットフォームが素晴らしい（本当にうまく機能する場合）ので、私は分裂していますが、一方で、WinUIのさまざまな問題の修正に大きな遅延が発生する場合は、クロスプラットフォームは必要ありませんWindowsの場合、またはWinUIの進行が遅くなりすぎて、改善や新機能が妨げられる場合。

クロスプラットフォームのトピックが、私たち全員が次の結果のいずれかを選択することを余儀なくされていることを意味する場合はどうなりますか？

1. Windowsでのみ実行されるWinUIの優れたバージョン。 また
2. すべてのプラットフォームで実行される中品質、信頼性の低い、および/または遅いWinUIであり、開発のペースが非常に遅く、多くの未解決の問題が5〜10年間修正されないままになっています。

それは防ぐ必要がある大きな問題です。 クロスプラットフォームへの興奮の中で、この大きな問題の防止に誤って注意を向けるのをやめるのは非常に簡単です。

クロスプラットフォームのトピックが、私たち全員が次の結果のいずれかを選択することを余儀なくされていることを意味する場合はどうなりますか？

1. Windowsでのみ実行されるWinUIの優れたバージョン。 また

2. すべてのプラットフォームで実行される中品質、信頼性の低い、および/または遅いWinUIであり、開発のペースが非常に遅く、多くの未解決の問題が5〜10年間修正されないままになっています。

@verelpodeまず、あなたはここで大いに怒り狂っています。 第二に：マイクロソフトは手元に膨大なリソースを持っています。 Microsoftがクロスプラットフォームフレームワークの提供に本当に関心を持っているのであれば、ネイティブのWinUIの改善とクロスプラットフォームソリューションの両方に資金を提供することはまったく問題ではないはずです。 実際、彼らは現在それを行っています。彼らはWinUIを開発および改善し、同時にXamarinを開発および改善しています。 彼らは同時にたくさんのプロジェクトを進めています。 したがって、Microsoftが優れたWindows UIフレームワーク（確かにそうです）とクロスプラットフォームフレームワーク（Surface NeoとDuoが間近に迫っていれば非常に理にかなっている）の両方を提供することに真剣に取り組んでいるのであれば、選択します。 どちらも妥協することなく実現できます。 （そして、一般的に、これが私たちが選択できるものではありません。マイクロソフトが彼らの決定を下し、私たちは結果が何であるかを見ることができます。）

したがって、クロスプラットフォームフレームワークに資金を提供することは、WinUIの開発と安定性が損なわれる必要があることをまったく意味しません。 Uno戦略が選択された場合、Unoは最上位に位置するため、WinUIから完全に独立しています。 WinUIはさらに進化させることができ、Unoは新しいWinUIコントロールと概念を（おそらくより遅い速度で）取得しようとします。 また、レンダラーアプローチが選択された場合でも、WindowsでWinUIが遅延することを意味するわけではありません。 新しいWinUIバージョンがリリースされた可能性がありますが、Androidレンダラーはまだありません。 次に、AndroidレンダラーがWinUI vLatestに更新されるまで、クロスプラットフォーム開発では古いWinUIリリースが使用されます。 Windows開発者は、最初からWinUIvLatestを使用できます。 リソースがあれば、両方を同じペースで開発できます。

@lukasf

Microsoftには膨大なリソースがあります。

本当ですが、それとは別の側面もあります。多くのプロジェクトマネージャーは、プロジェクトにもっと多くのお金、スタッフ、リソースを投入しても必ずしも成功するとは限らないという難しい方法を学びました。

Microsoftには膨大なリソースがあります。

本当ですが、それとは別の側面もあります。多くのプロジェクトマネージャーは、プロジェクトにもっと多くのお金、スタッフ、リソースを投入しても必ずしも成功するとは限らないという難しい方法を学びました。

次に、問題はそれらのプロジェクトマネージャーと組織構造である可能性があります;）

たぶん、MicrosoftはUnoを購入し、適切に資金を提供する必要があります。そうすれば、これらの未解決の問題をすべて修正し、制御サポートを追加できます。

私は、nventiveが過去数か月間Microsoftに求愛してきたことを知っています（Microsoftの買収はおそらく彼らの出口戦略です）。 宇野会議にはマイクロソフトも大勢参加しました。 Xamarinでさえ、現在Unoを使用してWebをサポートしています。

オプション（1）ネイティブレンダリングまたは（2）別のUI実装/レイヤーについて無限に議論できることは知っていますが、現在利用できるものと、Surface Duoに必要なものを見ると、実際に意味のある唯一のソリューションはUnoです。 @lukasfが言ったように、Microsoftはその背後にリソースを投入し、1年でどこまで到達できるかを確認する必要があります。 それが成功した場合（機能が完全で安定している場合）、開発者はそれが舞台裏でどのように実装されているかについてあまり気にしないと思います。 正しいアプローチがプラットフォームごとにネイティブにレンダリングされたWinUIであることが明らかになった場合、これは数年先の議論になる可能性があります。 今のところ、何もないよりも、25％完全なUnoプラットフォームから始める方が良いでしょう。

@stevenbrixはこちら：

@lukasf現在宇野に存在する「最小公分母」はリソース制限の問題であり、階層化によるものではないと思います。 私は間違っていると証明されたいのですが、問題は解決でき、将来悪化することはないと思います。

あなたたちは間違っています。
Unoは、Xamarinの「最小公分母」のマントラに従わず、逆に、すべてのXAMLコントロール（さらにはWindows Community Toolkit！）がすべてのプラットフォームで機能することを確認しようとします。

Unoは、Xamarinの「最小公分母」のマントラに従わず、逆に、すべてのXAMLコントロール（さらにはWindows Community Toolkit！）がすべてのプラットフォームで機能することを確認しようとします。

@weitzhandlerあなたは完全に正しいです！ 彼らのアーキテクチャは、Xamarin.Formsでは不可能なWinUIコントロールセットと完全に同等になる日が来ると思います。 私が正しく理解していれば、そのコントロールセットはまだ構築されていません。これは、 @ lukasfと私が参照していたものです。 私は間違っているかもしれませんが、私は知るのに十分な遊びをしていません、私は他のみんなから聞いたことを信頼しています:)

@weitzhandler実際のUWP / WinUI APIを再実装するUnoのアプローチは、Xamarinが新しいXAML方言を発明したよりもはるかに優れています。 ただし、Uno Xaml Controls Galleryを実行すると、かなりの数の領域が空になります。 それらのコントロールセットはXamarin.Formsよりも確かに優れていますが、まだ完全なUWP / WinUIではありません。 Unoは、APIサーフェスでさらに作業を行う必要があると思います。また、使用可能なコントロールを本当に安定してフル機能にするために、さらに作業を行う必要があります。

私は宇野をバイアルの選択肢として見ることができました。 しかし、それはいくつかの本当の進歩を必要とします、それはマイクロソフトが場に出ることができるところです。

別の点で、私は@lukasfがここで言ったことに完全に同意します：

優れたアプリには独自のルックアンドフィールがあります。 ストックプラットフォームのコントロールは必要ありません。 Spotify、Netflixを見てください

また、理想的には、WinUI + Fluentデザインをすべてのプラットフォームで同じようにレンダリングし、特定のプラットフォームに適用するために、ストックデザインが必要な人にネイティブのルックアンドフィールテーマを提供することが解決策だと思います。
Webはデスクトップと同じである必要があると思うので、とにかくDroidとiOSだけがその候補です。

クロスプラットフォームコントロールは、実際にはクロスプラットフォームフレームワークから独立しています。

仮説：将来、.Netコントロールは特定のプラットフォームに制限されなくなります。

既存の.NetUIクロスプラットフォームフレームワーク（Xamarin.Forms、Avalonia）があります。 みんな夢をみてるFutureXplatDotNetUIもあり、誰も定義できません。

コントロールを作成するときに、プラットフォーム固有の機能を使用するようにすることができます。 たとえば、各プラットフォームでネイティブプレーヤーを使用するビデオプレーヤー。 または、SkiaSharpを使用するなど、プラットフォームに依存しない方法でそれを行うこともできます。

いずれにせよ、コントロールは任意の.NetUIプロジェクトにインストールできます。

コロロリー：FutureXplatDotNetUIには最小限のコントロールセットのみが必要です

Viewクラスとレイアウトインフラストラクチャを定義する必要がありますが、nugetから標準の.Net UIパッケージをインストールすることで、特定のビューまたはビューのグループを追加できます。

（この投稿は、クロスプラットフォームの.Net UIに関するコメントであるため、WinUIとは関係ありません。）

WinUIチームの現在の優先順位は、「新しいネイティブWindowsアプリケーション」ではないと感じています。 代わりに、既存のアプリの最新化と、WinUIをより高レベルのUIフレームワークの基盤となるサポートにすることに重点を置いています...

@ reli-msft
WinUIチームは、人々が新しいネイティブWindowsアプリケーションを作成することを期待することをすでに諦めていると感じています。また、WinUIは、既存のアプリをアップグレードするために設計されています。

マイクロソフトで働いている人から来たのはちょっと変だ。

WinUIチームは、人々が新しいネイティブWindowsアプリケーションを作成することを期待することをすでに諦めていると感じています。また、WinUIは、既存のアプリをアップグレードするために設計されています。

マイクロソフトで働いている人から来たのはちょっと変だ。

@weitzhandler
私が使った言葉をもっと正確に使うべきです...それは「あきらめる」ではなく「気にしない」ということです。 とにかく、それはWinUIチームの外部の誰かからの感触です。
ただし、既存のアプリの最新化は_今のところ_より重要である可能性があり、それがWinUIがWin32をサポートすることを決定した理由である可能性があります。

WinUIチームの考えについて話していました。

一般的なMSとして、残念ながらそれは実際には理にかなっています。
MicrosoftがWinUIにReactやElectron、またはその他のHTML CSSやJS技術が得られるものを与えてくれたらよかったのにと思います（上記の私のコメントを読んでください）。

@charlesroddie

コントロールを開発するためのフレームワークが常に必要です。 継承する基本クラス、実装するインターフェイスが必要です。 コントロールツリーやテンプレートなどにアクセスするにはクラスが必要です。したがって、コントロールをフレームワークから分離することはできません。 これらのフレームワークがまったく同じ概念、クラス、および名前空間を使用しない限り、複数のフレームワークで制御を機能させることはできません。

（C＃ベースの）WinUIコントロールとWPFの間でコードを共有することはできますが、名前空間とAPIが異なるため、それでも困難です。 しかし、XAMLコントロールをAndroidまたはiOSフレームワークと共有することは明らかに不可能です。

それに加えて、.NETがUIスタックを構築するための適切なテクノロジーであるかどうかは本当にわかりません。 MicrosoftはWPFでそれを試し、ついに諦めてC ++に切り替えました。 アニメーションがますます重要になる時代に、レイアウトとレンダリング中にGCが中断することは、エンドユーザーに最高の印象を与えることにはなりません。 UIスレッドに完全に依存しないスムーズなアニメーションを処理するコンポジターが利用可能な場合、これはもはや真実ではないかもしれません。 その場合、コントロールスタックはC＃であり、最下位レベルのレンダリングとアニメーションの部分のみがネイティブコードになります。 しかし、当時、パフォーマンスが、次のXAML UIフレームワーク（SilverlightおよびUWP / WinUI）でC＃が完全に放棄された主な理由でした。

@lukasf複数のフレームワークで機能するコントロールはありません

本当じゃない。 コントロールが複数のフレームワークで機能する2つの方法を示しました。 最初のアプローチは、プラットフォーム固有のコードを作成することです。 次に、プラットフォーム固有のコードを各フレームワークに接続するためにサポートするフレームワークを知る必要があります。 現在これを行うことができますが、将来的には足場を簡単にすることができます。 2番目のアプローチ（プラットフォームに依存しないレンダリング）は非常に簡単で、現在実行されています。 たとえば、CSharpMath.SkiaSharpは、すべての.NetUIプラットフォームで使用できます。

@charlesroddieわかりました、多分私はあなたの投稿を間違えました。 しかし、その場合、制御は実際にはフレームワークから独立しているわけではありません。 フレームワークがコントロールによって明示的にサポートされているアプリにのみインストールできます。 また、レンダリングはコントロールのごく一部にすぎません。 プラットフォームに依存しないレンダラーを使用している場合でも、サポートされているすべてのフレームワークに対して、そのようなすべてのコントロールで、制御ロジック、データバインディング、および入力処理を実装する必要があります。 サポートされているフレームワークが非常に似ていない限り、それは私にはあまり効果的ではありません。 すでに述べたように、WPF、Silverlight、UWP間でコードを共有することは可能です。 しかし、それを超えると、それは非常に困難になり、私はそのような制御を目にすることはないだろうと思います。

クロスプラットフォームフレームワークでは、通常、すべての制御ロジック、データ、入力処理（場合によってはレンダリング）を1つのAPIに対して1回だけ記述でき、それを各フレームワークに自動的にマッピングします。 したがって、フレームワークが存在すると、制御の実装ははるかに効率的になります。

フレームワークがコントロールによって明示的にサポートされているアプリにのみインストールできます。

それは本当ですが、より多くのプラットフォームをサポートすることは簡単にできます。

制御ロジック、データバインディング、および入力処理は、サポートされているすべてのフレームワークに実装する必要があります。

データバインディングは、UIフレームワークによって実装される必要はありません。 これは、一般的であるが劣った.Netアプローチによって助長された誤解です。 コントロールは、コンストラクターとプロパティを指定するだけで済みます。 gettable / settableプロパティを指定すると、コンシューマーは任意のアプローチフレームワークを使用して必要なデータを移動できるため、データをバインドする特定の方法を指定する必要はありません。 （そして、ほとんどすべてのアプローチ/フレームワークは、WPF / UWP / Xamarinデータバインディングよりも優れています。）

制御ロジックは、プラットフォームに依存しない方法で.Netに自然に実装されるため、私が提供したどちらのアプローチでも完全に対応できます。

入力処理は「クロスプラットフォームフレームワーク」の恩恵を受けますが、これは非常に小さな制御フレームワークであり、プラットフォーム固有のプロジェクトとクロスプラットフォームプロジェクトの両方で参照でき、マウス/タッチとキーボード入力。 SkiaSharp.Extendedコントロールプロジェクトはこの方向に進んでいます。

データバインディングをWPFまたはWinUIで機能させる場合は、DependencyPropertiesを宣言する必要があります。 データバインディングで機能しないXAMLコントロールを使用する人がいるのではないかと強く疑っています。 データバインディングはこれらのフレームワークをよく知っており、好むと好まざるとにかかわらず、DependencyPropertiesが機能する必要があります。 それらを追加しないと、現在のWindowsプラットフォームフレームワークのいずれでもコントロールを使用できません。

「コントロールロジック」を使用すると、トップレベルコントロールのサブコントロールの定義や作成、これらのコントロール間のデータとステータスの処理、レイアウト、サブコントロールとの同期など、他のコントロールとの相互作用をさらに強化できます。 これはすべてフレームワーク固有の作業です。 これをデータバインディングコード（ターゲットフレームワークで必要な場合）および入力処理と組み合わせると、おそらく制御コードの90％以上を占めることになります。 そのようなコントロールの1つの異なるフレームワーク実装間の共通部分はおそらく非常に小さいので、そのように作業することは私には意味がありません。

できないとは言いません。 しかし、フレームワークは非常に異なるため、非常に複雑になります。 つまり、今そのようなコントロールを書くことは可能ですが、それでも私はそれを見たことがありません。 そして個人的には、これが少しでも人気のあるアプローチになるとは思いません。

現在のWindowsプラットフォームフレームワークではコントロールを使用できません

それは真実ではない。 DependencyPropertiesを実装しないコントロールは、WPF / WinUIで使用できます。 これは、従来の.Netデータバインディングの欠陥の1つです。これは、設定可能なプロパティをすでに定義しているコントロールに偽のDependencyPropertiesを追加することを推奨します。 巨大なコードの重複。 （ちなみに、クロスプラットフォームコントロールは「XAMLコントロール」ではないため、WinUIのマーケティング言語での「XAML」の誤用に惑わされるべきではありません。Xamlは、複数のユーザーで使用できるオプションのマークアップ言語です。 .Net UIフレームワーク。）

トップレベルコントロールのサブコントロール

はい、コントロールはサブコントロールを指定する必要があるため、上位レベルのコントロールをクロスプラットフォームで使用できるようにするには、下位レベルのコントロールも指定する必要があります。 下位レベルのコントロールがクロスプラットフォームで利用できる場合、それらを統合するのは簡単です。 あなたは、効率的なアプローチではない、より低いレベルのコントロールの前に、より高いレベルのコントロールを書くことを想像しています。

良いニュースは、Microsoftがすでに.netネイティブを殺すことを決定したことです。

@roblooこれが起こったら、私はそれを祝うパーティーを開きます。

Unoが信頼できる優れた技術設計と実装を持っていたとしても、同様の0ドルの問題や不十分な収入のために、Unoが数年以内に消滅し、最終的に燃え尽き症候群やプロジェクトのキャンセルまたは停滞を引き起こす可能性があるというリスクと心配があります。 あるいは、ある日、ウノの最も重要な開発者が突然新しい趣味/興味/執着を獲得してウノへの興味を失ったり、新しい仕事/雇用者でウノに取り組む時間がなくなったりします。

@verelpode
私はおそらく他のほとんどの人よりも同じ懸念を共有しています。 私は、大手企業（Oracle、Google、Microsoftなど）に支援されていないオープンソースパッケージを平均よりもはるかに少なく使用しています。 これを実現するには、次の両方の条件が満たされている必要があると思います。

1. Nventiveは事業を終了します。 Nventiveは、パンとバターのビジネスをUnoに依存しています。
2. 宇野の背後にいる主要な人々は、この素晴らしいプロジェクトへの興味を失います。

＃1については、Nventiveが現在の建物を拡張し、より大きな施設に移転していると聞きました。そのため、拡張されたUno Conf 2020（2日から3日）は別の建物で開催されます。 私はエコノミストではないので、多くの企業を廃業に追いやる深刻な不況が起こるかどうかは予測できません。 少なくとも、近い将来、経済の崩壊は見られません（私たちの地域の失業率はしばらくの間2％を下回っています）。

＃2に関しては、主な宇野の男たちが彼らのプロジェクトに対して持っているタイプの情熱を見ることはめったにありません。 それは、彼らのための単なるソフトウェア製品ではなく、ほとんど高貴な原因のようなものです。 まあ、愚か者だけが彼の心を変えないので、私は彼らが興味を失う可能性がゼロであるとは言いませんが、おそらくゼロからそう遠くはありません。 正直なところ、これが私が今、宇野を楽しんで頑張っている主な理由です。 他のプラットフォームと同じように、Unoには多くの問題があります（BTW、いくつかの便利な機能がないことは私にとって問題ではありません）が、それらは重大な問題に迅速に対処します。 毎日半ダース以上のリリースがあると思います。 プラットフォームの既知のバグが原因で私のアプリの1つを公開できず、大手企業（😉）が修正するのに文字通り半年以上かかりました（チケットをアーカイブしました）。

Sliverlight、Windows Phone 7 / 7.1 / 8 / 8.1 SDK、Windows 8 / 8.1 / 10（WinRT、UWP…）での豊富な経験に基づいています（私のメインの電話は、これまで人類史上最高のモバイルプラットフォームであるWindowsPhoneでした。今年はAndroidに切り替える以外に選択肢がなかった直前）、Microsoftの同様のものよりも、UnoPlatformの寿命に自信があります。 はい、UnoはすべてのMicrosoftテクノロジに基づいていますが、Microsoftが内部で物事を変更するときに移行を処理します。

ミゲルがウノを支持し、ウノ会議で基調講演を行った理由は、彼がウノを幼い頃の赤ちゃんのモノのように見、Nventiveを彼のXimianのように見ているからだろうかと思っていました。

私は最悪のシナリオ、つまり宇野の死に備えています。 すべてのUnoプロジェクトは、私のお気に入りの2つのテクノロジーであるC＃とXamlを使用しているため、それらをベースにした新しいプラットフォームに簡単に移行できます。 少なくとも、C＃コードは非常に古くなっていると言えます。 すべてのプロジェクトで共有されているコアユーティリティライブラリのコードの多くは、10年以上前のものです。 それらはまだ完全に機能しており、今後数十年で機能すると思います。

@stevenbrix @weitzhandler @Pinox

興味深い議論で、BlazorNativeがここでも言及されていることに気づきました。

SteveとBlazorからの新しいNDCconfがあり、検討するのは興味深いかもしれません。上記のビデオでは、Blazor + Nativeを使用してFlutterをレンダラーとして使用しています。 しかし、新しいNDC Confビデオでは、SteveはXamarin.Formsを使用してXAMLのようなマークアップでモバイルUIをレンダリングするようになりました。 Blazor Nativeは、Blazor Nativeをサポートしているのと同じように、React Nativeをサポートするため、WinUIで現在使用できる最も実用的なxプラットフォームソリューションであることがわかりました。 そのため、.Netは（Web、モバイル、Winデスクトップ）をターゲットにできるようになりました。

アップデート：
MS Teamsの新しいバージョンが最近リリースされ、最新のチャットメッセージを表示するのにかかる時間が改善されました。 以前のメッセージで、約27秒かかったと述べましたが、ありがたいことに、新しいバージョンの方が最新のチャットメッセージを表示する方が高速です。

この改善に取り組んだマイクロソフトのスタッフに感謝します。 ：笑顔：

私の視点：

Microsoft：ほとんどすべての機能を無効にしてHTML UIへのイベントバインディングのみに減らすことができる最小限のWebview2（ Carloと同様）を開発できます...他のすべての機能はC＃/ネイティブ/コミュニティからの範囲外で開発されている可能性があります（クロスプラットフォームとして）ネイティブバックエンドライブラリ）。
HTML / CSS側がどれほど複雑かは知っていましたが、そのUIの知識と、イベントコードの背後にあるC＃コードの1対1のバインディングを活用したいと思います。

Microsoft：4x 8gb / 4x32gbを持っていた人の8 / 32gbの1つのRAMの電源を切ることができます...多くのエネルギーを節約します。

これを行うために、Electronで開発された多数のアプリを削除します... MicrosoftとBillGatesの目標に依存します。

最善の目標は、誰もがアプリの開発を開始し、CSS3標準のGUIフレームワークから牽引力を獲得することです... QT / GTKのように可能です...しかし、あまりにも悪いGTKはコピーレフトではなく、.netと同等のQMLのように可能です。

アップデート：
修正中の問題について前のメッセージで言ったことをキャンセルしてください☹️修正されていません。 これは奇妙なことです。数週間、問題はなくなったように見えましたが、最近問題が再発しました。 MS Teamsは、最新のチャットメッセージを表示しようとすると、再び困難と遅延を引き起こします。

JavaScriptで記述されていることを考えると、MSTeamsのバグは驚くべきことではありません。 _もちろん_JavaScriptで書かれたアプリはバグがあります-なぜ他の人が期待するのでしょうか？ MS Teamsは、JavaScriptを使用するElectronJSを使用していますが、JavaScriptが実際のプログラミング言語を意図したものではなく、Webブラウザー用のカジュアルなスクリプトアドオンであることがよく知られています。

JavaScriptには、コンパイル時の型チェックも含まれていません。これは非常に悪いことです。 したがって、JavaScriptでこの_主要な_問題を修正しようとするTypeScriptの必要性。 実際、JavaScriptをプログラミング言語と考えると非常に悪い問題です-JavaScriptはプログラミング言語としてひどいです-しかし、私が言ったように、それはプログラミング言語ではなく、カジュアルなスクリプト言語を意図していたので、プログラミングアプリはJavaScriptの目的ではなかったため、プログラミング言語の本質を含めることができなかったためにJavaScriptを許してください。

本当に許されないのは、プログラミング言語であるかのようにカジュアルなスクリプト言語を使用するという理解できない決定です。 マイクロソフトがチームと同じくらい重要なアプリに非専門的な言語を選択したのを見て、私は本当に驚きました。 「JavaScript」という名前は、プログラミング言語ではなくスクリプト言語であるため、「JavaScript」の名前に「Script」が含まれていることを忘れながら、誰もが「JavaScript」という名前を言うことはできないと思いました。 どういうわけか、「JavaScript」の「スクリプト」という言葉の存在は完全に混ざり合っています。

WinUIチームのメンバーは、WinUIの多くの改善に懸命に取り組んできました。 WinUIの代わりにカジュアルなスクリプト言語を使用するというMicrosoftの決定は、意味がありません。

非常によく書かれた高性能のJavaScriptWebアプリケーションがたくさんあります。 確かに、他のテクノロジーでさらに優れたパフォーマンスを得ることができます。 しかし、Teamsが遅い理由は、JavaScriptに基づいているという事実ではないことは確かです。 これは、サーバー側またはクライアント側のいずれかでの実装の誤り（おそらく非同期/スレッドの問題）が原因です。 確かに、はるかに優れたパフォーマンスでJavaScriptでチームを作成することは可能です。

誤解しないでください。私はJavaScriptファンではありません。 実際、それは恐ろしい言語だと思います。 表示される問題は、TeamsがJavaScriptテクノロジーを使用しているという事実が原因ではないと言っているだけです。 優れた（一流ではない）パフォーマンスで、JavaScriptでUnrealエンジンを実行することも可能です。

WinUIはWindowsデスクトップフレームワークのみです。 そのため、それに基づいてx-platform Teamsアプリケーションを開発することはできず、今日でも不可能です。 しかし、Teamsの問題は、MicrosoftがWinUIをクロスプラットフォームにすることを検討するのに役立つかもしれません。 真のxプラットフォームのWinUIと.NETCoreを使用すると、拡張性に優れたレスポンシブアプリの開発がはるかに簡単になります。

WinUIはWindowsデスクトップフレームワークのみです。 そのため、それに基づいてx-platform Teamsアプリケーションを開発することはできず、今日でも不可能です。 しかし、Teamsの問題は、MicrosoftがWinUIをクロスプラットフォームにすることを検討するのに役立つかもしれません。 真のxプラットフォームのWinUIと.NETCoreを使用すると、拡張性に優れたレスポンシブアプリの開発がはるかに簡単になります。

Unoを使用すると、WinUIはクロスプラットフォームになります。 GooglePlayストアでUNOCalculatorを見てください。 これは、Windows10計算機の移植バージョンです。

誰かがUWPとElectronの比較を求めていましたが、ここにいくつかあります。

https://twitter.com/emiliano84/status/1198177284533956608

https://twitter.com/emiliano84/status/1198179206548602881

ばかげている新しいXBOXアプリは、1.5GBのRAMを無料で簡単に使用できます

誰かがビデオを作成して、UWPと比較してどれだけ遅いかを示すことができれば素晴らしいと思います

WinUIとXプラットフォームに関するこのディスカッションのほとんどの参加者はこのストーリーについて読んだと思いますが、一部の人が見逃した場合に備えて、Windows 7上のWinUIを紹介します–はい、Unoプラットフォームで可能です。 アプリがUnoに基づくと、Windows、Web、iOS、Androidをターゲットにします。

@lukasf

確かに、はるかに優れたパフォーマンスでJavaScriptでチームを作成することは可能です。

はい、それは_可能_であり、許容できるパフォーマンスでPowerShellでMS Teamsを作成することも_可能_です（私はPowerShellが好きです）。また、SpaceXがロシアに移転し、衛星を起動することも_可能_ですが、それでも無能な管理になります。 SpaceXをロシアに移転するか、PowerShellやJavaScriptなどのスクリプト言語でMSTeamsアプリを作成するかを決定します。 SpaceXがロシアに移った場合、そうです、SpaceXはまだ動作する可能性がありますが、正直なところ、Elon Muskは実際には効果的なマネージャーではなく、彼が何をしているかを本当に知りません。

私は、Electronが原因であると100％確信しているわけではありません。 Visual Studio CodeもElectronをベースにしていると言われていますが、そのパフォーマンスはかなり安定しています。 Electronアプリは基本的にWebアプリであり、パフォーマンスの悪いWebアプリの背後には何千もの理由があります。

WinUIが「チームを勝ち取る」ためにできることはあまりありません。 それは技術ではなく、製品です。 チームは、急速な成長の道を歩み始めたスタートアップ企業のようなものです。 機能が同等の複数のプラットフォームで実行する必要があり、可能な限り迅速にこれを実現する必要があります。 これが、Webベースのテクノロジーを選択する唯一の理由です。 モバイルでは、JavaScriptでハードウェアを利用する唯一の方法であるため、React Nativeを使用できますが、デスクトップでは、Webアプリ、Mac、およびLinuxバージョンで機能の同等性とコードの保守性を維持する必要があります。 UWPアプリモデルが必要な機能を追加するのを待つことができないため、win32を対象とするフレームワークを使用する必要があります。 共有するデスクトップまたは特定のアプリを選択するオプションを使用してデスクトップを共有できることは、その重要な機能の1つです。 これがスタートアップのような製品の開発方法です。 Slackは、最初にjqueryを使用して成長をハックし、非常に悪いコードで終了しましたが、リファクタリングする時間があれば、reactを使用してすべてをすばやく書き直し、Slackは以前よりもはるかに高速になりました。 WinUIとElectronは同じカテゴリに属していないため、追加する機能に関係なく、実際に必要なアプリのElectronに取って代わることはありません。