ハクソク

世界を動かす技術を、日本語で。

マイクロソフトは「Petzold」以来、一貫したGUI戦略を持っていない

50日前原文(jsnover.com)

概要

  • Windowsデスクトップアプリ開発の「正しいフレームワーク」が長年不明瞭な状況
  • かつてはWin32が明確な戦略と答えを提供
  • その後、複雑な政治と戦略の迷走で混乱が続く
  • 技術的失敗ではなく、組織的失敗が根本原因
  • 現在も多様なフレームワークが乱立し、明快な指針がない現状

Windowsデスクトップアプリ開発の混乱史

  • 数年前、 Windowsデスクトップアプリのフレームワーク選定 について開発者間で議論
    • WPF、 WinUI 3、 Electron など意見が分裂
    • 明確な答えが出ず、議論は迷走
  • この沈黙こそが 30年以上続く問題 の象徴

かつての明確な答え「Win32時代」

  • 1988年、 Charles Petzold 著『Programming Windows』が登場
    • Win16 API とC言語による一貫した開発手法
    • 戦略 としての一貫性と明快さ
  • Win32も同様に一つの メンタルモデル で理解可能
  • 「 1 OS、1 API、1言語、1冊の本」というシンプルさ

オブジェクト指向化と複雑化（1992–2000）

  • MFC(1992)、 OLE、 COM、 ActiveX など新技術が次々登場
    • GUIフレームワークではなく コンポーネントアーキテクチャ 中心
    • 認知的複雑性が急増し、 一貫した物語性の喪失
  • Microsoftは 技術要素だけを提供 し、開発者に全体像を委ねる方針

Longhorn（PDC 2003）とビジョンの崩壊

  • Longhorn （WinFS, Indigo, Avalon/WPF）の発表
    • Avalon（WPF） は開発者に高評価
    • しかし開発リセットで .NET排除 の方針へ
    • Windowsチームと.NETチームの対立が激化

Silverlightと繰り返されるパターン（2007–2010）

  • WPF リリース後、 Silverlight （Flash対抗）を投入
    • クロスプラットフォーム戦略のはずが、突然 Windows Phone専用 へ方針転換
    • 技術的失敗ではなく ビジネス戦略の急変 で終了
    • 開発者が最後に知らされる構造

Metroパニックと二重戦争（2012）

  • Windows 8/Metro（WinRT） の登場
    • WinRT はC++ベース、.NETとは断絶
    • Windowsチームと.NETチームが 別々の未来を提示
    • 開発者は混乱し、 UWP の制約や不便さから離脱

UWPとWinUIの混迷（2015–現在）

  • UWP は「書けばどこでも動く」を標榜
    • しかしMicrosoft自社アプリすらUWPを採用せず
    • 公式の答えは「状況次第」「様子見」と曖昧化
    • WinUI 2/3, Project Reunion, Windows App SDK など、名称と戦略が頻繁に変更
    • 開発者は 14年で14回の方向転換 に振り回される

現在のWindows GUIフレームワークの乱立

  • Microsoft純正
    • Win32 （1985）– 依然現役
    • MFC （1992）– 保守モード
    • WinForms （2002）– 利用可能だが推奨されず
    • WPF （2006）– オープンソース化、投資停止
    • WinUI 3 / Windows App SDK （2021）– 現在の「最新」だが将来不透明
    • MAUI （2022）– クロスプラットフォーム指向
  • ハイブリッド/ウェブ系
    • Blazor Hybrid、 WebView2
  • サードパーティ
    • Electron、 Flutter、 Tauri、 Qt、 React Native for Windows、 Avalonia、 Uno Platform、 Delphi/RAD Studio、 Java Swing/JavaFX など多様
  • 17種類のアプローチ、5言語、3つの描画思想 が混在

失敗の本質と教訓

  • 失敗の主因は 内部政治、 カンファレンス主導の拙速な戦略転換、 ビジネス判断による開発者切り捨て
  • 技術自体は優れていても、 組織的失敗 が全てを台無しに
  • 採用・投資・保守・移行 まで見据えた「成功の理論」がなければ、混乱が続くのみ
  • Charles Petzold もWinRT以降、著作を断念

