WPF, Modern App (Metro App), UWP がiPentec内の採用で低迷した理由を紹介します。

概要

Windowsデスクトップアプリケーション開発では、もともとはVisual C++ が提供されており、C++でWindows APIを直接呼び出してアプリケーションを実装するか、 MFCを利用してアプリケーションを実装する方法がありました。 その後、Visual Basic (2.0)が登場し、ウィンドウにボタンやテキストボックスを配置してアプリケーションを開発するビジュアル開発が提供され、 アプリケーションも開発しやすく、大きく普及しました。同時期にDelphi, C++ Builder, Power Builder などのMicrosoft 以外のビジュアル開発ツールも提供されました。

ビジュアル開発が浸透したころ、Visual Basic 2.0のランタイムアプリケーションでは動作速度が遅いことや、ネイティブのAPIコールがしづらいといった点から、 新しいプラットフォームである。.NET Framework が提供され、UIフレームワークとして Windows Formsが登場しました。 また、同時期に新しい言語の「C#」が提供されました。
当初の.NET Frameworkはネイティブアプリケーションと比較して、動作が遅くパフォーマンス面でネイティブアプリが有利でしたが、CPUの動作速度上昇や .NET Frameworkのバージョンアップにより、2008年ごろにはネイティブアプリケーションと比較してもまずまずのパフォーマンスとなりました。

同時期にWindows Presentation Foundation(WPF)が登場し、高度なグラフィック機能が扱えるようになり、 その後にはWindows 8が登場し、Modern App (Metro UI)アプリケーション、Windows 10の登場によりUWPアプリケーションのUIフレームワークが提供されています。 年を追うごとに、新しいフレームワークが登場していましたが、現在のところ、メインで利用しているのは相変わらず、.NET Framework のWindows Formsがメインとなっています。 いろいろなフレームワークが出ているのに、古い.NET Framework のWindows Formsが相変わらず採用されているかの理由を紹介しつつ、 新しいフレームワークの採用に至らなかった理由を紹介します。

C/C++ Windows API呼び出し

Windows登場時から提供されている C/C++による、Windows APIを呼び出す方法でのアプリケーション開発です。 この方式はUIフレームワークはほとんどなく、APIを呼び出しウィンドウを作成していく方法です。メッセージループなどの基本的なUIフレームワークはあります。
この方法でアプリケーションの作成はできますが、複数のウィンドウコントロールがあり、ある程度デザインにこだわったウィンドウを作成する場合、 ビジュアルデザイナがなく、すべてコードベースで画面デザインを実装する必要があり、画面をデザインする労力が大きいです。
また、画面デザインの結果もビルドして実行してアプリケーションの画面を確認する必要があります。 当時のC/C++(Visual C++ version 2.0 - 1995年ごろ)のビルド速度は遅く、時間もかかるため、繰り返し修正をして画面デザインを確認する作業は非効率でした。 Windows NT 3.5の動作も遅いことがさらに負担を大きくしていました。
UIの画面デザインの労力が大きいことから、一部のアプリケーションで採用しましたが、主流の開発環境としては採用されませんでした。

メリット

• フレームワークがないため、理解がしやすい
• ランタイム配布が必要だが、標準でインストールされている場合も多い

デメリット

• 画面デザインが大変
• ビルドに時間がかかる

Microsoft Foundation Class (MFC)

Visual C++の登場とともに提供されたフレームワークです。
WindowsのUIコントロールなどがライブラリ化されて、より簡単にWindowsアプリケーションを開発できるフレームワークです。
MFCではDocument-View構造という考えに基づいてフレームワークが設計されています。 Document-View構造はSmallTalkの考えに基づいた仕組みであり、理解が難解な仕組みです。

このため、小規模なアプリケーションであっても、入念な設計が必要であり、 ベースのコード(最近では、ボイラープレートとも呼ばれます)が多く、手軽にアプリケーションが作成できるフレームワークではなく、Document-View構造の難解さもあり、 iPentecではほとんど使われることはありませんでした。
市販のアプリでもWindows APIを直接呼び出す方式で実装しているものも多く、MFCを利用していないアプリケーションも比較的多いです。 (mfc42.dll が不要で動作するアプリケーションはWindows APIの直接呼出しによる実装だと考えてよいです。)

