2026/04/06 2:27
マイクロソフトは、Petzold以降、統一されたGUI戦略を持っていません。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
マイクロソフトのWindows UIの歴史は、単一で一貫したGUI戦略が確立されることを妨げた断片化された政治的決定によって特徴付けられてきました。
それは1988年にチャールズ・ペツオルドが書いた Programming Windows から始まり、明確なWin16アプローチを提示しました。その後、Win32+Win16への移行でMFC（1992）、OLE/COM/ActiveX、およびその他のコンポーネントモデルが導入されましたが、統一されたフレームワークなしに認知的複雑さを増加させました。PDC 2003ではLonghornがWinFS、Indigo、Avalon（後のWPF）の三本柱を約束しましたが、Windowsチームはその後マネージドコードを放棄し、Windowsと.NETチーム間で13年間にわたる機関的分裂を生み出し、結果としてWPFもSilverlightも孤立させました。
2007年のSilverlightはクロスプラットフォームなリッチクライアントとして宣伝されましたが、静かにWindows Phoneへと方向転換しました。この変更について開発者にはQ&Aでのみ告げられ、ロードマップでは示されませんでした。2012年にWindows 8のMetro/WinRTは.NETやWPFをバイパスするネイティブC++ランタイムを導入し、企業開発者に矛盾したメッセージを送信しました。UWP（Windows 10）は「一度書いてすべてで実行できる」と約束しましたが、サンドボックス化され、ストア専用でありWin32 APIを欠いたため、コアのMicrosoftアプリや広範な開発者コミュニティの関心を引くことはできませんでした。
今日、Windowsには17種類のGUI技術（Win32、MFC、WinForms、WPF、WinUI 3/Windows App SDK、MAUI、Blazor Hybrid、WebView2、Electron、Flutter、Tauri、Qt、React Native for Windows、Avalonia、Uno Platform、Delphi/RAD Studio、Java Swing/JavaFX）が存在し、開発者や企業は高い保守コストを負担せざるを得ず、移行の決定が複雑化し、業界全体の採用速度が遅くなっています。
失敗の繰り返しパターンは内部政治（Windows vs. .NET）、会議で発表される前段階のプラットフォームベット、またはビジネス戦略のピボットに起因しており、開発者を警告なしに置き去りにします。多くのスタックが高い技術品質を持っているにもかかわらず、組織的なミスステップが継続的な採用を阻害しました。最新のUI統一試みであるProject Reunion/WinUI 3も不確実性が残るままで、レガシーの断片化が解消されておらず、UWPに対する明確な代替策が欠けています。
教訓は明白です：成功したGUI戦略には、断片的で会議主導の発表ではなく、採用・投資・保守・移行を含む単一かつ一貫したライフサイクル計画が必要です。
本文
数年前、開発者会議で誰かが簡単な質問を投げました。
「新しい Windows デスクトップアプリに最適なフレームワークは何ですか？」
沈黙の連続。ある人は WPF を推奨し、別の人は WinUI 3 を提案。第三者は Electron だけを使えばいいのではないかと尋ねました。会議は混乱し、その質問に答えることはできませんでした。
この沈黙こそが物語です。そしてその物語は30年以上前まで遡ります。
プラットフォームが「UI をどう構築すればよいか」を10秒以内で回答できないとき、それは開発者への失敗です。終わりです。
Windows が明確な答えを持っていた最後の時
1988 年、チャールズ・ペツオルドが Programming Windows を出版しました。852 ページ。C で書かれた Win16 API。大量に見えるものの、素晴らしい点は単一で統一された「戦略」を提示したことです。
その後登場した Win32 はさらに大きくなりましたが、依然としてメッセージループ・ウィンドウプロシージャ・GDI といった一貫したモデルを提供しました。ペツオルドはそれを説明し、Windows の F=MA（力＝質量×加速度）と呼びました。学んで使えば成功できるという単純で強力なモデルです。
明確さこそが友達です！ 1つの OS、1つの API、1つの言語、1冊の本。マネージドコードの代替案を議論する委員会は存在せず、Win32 とペツオルドだけで十分に機能しました。これは物理学であり化学ではありません――ある条件下でしか通用しないものです。
次に起こったことは、優秀な人材と莫大なリソースを持つ企業が誤った点を最適化して30年にわたる失敗を生み出す方法のマスタークラスでした――素晴らしい人々が愚かな選択をするケースです。
オブジェクト指向の熱狂期（1992–2000）
Win32 の限界は明白だったため、Microsoft は開発者会議で新しいものを披露しました。いくつかあります。
- MFC（1992）― Win32 を C++ でラップしたもの。Win32 が不格好なら MFC は「他のタキシードで作られたタキシード」を着た Win32 です。
- 次に OLE、COM、ActiveX が登場しました――いずれも GUI フレームワークではなく、Windows 開発全体を感染させるコンポーネントアーキテクチャであり、認知的複雑性を増大させました。
1990 年代後半のある会議セッションで OLE ドキュメント、COM オブジェクト、ActiveX コントロールの違いを理解しようとしました。講演者は一時間ずっと「ネズミの尾」が口から垂れ出ているかのように見えました。
Microsoft は統一されたストーリーを売っていたわけではなく、テクノロジープリミティブを提供し、開発者自身に物語を構築させていました。これは「会議キーノート・クラスタ」――エグゼクティブが講演で人々を感動させることに最適化され、ユーザーや開発者の成功は二の次になっていたのです。
PDC 2003 とそれ自身を食べたビジョン
PDC 2003 では Microsoft は Longhorn を公開しました―魅力的な技術ビジョン：WinFS（リレーショナルファイルシステム）、Indigo（統合コミュニケーション）と Avalon（後の WPF）―GPU アクセラレートされた XAML ベースのベクタ UI。開発者は狂喜し、これが正しいビジョンだと感じました。
しかし 2004 年 8 月に Microsoft は完全な開発リセットを宣言し、計画を破棄して Server 2003 のコードベースから再スタートしました。そして静かに指示を出しました：Windows ではマネージドコードは使わない。すべての新規コードは C++ で書くというものです。WPF は Vista と共にリリースされましたが、シェル自体はそれを使用しませんでした。
Windows チームは .NET に対する憎悪を癒すことができませんでした。その視点から見ると、新しいマネージドコードフレームワークへの賭けは会社史上最も恥ずかしい失敗に繋がりました。この憎しみは、Windows と .NET チーム間の13年にわたる機関内の内戦を生み出し、結果として WPF を孤立させ、Silverlight を打ち砕き、UWP を台無しにし、今日私たちが抱える GUI エコシステムのボーフ・アラマをもたらしました。
Silverlight：確立されたパターン（2007–2010）
WPF は 2006 年末にリリースされました。XAML、ハードウェアアクセラレーション描画、実際のデータバインディング――素晴らしいものでした。Microsoft がこれを決定的な答えとして確固たる投資を続けていれば、物語は別の結末を迎えていたかもしれません。しかし 2007 年に Silverlight を発表しました：Flash と競合するブラウザプラグインで、クロスプラットフォーム、エレガントであり、Windows Phone の基盤となりました。
2010 年頃、リッチクライアントの未来のように見えました。しかし MIX 2010 で Microsoft の幹部が Q&A で Silverlight が「クロスプラットフォーム戦略」ではなく「Windows Phone に関するもの」であると告げ、HTML5 が方針となりました。Silverlight チームはこれを知らされていませんでした。Silverlight を使って LOB アプリケーションに賭けた開発者は会議の Q&A で知ることになりました。
Silverlight は技術的な失敗によって終わったわけではありません――テクノロジー自体は十分に良かったです。ビジネス戦略上の決定がそれを終焉させ、開発者が最後に知ることになりました。このパターンを覚えておいてください――また出現します。
メトロ・パニックと二チームの対立（2012）
Apple は 2000 万台以上の iPhone を販売し、iPad が PC 売上を食い止めました。Microsoft の答えは Windows 8 と Metro ―タッチファーストランタイム WinRT で、.NET には依存していませんでした。この時点で Windows チームの憎悪が顕在化します。WinRT はネイティブ C++ ランタイムで、WPF・WinForms や .NET に対する10年間の投資から完全に離れたものです。
Microsoft 内では同時進行で二つのストーリーが語られていました：
- Windows チームは WinRT を構築中。
- .NET チームは WPF のエバンジェリズムを続けている。
異なるビル、異なる VP、異なるロードマップ。Build 2012 で開発者に語られたのは「WinRT が未来だ」「HTML+JS はファーストクラスだ」「.NET はまだ機能する」「C++ は戻ってきた」「Metro アプリを作るべきだ」「WPF コードもそのまま動く」ということでした。これは戦略ではなく、6 チームがあなたの注意を奪い合う Hunger Games の舞台です。
エンタープライズ開発者は UWP のサンドボックス、ストアデプロイメント要件、Win32 API の欠如を見て離れました。モダン時代へ導くために設計されたフレームワークが、実現しなかったタブレット向けアプリストアに最適化されていたのです。
UWP と WinUI の拡散（2015–現在）
Windows 10 で Universal Windows Platform が登場しました――一度書けば PC、電話、Xbox、HoloLens 上で動くというコンセプト。紙上では魅力的でした。しかし Windows Phone は衰退し、Microsoft のフラッグシップアプリ（Office、Visual Studio、シェル自体）は UWP を使用していませんでした。そのメッセージは明確に語られましたが、声としては出ていません。
UWP が停滞すると公式回答は「状況による」になりました。新規アプリには UWP を使う。既存アプリには WPF を残す。XAML Islands でモダン API を追加する。WinUI 3 を待つ。さらに WinUI 2 は UWP 専用です。Project Reunion が全てを解決すると宣言されましたが、実際は Windows App SDK として再命名され、UWP を完全に置き換えることはできませんでした…
素晴らしい人々が愚かな選択をする――テクノロジーのブラウン運動。
Project Reunion / WinUI 3 は本格的な進歩です。しかし問題が存在した理由を自問してください。UWP のコントロールは Windows チームが所有していたため OS に結び付けられました。.NET チームも開発者ツールチームもそれに関与しませんでした。Project Reunion は組織的な回避策であり、技術的解決策のように見せかけたものです。
2024 年に書かれたある開発者のまとめ：「私は Microsoft の継続的な変更を追ってきました：UAP, UWP, C++/CX が C++/WinRT に置き換えられる、XAML Islands, XAML Direct, Project Reunion, WinAppSDK の再起動、WinUI 2.0 と 3.0 の混乱的な切り替え…」十四年。十四回のピボット。彼にはメダルと謝罪が同時に必要です。
看護師のいない動物園
現在 Windows 上で実際にリリースされている GUI テクノロジーは以下の通りです：
Microsoft ネイティブフレームワーク
| フレームワーク | 年 | 備考 |
|---|---|---|
| Win32 | 1985 | 今も存在。Petoldo の本は有効。 |
| MFC | 1992 | Win32 を C++ でラップしたもの。メンテナンスモード。企業・CAD 向けに残存。 |
| WinForms | 2002 | .NET ラッパー。利用可能だが推奨されない。データ入力フォームでは最速。 |
| WPF | 2006 | XAML、DirectX 描画、オープンソース。Microsoft の新規投資は無い。 |
| WinUI 3 / Windows App SDK | 2021 | 「モダン」な回答。ロードマップは不確実。 |
| MAUI | 2022 | Xamarin.Forms のクロスプラットフォーム後継。.NET チームの現在の賭け。 |
Microsoft Web‑Hybrid
- Blazor Hybrid – .NET Razor コンポーネントをネイティブ WebView 内で実行。
- WebView 2 – Chromium を Win32/WinForms/WPF アプリに埋め込む。
サードパーティ
| テクノロジー | 言語 | 備考 |
|---|---|---|
| Electron | JavaScript/Node.js | Chromium + Node.js。VS Code、Slack、Discord などが採用。Windows 上で広く展開。 |
| Flutter (Google) | Dart | カスタムレンダラー、クロスプラットフォーム。 |
| Tauri | Rust バックエンド | 軽量な Electron の代替。 |
| Qt | C++/Python/JavaScript | 真剣なクロスプラットフォームオプション。 |
| React Native for Windows | JavaScript | Facebook のモバイルフレームワークを Microsoft がサポート。 |
| Avalonia | .NET (C#) | WPF の精神的後継者。JetBrains、GitHub、Unity で使用。 |
| Uno Platform | .NET | WinUI API をすべてのプラットフォームに提供。Microsoft よりも WinUI にコミットメントが高い。 |
| Delphi / RAD Studio | Object Pascal | まだ生きている、速い、垂直市場向けソフトウェア。 |
| Java Swing / JavaFX | Java | 生産中で、企業は忘れません。 |
17 のアプローチ。5 つのプログラミング言語。3 つのレンダリング哲学。これはプラットフォームではありません。ボーフ・アラマという用語に辞書的定義がなくても、それを見た瞬間にはわかります。
教訓
すべての GUI イニシアチブの失敗は、次の3つの原因のいずれかに起因します：
- 内部チーム政治（Windows vs. .NET）。
- 開発者会議での早期プラットフォーム賭けを推進する発表（Metro, UWP）。
- 開発者への警告なしに孤立させるビジネス戦略転換（Silverlight）。
これらは技術的失敗ではありません。テクノロジー自体は多くの場合優れていました――WPF は良い、Silverlight は良い、XAML は良い。組織上の失敗が製品を決定づけました。
開発者にとって有効な戦略とは、採用から投資、保守、移行まで全ライフサイクルを網羅する理論であるべきです。そうでない場合は単なる会議キーノートに過ぎません。一方が戦略であり、もう一方は30年にわたるボーフ・アラマです。
チャールズ・ペツオルドは Microsoft が発表するすべての新機能に追いつくために Programming Windows の6版を書きました。彼は第六版で Windows 8 の WinRT をカバーし、2012 年まで続けました。私は彼を責めません。