参考リンク

Hackerたちの意見

もしマイクロソフトが成功したGUIフレームワークを次々と出していたら、もっとひどいことになってたと思う。今でもWin32アプリを書くことはできるし、.NETも使える（あのランタイムのダウンロードはマジでウザいけど！）。マイクロソフトは1988年から「ウェブアプリを作ろう」と言ってきたし、AJAXを導入したり、CSSにflexboxやgridを取り入れたり、アプリケーションUIをサポートするHTML5の機能をたくさん追加してきた。npmまで買収したしね！毎日Windowsを使ってるけど、ほとんどWWWやJava、Pythonを使ったクロスプラットフォームのシステムを開発してる。 .NETで開発したのは、SilverlightやUnity/itch.ioのようなクロスプラットフォームのフロントエンドのためだけ。ウェブアプリが作れるのに、ネイティブのWindows GUIアプリを作りたいとは思わないな。自分のコンピュータでやる価値があるなら、Tailscaleを使ってiPadからどこでもやる価値があるんじゃない？現代のJavaScriptに対する不満は多いけど、DXやUXの面で素晴らしい世界を作るための要素は揃ってるし、多くのアプリケーションにはElectronのランタイムを配布する必要もないよ。

└

あなたの投稿は重要な質問に触れてるね：なんでWindows専用のアプリを書くの？私はいくつかのアプリを作って公開した開発者なんだけど、できるだけ多くの人に使ってもらいたいと思ってる。なんでそのアプリをWindowsだけに制限するの？（あるいはどの単一のプラットフォーム/OSにも？）ウェブアプリはどこでも動くし、ウェブはますます強力になってる。なんで一つのOSでしか動かない技術に投資する必要があるの？意味がないよ。ウェブ向けに作ればいいじゃん。PWABuilderを使えば、主要なアプリストア向けにウェブアプリをパッケージできるし、Electronも必要ない。アプリストアから配布されて、ウェブからアクセスできる、速くて軽量なアプリを作ればいいんだ。[0]: https://pwabuilder.com。ちなみに、私はこれに関わってるよ。

スティーブン・シノフスキーが同じトピックについて数週間前に書いた記事があるよ： https://x.com/stevesi/status/2036921223150440542

└

この記事はこれに対する反応なので、上のテキストにリンクを追加するね。ありがとう！

└

Sinofskyが.NETを批判しているのを見るのはとても面白い。彼はWin32やMFCの地獄からWinFormsに開発者が積極的に移行した理由をまだ理解していないみたいだし、Win8のHTML/JSアプリモデルが本当に成功しなかった理由もね。彼がWinRTを推進していたとき、DevDivにいたけど、Windowsの人たちは開発者が本当に何を望んでいるのか全く分かっていなかったという印象が強かった。でも、自分たちのものじゃない地面を焼き尽くすことに必死だった。私のチームはPython/WinRTのサポートのプロトタイピングをしていて、Visual StudioのビジュアルWPFデザイナーまで動くところまで行ってた。JSとは違って、WinRTではC#と同じように何でも使えたし、クラスを拡張することもできた。でも、JSはAPIの「消費者」向けの表面に制限されてた。そのプロトタイプは、Windows（つまり当時のSinofsky）が開発者はJS以外のことに興味がないと思ったから、別の高レベルの言語は必要ないと言ったので、潰された。Windowsが会社のすべてにMetroスタイルを押し付けていた時期でもあって、時には馬鹿げたことまでしてた。例えば、当時のVisual Studioはメインメニューバーをすべて大文字にして、Metroのタブのように見せようとしてたんだ！この「機能」がVS 2012の最初の公開ベータで出荷されたときのブログ投稿やコメントは今でも見られるよ。そして、Windows RT（WinRTとは混同しないでね、Microsoftの製品名の付け方！）。つまり、ARM上のWindowsで、Sinofskyがエコシステムを再起動することが競争する唯一の方法だと決めたために、数十年の後方互換性を捨てたんだ。実際に起こったのは、ユーザーが「何これ？」ってなったこと。彼らのネイティブアプリは、彼の見解とは逆に、実際には生き生きとしていたのに、動かなかったから。開発者も「何これ？」ってなった。なぜなら、また新しいものにすべてを書き直さなければならないと言われたから。Windowsは.NETが大嫌いで、開発者がそれを好んでいることを受け入れられなかったんだ。だからアプリストアは無人の荒れ地になって、アプリがなければユーザーもいなかった。そこにある技術的な詳細のいくつかも完全に間違っている。例えば、.NET 3.0は実際にはVistaで出荷されたのに、彼はWin7で出荷されたと言っているし、消費者向けWindowsで初めて出荷されたのは.NET 1.1がWinXP SP1で出荷されたことなんだ。