また、MFCのライブラリ自体はクラスを利用した クラスライブラリになっており、Standard Template Library(STL)/Active Template Library (ATL) の書式を利用して アクセスすることが基本になるため、C/C++に加えてSTL/ATLの理解も必要になり、 開発の敷居が高く、学習に時間を要する点もデメリットとして挙げられます。

また、UIのコントロールがクラスライブラリとして提供されているものの、画面のデザインはコードベースで実装する必要があり、 画面デザインに関しては、Windows APIを直接呼び出す方法と比べて大きな改善はありません。 一方で、リボンUI、スマートドッキングウィンドウなどの新しいバージョンのWindowsで導入された機能がいち早くライブラリとして 提供されるメリットはあります。

メリット

• 先進的なWindowsのUI機能が利用できる (リボンUI、スマートドッキングウィンドウ)

デメリット

• パーツは用意されているものの、画面デザインが大変
• フレームワークで採用されている、Document-View構造の理解が難解
• STLを利用するため、C/C++ 以外にSTLの理解も必要
• ビルドにとても時間がかかる
• ランタイム配布が必要 (MFC42.dll など)

Visual Basic (VB 2.0～6.0)

Visual Basicの登場により、ビジュアルデザイナーが提供され、ウィンドウのデザインやメニューのデザインが格段に容易になりました。 サウンド再生やOLE関係の機能もコントロールとして提供され、複雑なコードを記述せずにアプリケーションを実装できるようになりました。 iPentecでも数多くのツールやアプリケーション作成で利用していました。
生産性も高く良い開発環境ですが、Visual Basicのランタイムを必要とする関係で、ネイティブアプリケーションより動作が遅い点が問題になってきます。 また、凝った処理をすると、Windows APIを呼び出すケースが必要になります。Visual Basic ではWindows APIのあるDLLを指定して、Declare宣言をすれば、 Windows APIを呼び出せますが、Visual Basicにはポインタの概念がないことや型の違いもあり、呼び出しが難しい問題があります。 また、呼び出すAPIごとにDeclare宣言をする必要もあります。
OCXのインポートにより、OLEコントロールやActiveXコントロールをフォームに配置できますが、型の違いや開発環境の違いでうまく扱えないこともあり、完全な互換性が ないコントロールもあります。
このような理由から、1996年ごろから徐々にDelphiに開発環境が移っていくことになりました。

メリット

• ビジュアルデザイナの導入によりデザインの生産性が大幅に向上

デメリット

• 動作速度が遅い
• Visual Baicの仕組みにない処理を実装する場合は Windows APIの呼び出しが必要
• Windows APIの呼び出しが大変 (C/C++との型の違い、Declare宣言の記述)
• ランタイム配布が必要 (VBRJP200.DLL, msvbvm60.dll など)
• コードファイルを見通せない(VB2)
• クラスの概念がないため、規模が大きくなるとコード管理が大変

Java (AWT)

1995年ごろのJavaでGUIアプリケーションを作成するフレームワークです。当時のJavaは実行も開発環境も非常に重く、 試してはみたものの、パフォーマンス面で実用に耐えず採用にはなりませんでした。
(当時の最速CPUはPentium 100Mhz程度のため、SPARCやSGIワークステーションであれば、もっと快適に動作したのかもしれません。)

Java (Applet)

1995年ごろのJavaでWebアプリケーションを作成するフレームワークです。こちらも非常に動作が遅く、採用にはなりませんでした。

Delphi (1.0 ～ 7.0)

Visual Basicの動作速度の遅さやWindows APIの呼び出しにくさ、クラスの概念の導入、ネイティブアプリのビルドによりランタイム不要など、 Visual Basicの欠点を解消した開発環境です。
ビジュアルデザイナもあり、当時は Visual Basicからの乗り換えも多かったです。欠点の少ない開発環境でしたが、Microsoftの開発環境でないため、 新しいWindowsが登場してから、新機能が使えるようになるまでの期間が長くなってしまうことがデメリットでした。 また、新バージョンのリリース直後は開発環境の安定性が低く、開発環境ごとクラッシュしてしまうこともありました。

