Windows 11 がネイティブ アプリではなく Web アプリを採用し続ける理由を開発者が説明
<本文>
WhatsApp がネイティブの Windows アプリを Web ラッパーに切り替えるという世界中で嫌われている決定を下したとき、批判のほとんどは Meta に向けられました。そして当然のことです。それは怠惰に感じられ、明らかに RAM を大量に消費するダウングレードであり、Windows 上でアプリが持っていたわずかな「ネイティブ」エクスペリエンスが削除されました。
しかし、現実はもう少し不快です。
Meta ですら、ネイティブ Windows アプリを使い続ける動機はあまりありませんでした。同社はほとんど更新せず、同等の機能を提供せず、最終的にはデフォルトで Web バージョンを使用するようになりました。主な理由はおそらく、Web アプリの構築と維持が安価であるという事実です。しかし、実際の問題は、Microsoft が開発者に長期的にコミットできる UI フレームワークを提供していないことです。 Web アプリにはそのような問題はありません。
最近、Windows Insight の長年の読者である Alexander Ovchinnikov 氏から話を聞きました。彼は開発者でもあります。彼の指摘は、多くの開発者がすでに感じていることと同じです。
ユーザー ベースがはるかに少ないにもかかわらず、常にネイティブ アプリを提供する macOS とは異なり、Windows 専用の Web アプリを推進する開発者の姿勢は、利便性を重視するものではありません。それは信頼、あるいは信頼の欠如の問題です。
長年にわたり、Microsoft は複数の「将来の」フレームワークを導入してきましたが、後にそれらのフレームワークから遠ざかりました。 WPF、Silverlight から UWP、そして WinUI 3 に至るまで、同社はこのパターンを変えていません。 Alexander 氏が言うように、多くの開発者は現在、Microsoft が今日推進しているものは何であれ、その上に構築することを正当化できるほど長続きしない可能性があると考えています。
Microsoft はここ数十年、明確な GUI 戦略を持っておらず、現在 Windows は開発者が実際に何を使用すべきかについての最終的な答えがないまま、あまりにも多くのフレームワークを提供しています。
これを知ることで、Windows 用 Web アプリに対する私の見方が変わりました。これらは、プラットフォーム自体に不安がある場合の代替オプションです。しかし、Microsoft は最近、Windows 用の 100% ネイティブ アプリの作成に熱心に取り組んでおり、状況が好転する可能性があります。
Windows は 1 つの明確な開発パスから、混乱を招く選択肢が多すぎるようになりました
Windows アプリの構築に頭の中で議論する必要がなかった時代がありました。初期の Windows 開発は、よく理解されている単一のアプローチを中心に展開されました。 Win32 が答えでした。 1 つの API、1 つのメンタル モデル、そして物事を成し遂げるための明確な方法。
Windows 開発の「バイブル」として広く認められている Charles Petzold の「Programming Windows」により、Windows がアクセスしやすくなり、開発者はプラットフォームが足元で変化することがないことを認識して時間を投資することができました。その安定性が信頼を生み出し、信頼がエコシステムを成長させました。
しかし、Microsoft は Win32 をより最新のものに進化させるのではなく、新しいレイヤーや代替手段を導入し続けました。 MFC は最初に C++ ラッパーとして登場しました。次に、.NET 開発者向けの WinForms。 WPF に続いて、XAML とハードウェア アクセラレーション レンダリングが登場しました。 Silverlight はクロスプラットフォームの賭けとして登場しました。その後、Windows 8 と Windows 10 の時代に WinRT と UWP が登場しました。そして現在、Windows App SDK を備えた WinUI 3 と、クロスプラットフォーム開発用の MAUI が提供されています。
これらはいずれも、Windows 開発の未来に関する強力な宣伝とともに発表されました。それぞれが開発者に、時間を投資し、新しいパターンを学習し、その上に構築するよう求めました。
問題は、これらのテクノロジーが悪かったということではありません。彼らの多くは真に時代を先取りしていました。問題は、「未来」が完全に定着する前に入れ替わってしまうことだった。開発者は単一の進化するプラットフォームではなく、動くターゲットを追いかける必要がありました。
Jeffrey Snover の詳細なブログでは、Windows アプリはどのように構築すべきかという単純な質問に対する明確な答えを Windows が持たなくなったと指摘しています。
Silverlight が登場して有望に見え、Microsoft が HTML5 に舵を切るまでは、WPF が未来であると考えられていました。 UWP はあらゆるものに対応する統合プラットフォームとして推進されましたが、社内であっても完全に採用されることはありませんでした。 WinUI 3 は現在、最新のソリューションとして位置付けられていますが、そのロードマップは開発者が以前に抱いていたレベルの信頼を刺激するものではありません。
Microsoft が明確な方向性を持った新しいフレームワークを導入すると、開発者はそれを採用し始めます。そうなると戦略は変わり、注目は別のところに移るでしょう。以前のフレームワークが必ずしも正式に廃止されるわけではありませんが、徐々に関連性を失います。このサイクルが何度も繰り返されたため、開発者は完全にコミットするのをやめました。
Alexander 氏が私たちに語ったように、今日の感情は、Microsoft が以前のフレームワークに固執できないのであれば、なぜ現在のフレームワークが異なると考える必要があるのかということです。
今日はこんな感じです。 Windows アプリに何を使用するべきかを開発者に尋ねると、答えは誰に尋ねるかによって異なります。依然として Win32 を推奨する人もいます。安定しているという理由で WPF を好む人もいます。 WinUI 3 は最新のものとして位置付けられていますが、まだ広く信頼されているわけではありません。 MAUI はクロスプラットフォームで使用するために存在します。次に、Electron または PWA を使用した Web ルートがあります。それに加えて、Avalonia や Qt などのサードパーティ フレームワークが注目を集めています。
これは開発者が求めていた種類の選択ではありません。それは完全に不確実性です。
開発者がネイティブではなく Web アプリを選択する理由
最も人気のある Windows アプリの中には、完全にネイティブではないものもあります。 WhatsApp、Spotify、Discord、Slack、Notion、Zoom、さらには Microsoft 独自のエコシステムの一部…Microsoft Teams (書き換え前)、Clipchamp、およびいくつかのファーストパーティ エクスペリエンスでも WebView2 が使用されています。
もちろん、Web アプリを一度構築すれば、どこにでも配布できるのは非常に簡単になりました。個別のコードベースを維持することなく、Windows、macOS、Linux、さらにはブラウザ内で実行できます。 Electron、Chromium ベースの WebView、Progressive Web Apps などのフレームワークにより、配布が簡素化され、更新が高速化され、開発コストが削減されています。企業は無視するのが難しいと感じています。
Microsoft は WebView2 に軸足を置き、アプリ内に Edge (Chromium) エンジンを埋め込みます。これは一貫性を保つためにはうまく機能しますが、多くの「デスクトップ」アプリがコンテナ内で実行されている単なる Web ページであることも意味します。
そして明らかな欠点は、これらのアプリはより多くの RAM を消費し、応答性が低く感じられ、OS とそれほど深く統合されていないことです。複数の Electron アプリを同時に実行すると、システム リソースが簡単に消費されてしまいますが、これは従来のネイティブ アプリの方がはるかにうまく処理できました。
macOS と iOS では、開発者は依然としてネイティブ アプリを優先しています。他の場所で Web テクノロジーを持っている企業でも、Apple デバイス用のネイティブ バージョンを構築しています。それは、Apple がより明確な開発方針を維持しているためです。 Cocoa、AppKit、そして今回の SwiftUI などのフレームワークは、一貫してサポートされ、進化してきました。開発者は何を使用すればよいかを知っており、さらに重要なことに、それが何年後も意味があることを知っています。
Windows にはこれほど明確な点はなく、開発者はそれに応じて対応します。
そのため、多くの人は再び方向性を変える可能性のあるフレームワークに賭けるのではなく、Web を選択します。これは完璧ではなく、多くの場合、客観的にはデスクトップのパフォーマンスが低下します。しかし、これにより、Microsoft の次の決定に依存するという大きなリスクが回避されます。
Microsoft はこの問題を修正しようとしていますが、手遅れになる可能性があります
Microsoft がこの問題を認識している兆候があります。最近の取り組みでは、パフォーマンスの向上、Web ベースのコンポーネントへの依存の軽減、Windows 全体でのネイティブ エクスペリエンスの構築に向けて取り組んでいることが示唆されています。 Windows 開発者に 100% ネイティブ アプリの構築を歓迎する Rudy Huyn の X の投稿は、肯定的に受け止められています。
ただし、アプリ自体を修正することは方程式の一部にすぎません。
たとえ Microsoft が今後、より優れたネイティブ アプリを提供するとしても、開発者は依然として躊躇するでしょう。このためらいは、WinUI 3 で何ができるか、何ができないかによって生じるものではありません。それは、それ以前に起きたすべてのものに起こったことから来ています。何年にもわたって優先順位が変化してきたため、開発者は慎重になっており、その種の躊躇は一夜にして消えるものではありません。
Microsoft がそれを変えたいのであれば、1 つのフレームワークに完全にコミットし、それを開発者によく伝える必要があります。それは、フレームワークが成熟するまで十分に長く使い続け、その方向性を明確にし、それをサポートすることも意味します。開発者には、変更が発生した場合の明確な移行パスとともに、信頼できるロードマップが必要です。
本当の問題はテクノロジーではなく、一貫性です
マイクロソフトには能力が不足しているわけではありません。同社には業界最高のエンジニアリング人材がおり、強力な開発ツールを構築してきた長い歴史があります。導入されたフレームワークの多くは、技術的な観点から見て本当に強力でした。
欠けているのは一貫性であり、一貫性です。
レベッカ・サッター氏の分析では、問題は技術的な障害ではなく、繰り返し方向を変える内部決定のパターンにあると述べられています。
これらは開発者にとって繰り返し不確実性をもたらしました。外部から見ると、なぜそのような変化が起こったのかは問題ではありません。重要なのは結果です。開発者には複数の道が残されましたが、どれも長続きする保証はありませんでした。
だからこそ、今日のような状況になっているのです。問題は、Windows のオプションが少なすぎることではありません。それは、どれも決定的なものではないということです。開発者は、これ以上のフレームワークを求めているわけではありません。彼らは信頼できる人を求めています。
Web アプリは問題ではなく症状です
Web アプリはデスクトップ コンピューティングに適しているため、Windows を引き継ぐわけではありません。多くの場合、そうではありません。彼らが引き継いでいるのは、Windows プラットフォームに投資したくない開発者に信頼性を提供しているからです。
過去の経験に基づいて計算された決定を下した開発者を責めることはできません。
Microsoft が Windows 上のアプリの品質を向上させたいのであれば、解決策は Windows 11 を修正してネイティブのファーストパーティ アプリを構築するだけではなく、開発者との信頼を再構築し、今度はプラットフォーム (WinUI3、私はそう願っています) が一貫性を保つことを証明することです。
ホーム
シェアする
ニュースレター
WL ニュースレター
WLニュースレターです！
最新の Windows、IT、AI アップデートを常に入手してください。 50,000 人以上の加入者から信頼されています。
名前
電子メール
無料で参加
*️⃣ 出典リンク:
指摘、最も人気のある Windows アプリは真のネイティブではなく、Windows 全体でより多くのネイティブ エクスペリエンスを構築し、Windows 開発者は 100% ネイティブ アプリを構築する必要があります。 Rebecca Sutter の分析 、ホーム 、ニュースレター 、