Delphiの世界で少し時間を過ごしてたら、2007年頃にWPFにハマったんだ。2010年には、WPFを完全にやめただけじゃなくて、Windows自体も完全にやめてた。MSの一部が政治的な策略を巡らせて、次々と「最新の最高の」技術が18ヶ月以内に無効化されるのを見て、最新の情報を追いかける努力が無駄になったのは本当に辛かった。幸い、その頃Railsが盛り上がってたから、乗り換えるのは簡単だったし、無視することができた。

└

WindowsデスクトップのGUIを書くなら、やっぱりWPFを使うかな。ストックホルム症候群かもしれないけど、結構好きなんだよね。新しいMSのUIフレームワークを使う理由が見当たらない。特に、MS自身があまり使ってないし。私の知る限り、Visual StudioはまだWPFプロジェクトだから、動かなくなることをあまり心配してないよ。

└

マイクロソフトには素晴らしい才能がたくさんいたけど、リーダーシップと一貫したビジョンが欠けてたんだ。今のビッグテックの問題をすべて予見してたよ。

└

でも、VBはまだ動いてるし、いつも rug pull するわけじゃないよね。

問題は、Win32の後に2年以上何かにコミットできなかったことだ。WinRTにはそれなりに良いものがあったのに、それを続けるべきだった。でもナデラが来て、Azure Cloudが未来だと言ってWindowsプラットフォームを放棄しちゃったんだ。

└

ここで一つ考えなきゃいけないのは、Microsoftはまだソフトウェアプラットフォーム企業なのかってこと。彼らの製品がエコシステムを形成して、プラットフォームのユーザーにとって一貫したソフトウェア環境を提供できるのかどうか。Microsoftは昔はWindowsの会社だった（その前はBASICの会社、次はDOSの会社）。それからOfficeの会社になった。今はSharePointやOffice365、Azure、つまりユーティリティだね。Windowsは比較的小さい部分になっちゃった。Officeはデスクトップとウェブ両方（宇宙船でも、Outlookのバージョンが2つあって、どっちも動かないけど）。ここまで来ると、何がMicrosoftなのか分からなくなるよね。Satya NadellaがMicrosoftのビジョンを知っているなら、ちゃんと伝えてないと思う。Azureだけじゃないし、OfficeやWindowsもあるし、オンプレミスのサーバー製品やハードウェア製品もある。ストアも（まだあるのかな？）。

└

WinRTは技術的にひどかったよ（「マイクロソフトの誰も実際に役立つものを作ってなかった」ってのがそのまま出てる）。でも、それが沈没の原因じゃなくて、「もちろんあなたのWinRTアプリはMicrosoft Store^TMに入るのが未来だから」っていう要件がそれを決定づけた。あのクソストアは冗談みたいなもので、その要件はただ内部のバカどもを持ち上げるためだけに存在してた。

「彼らの視点から見ると、新しいマネージドコードフレームワークに賭けることは、会社の歴史の中で最も恥ずかしい失敗を生んだ」 会社の歴史の中で最も恥ずかしい失敗だよ。