クラス、ポインタも利用できますが、言語の書式がPascalという点も好みがわかれる点で、ブロックのbegin end の記述や代入の := 比較演算の = など C/C++ になじみがあるほど受け入れにくいというデメリットもあります。
こうしたことから、後発で、Delphiと同様の開発環境で C/C++ の書式で記述できる C++ Builder も登場します。

一時期はWindowsの開発環境を席巻し、iPentecでも多くのアプリケーションを作成しましたが、.NET Framework の登場やWebアプリケーションへの移行に伴い、 徐々に採用が減り、開発環境の値上げとサブスクリプション化に伴い、開発環境を維持できなくなり、採用はほぼなくなりました。
(旧バージョンやCommunity Editionでのメンテナンスはあり)

メリット

• クラスが利用可能、オブジェクト指向
• ランタイムが不要
• UI部品のコンポーネント化に対応
• 単一exeファイルにビルドできる
• ビルドが高速
• Windows APIの呼び出しも容易

デメリット

• 新しいWindowsが登場しても新機能が利用できるまでの期間が長い (年を追うごとに期間が長くなる)
• Pascalの書式の好き嫌い
• .NET Framework / XAML / GDI+ の対応で右往左往
• Webアプリケーション開発はできない (ActiveX Formを利用してWebアプリを作成できた時期もあり)
• Community Editionが遅延してリリースされる
• (現在は)情報が少ない
• (現在は)価格が高い

C# (.NET Framework / Windows Forms)

2002年に.NET Framework の登場、Visual Studio .NETの登場とともに、提供された新しい言語です。 クラスの概念があり、オブジェクト指向の言語です。ポインタの概念は隠されており、unsafeで明示的に指定しない限りは使えず、 どちらかというとVisual Basicに近い仕組みでした。
当初は動作速度も遅く、できることも限られていましたが、年を追うごとに言語の拡張、.NET Framework の改良、Windows Formsの新しいコントロールの追加が 進み、パフォーマンスも改善され、2008年ごろにはC/C++のアプリケーションと比較しても問題ない速度で動作し、 実用的なアプリケーションでも利用可能になりました。
また、Webアプリケーション開発にも対応し、.NET Framewok による、Web Formsアプリケーションもできるようになりました。
長い間提供されているフレームワークのため、動作対象のWindowsが多いこともメリットです。また、.NET Frameworkがプリインストールされていることも多く、 .NET Frameworkをダウングレードすることで、ランタイム配布不要でアプリケーションを動作させることもできます。 .NET Frameworkのランタイムのインストールが(管理権限が無いといった理由で)できない場合に、プリインされている.NET Frameworkのバージョンまでダウングレードして アプリケーションを実行できるようにするといったケースもありました。

2022年時点でもWindows Formsはメインのアプリケーションフレームワークとして採用しています。 (現在は、.NET Framework のWindows Formsから.NET 6のWindows Formへの移行時期です。)

メリット

• クラスが利用可能、オブジェクト指向
• ランタイムは必要だが、配布がわかりやすい
• ビルドが高速
• Windows APIの呼び出しもそこそこ簡単
• C/C++に似た書式
• 動作速度も2008年以降は問題ない程度に高速
• Webアプリケーション開発と同じ言語が利用可能
• 情報が多い
• 提供期間が長いため、動作するWindowsのバージョンが多い

デメリット

• (2022年時点では)UIのデザインが古めかしい
• 最近のWindowsの新機能に対応していない

C# (.NET Framework / ASP.NET Web Forms)

C#でWebアプリケーションを開発できる仕組みです。
Windows Formと同じ考え方でWebアプリケーションを開発できるため、敷居が低く、開発しやすいです。 実行環境はWindows ServerのIISのみとなりますが、比較的簡単に配置でき、アプリケーションのパフォーマンスも良いです。

とっつきやすさもあり、生産性も高いフレームワークですが、Webの仕組みを無理にWindows Formsに合わせている部分もあり、 ポストバックの考え方を学習する必要があります。
また、登場当時はCSSやJavaScirptが2010年代ほど普及していなかったこともあり、Web Formのデザイナと実行画面が比較的同じデザインで表示できましたが、 2010年代後半になるとデザインは、ほぼCSSで定義するスタイルが主流になり、Web Formのデザイナと実行画面のデザインが全く対応していないという状況になってしまいました。

また、複雑なアプリを作成すると、最終的にはLiteralコントロールに対して、すべてタグを出力する構造になってしまい、 用意されている Web Formのコントロールを使わなくなってしまうケースもあります。
さらに、Web Formの実行URLは http://..../index.aspx の形式となり拡張子が見えるのが通常の設定です。 2000年代初めでは、*.cgi *.pl のように拡張子が見えるURLは一般的でしたが、2010年代にはいると、Webアプリケーションでは拡張子を見せない構造が主流になってきます。 Web Formの場合は、aspxファイルに対してアプリケーションルーティングをかぶせる方式で対応できますが、別途ルーティングのロジックを実装する必要があり、 実装がやや面倒で複雑になりがちです。

こうしたことから、最近では、Web FormからASP.NET MVC や Razor Pages、Blazorへの移行も徐々に進んでいますが、 Windows Formに慣れているほど、Web Formの開発はしやすいため、まだまだWeb Formのアプリケーション開発も多いのではないかと思います。
iPentecでは、新規開発はASP.NET Core Razor Pagesを採用、既存のアプリのメンテナンスはWeb Form継続で利用しています。

メリット

• C#でWebアプリケーションが開発可能
• Windows Formの開発に慣れていると直感的に理解しやすい

デメリット

• ポストバックなどフレームワークに癖がある、ポストバックの概念の理解が必要
• 拡張子なしのアプリケーション専用URLをマッピングする場合は、ルーティングの実装が別途必要
• デザインがCSSで定義されていると、Web Formデザイナと実行時画面のデザインがまったく一致しない
• アプリケーションの作りこみが進むと、Web Formのコントロールではなく、LiteralコントロールにHTMLタグを出力する構造になってしまう。
• JavaScriptとの連動が若干めんどう

C# (.NET Framework / Windows Presentation Foundation(WPF))

2006年に.NET Framework 3.0が登場し、Windows Vistaが登場したタイミングで新しいフレームワークWindows Presentation Foundation(WPF)が提供されました。
グラフィックスに関する機能が大幅に強化され、表現力も上がり、Direct3Dを利用して高速に画面の描画もできます。 アプリケーションの設計もビジュアルデザイナを利用してXAMLと呼ばれるXMLで記述できます。
表現力も上がり、非常に良さそうですが、いくつかのデメリットのため、実運用アプリでの採用とはなりませんでした。
デメリットで最も大きかったのはアプリケーション起動時の遅さと、全体的なパフォーマンスが良好ではなかった点です。 提供当初からも動作速度が遅く、その後CPUの性能や.NET Framework 自体のバージョンアップもあったのですが、Windows Formsと比較した際の パフォーマンスの違いは大きく、WPFへの移行は進みませんでした。
また、UIへの表示はバインディングを基本としているため、概念が違う点もありました。バインディングについては、使わずに Windows Formと同様の実装にすることも可能ですので、それほど大きな障害ではありませんでした。

結局、パフォーマンスの問題と、WPFに移行してもできることはあまり変わらないという点で、移行は進みませんでした。
アプリケーションの動作が遅いため、一部のプログラムではUXが悪く、WPFで実装したものをWindows Formに移植しなおすこともありました。

メリット

• XAMLによるデザインのコード化
• Direct3Dによるグラフィックス表現の高度化、パフォーマンス向上

デメリット

• とにかく遅い(特にアプリケーションの起動時) ※ただし、2022年時点ではあまり違いを感じない
• バインディング前提のUI設計のため移行しにくい (バインディングを使わないこともできる)
• リッチな表現ができても、デザインにこだわるアプリが少ないため、移行してもメリットがない
• 情報が少ない

C# (.NET Framework / Modern App / Metro App)