ChatGPTが爆発的に広がって、Bingがそれを統合したとき、アイデアは素晴らしかった。ChatGPTとは違って、ウェブにアクセスできるから情報のカットオフがなかったからね。Googleを捨ててAIチャットに移行するのが楽しみだった。でも、MSは実際にどう実装したの？数回のメッセージの後、チャットがブロックされちゃった。MSがもう少し頑張って、コンテキストをコンパクトにして、製品が実際に使えるようにすればよかったのに。もちろん、OpenAIやPerplexityなどはその後、ちゃんと実装して、現代のAIチャットの重要な部分になった。私はほとんどGoogleを捨てたよ。もしMicrosoftがそれをやっていれば、Googleに取って代わるチャンスがあったかもしれないのに。でも、Microsoftは素晴らしいUXを提供するための考え抜かれたUIを持てない。私の意見では、これは文化の問題だと思う。まとまりがないのはその結果で、Appleがアプリと一緒に自社のUIライブラリを出荷できないことにイライラしてたけど、Appleは正しかった。制限のおかげでUIは一貫性があるんだ。

ここには、Microsoftの幹部とのディナーについて何度も投稿している人がいるけど、Microsoftがエンタープライズに全力投球だと言われたらしい。あのコピペがここに来るのを待ってるよ。Microsoftは本当に足を引っ張ることばかりしてるから、エンタープライズも今後彼らと一緒に進むのをためらうかもしれないね。[0] Netcraftの数字は手元にないけど、エンタープライズ向けに戦略をシフトしても、Windowsを無意味に貶めるようなことをしているから、状況が大きく改善されたとは思えない。個人的にはFOSSが強くなってるのは嬉しいけど、それは別の話。[0] Azureで痛い目にあったし、他の多くの企業もそうだと思うけど、彼らは状況を改善するために何もしてくれなかった。SLAなんてどうでもいい。今のところ、私たちの戦略はMicrosoftやWindowsの技術に依存しないこと。最近、Active Directoryからも移行したところだよ。BingやEdgeなんて、正直どうでもいい。

└

Microsoftはエンタープライズに集中しすぎて、エンタープライズが個々のユーザーで構成されていることを忘れちゃった。ユーザーを犠牲にしてエンタープライズを優先するトレードオフは、長期的には誰にも利益をもたらさない。

レドモンドには、開発製品を理解しようとしたPatterns & Practicesグループ（P&P）もあった。彼らは「顧客に使い方を示す」ために追加のライブラリを作ってた。彼らは主要な開発チームからのフレームワークリリースの動きを追っていた。つまり、主要製品の使い方がはっきりしていなかったから、P&Pが「こうやってみて」と言ったんだと思う。この記事は、ウェブ時代のMSについてあまり触れていなかったと思う。私の意見では、会社はウェブ開発を生き延びたけど、リーダーではなかったね。

Windowsのフレームワークはウェブに嫉妬してるみたいだね。Xamlやスタイリングとか色々試して競おうとしてるけど、問題はデスクトップ開発が難しくなったこと。ウェブには勝てなかったし、デザイナーの遊び場になっちゃった。デザイナーたちはウェブの方が好きだしね。ウェブ用に何か作れば、Electronでパッケージして安くクロスプラットフォームにできるし。

未来のUI戦略はHTMLになるかもしれないね。広く普及してて、標準化されてて、十分にパフォーマンスも良いし、かなりリッチだ。ただ、まだ欠けてるのはネイティブOSの概念やJS以外のプログラミング言語との深い統合だね。Electronみたいなフレームワークはその方向に進んでるけど、いくつかの大きな欠点もある。アプリは、複数のOSレベルのウィンドウを管理するような自然なことに苦労することが多いし、もう一つの厄介な点は、Electronアプリが大きな部分のChromiumを繰り返しバンドルするから、余計なオーバーヘッドが発生すること。重複したモジュールが原因でRAMの使用量が膨れ上がるし、各アプリが自分のChromiumコピーを持ってて、OSはそれをRAMに保持し続けなきゃいけないから、共有可能な部分を再利用することができない。

└

それを10年以上聞いてるけど、実現しそうにないね。

└

HTMLとCSSは、普通のデスクトップやアプリのフレームワークに比べて、実際に何か役立つことやインタラクティブなことをするのが信じられないくらい難しいよ。何倍も多くの面倒くささ、配管、ぎこちなさ、頭を抱えることがある。

└

正確には同じじゃないけど、マイクロソフトが30年前にこれを出荷したのは早すぎたってことは言えるね（1997年のアクティブデスクトップはWindowsエクスプローラーとInternet Explorerを統合して、フォルダーをウェブページに変えたんだ）。