Windows 8登場のタイミングで新しいMetro Appが登場しました。Windows 8の新しい全画面スタートメニューから起動し、 全画面で表示されるアプリケーションです。そもそもPCで全画面表示アプリケーションが流行るのかと疑問でしたが、 懸念通り流行らずに衰退となりました。
Microsoft Storeで配布することが前提となっており、配布はappxパッケージであり、appxパッケージをシステムにインストールして 利用する仕組みです。インストールはMicrosoft Storeからのインストールになり、 ストア経由でない場合は、開発者モードにする必要があります。appxの署名等の作業も必要です。
また、セキュリティ面も強化されており、ローカルリソースへの制限(ローカルファイルへのアクセスなど)もありました。

全画面での起動や、配布の敷居が非常に高く、ローカルリソースの制限もあるため内製ツールのフレームワークとしては使えず、 動作環境もWindows 8以降とのことで、ほぼ使うことはありませんでした。
その後、ウィンドウ起動ができるようになりましたが、配布の難しさのため採用はありませんでした。

メリット

• Windows 8の新機能が利用可能 (通知など)
• モダンなデザイン

デメリット

• 配布の敷居が高い (appxでの配布、署名)
• 実行するにはアプリケーションのインストールが必要 (ストア経由でない場合は開発者モードにする必要あり)
• ローカルリソースへのアクセス制限あり
• Windows 8以降が必要
• 全画面での起動 (のちにウィンドウ起動も対応)

C# (.NET Framework / Universal Windows Platform (UWP))

Windows 10登場のタイミングで提供された新しいUIフレームワークです。
様々なデバイス上で動作するアプリケーションを単一のフレームワークで作成可能なフレームワークですが、 クロスプラットフォームが流行った歴史はないため、クロスプラットフォームはメリットとしては感じられず、 どちらかというと、Modern Appの進化系というとらえ方でした。

(同じ言語で複数のプラットフォームのアプリケーションを作成できるという意味でのマルチプラットフォームはあると考えていますが、 同一コードベースで複数のプラットフォームに対応できる仕組みは幻想だという立場です。デバイスやOSごとにUIパーツとその挙動は異なるため、 プラットフォームのUIパフォーマンスを最大限活用する場合は、プラットフォームに適したUIを設計、実装する必要があると考えています。 ゲームなどすべてのUIパーツが独自に実装されOSやプラットフォームに依存していない場合は、UIのマルチプラットフォーム対応はできると思います。)

配布形式はappxでの配布となり、アプリケーションの実行には、配布パッケージのシステムへのインストールが必要になり、 簡易な配布はできず、配布の敷居は高いままです。
また、ファイルアクセス等のロジックも.NET Framework とは異なる仕組みでのアクセスとなり、移植のコストが高い点も懸念でした。
appx形式の時点で内部ツールとしての採用はなく、Microsoft Storeでの配布するアプリケーションも無いことから採用はありませんでした。

メリット

• 様々なデバイス上で動作するアプリケーションを単一のフレームワークで作成可能

デメリット

• 配布の敷居が高い (appxでの配布、署名)
• 実行するにはアプリケーションのインストールが必要 (ストア経由でない場合は開発者モードにする必要あり)
• ローカルリソースへのアクセスは Modern App の流れを受けついでいるため使い勝手が悪い
• Windows 10以降が必要

C# (.NET 5,6,7 / ASP.NET MVC)

Model View Controller （MVC）パターンでWebアプリケーションを開発するフレームワークです。
こちらもiPentecでは採用事例は少ないです。大規模なアプリケーション作成には向いていますが、 小規模なアプリではフレームワークの手続きが重く、生産性やコードの見通しが良くないといった点があります。
小規模なWebアプリの開発が多いiPentecでは採用したプロジェクトはありませんでした。

メリット

• MVCモデルで開発可能
• Web Formの問題点を解消している
• 大規模アプリケーション、チームでの開発に適している
• 情報が比較的多い

デメリット

• フレームワークに沿った実装が大変

C# (.NET 5,6,7 / ASP.NET RazorPages)

ASP.NET MVCのビューエンジンのRazorPagesのみを利用するフレームワークです。こちらの場合はMVVMモデルになります。
小規模なアプリケーションの実装が容易です。ある程度の自由度があるため使いやすいです。iPentecでもWebアプリで採用しています。

メリット

• Web Formの問題点を解消している
• 小規模なアプリケーションを開発しやすい

デメリット

• 情報が少ない
• 自由度が高いため、UIのロジックと、データ処理ロジックを混ぜてしまいがち

C# (.NET 5,6,7 / ASP.NET Blazor)

シングルページアプリケーション（SPA）を開発するためのフレームワークです。
AJAXと同様のページ遷移のないWebアプリケーションを開発できます。
iPentecでもいくつかのWebアプリで採用しています。

メリット

• Web FormでUpdatePanelを利用するより簡単に実装できる
• フレームワークの構造も理解しやすい (RazorPagesに似ている)

デメリット

• 情報が少ない
• 採用実績が少なそう

C# (.NET 5,6,7 / Windows Form)

Windows Formは .NET Frameworkで実装されていましたが、マルチプラットフォームに対応した .NET Coreが登場し、その後.NET 5になりました。 新しい.NET 5に対応した Windows Formも提供されています。
こちらは、.NET Framework の Windows Formとほぼ同じ使用感で移行できるため、.NET Framework にあり、.NET 5,6,7 にない機能を使用していない限りは 比較的容易に移行できると思います。iPentecでも新規開発は .NET 6の Windows Formを利用しています。

.NET Remoting, System.EnterpriseServices, Workflow Foundation, System.Reflection.Emit, 複数モジュールのアセンブリの読み込み, XSLT スクリプト ブロック などがサポートされていませんが、あまり使わない機能なので大きな影響は出ていません。

メリット

• .NET Framework の Windows Formと同様、移植、移行も容易
• ビジュアルデザイナもある

デメリット

• UIのデザインは従来通り
• できることは.NET Framework と変わらない (新鮮味がない)
• .NET Frameworkにあり、.NET 6/7 にない機能の場合は移植が大変
• .NET 5 / .NET 6 / .NET Core 3 はプリインストールされていないPCが多いため、ランタイムのインストールが必要なことが多い

C# (.NET 5,6,7 / Windows App SDK / WinUI 3)

Windows 10, Windows 11 のデスクトップアプリを作成するためのフレームワークです。
当初はProject Reunion と呼ばれており、Modern App, UWPをWin32アプリに再統合するというプロジェクト計画でした。

基本はWin32アプリケーションのため、Windows Formから違和感なく移行できそうです。
Unpackaged形式の出力も可能で、自己完結型のアプリケーションをビルドすればランタイムの配布に関する問題も解消できそうです。
現時点ではビジュアルデザイナーが無いためWindows Formsの開発からの移行が増えるにはビジュアルデザイナーの提供が必要な気がします。 逆にASP.NETでのWebアプリ開発に慣れている場合は、Webアプリではビジュアルデザイナーを使用することは少ないため、WinUI 3のXAMLのコードデザインも 比較的受け入れやすいのではないかと思われます。
iPentecではまだ、採用はありませんが、これから検証していく予定です。

メリット

• 最新のWindowsのUIコントロールのデザインが利用できる
• 基本はWin32アプリケーションのため、Windows Formからの移行が容易
• exeファイルでの配布が可能(Unpackaged 自己完結型デプロイ)

デメリット

• 現時点ではXAMLのビジュアルデザイナーがない
• 登場したばかりなので将来性が未知数

今後

WinUI 3/Windows App SDK は長らく停滞していた Windows Formアプリケーションの移行先としてありになるかもしれません。 逆に、Windows Formアプリケーションに WinUI 3 コントロールを導入するブリッジの提供があるのかもしれません。
とはいえ、デザインはXAMLベースに移行したほうが後々良さそうな印象ですので、長い目で見ると、XAMLベースのWinUI 3になっていく気がします。

Webアプリはしばらくは、WebFormとASP.NET MVCの並走状態になりそうな印象です。RazorPagesは情報が少ないこともあり、 採用数や採用事例はゆっくり増えていくのではないかと思います・
Pythonなどもありますが、Windows実行環境では、実用のWebアプリやデスクトップアプリケーションは 言語的な堅牢さがあるC#が引き続き多いのではないかと思われます。(またはVB)