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が相変わらず採用されているかの理由を紹介しつつ、
新しいフレームワークの採用に至らなかった理由を紹介します。
Windows登場時から提供されている C/C++による、Windows APIを呼び出す方法でのアプリケーション開発です。
この方式はUIフレームワークはほとんどなく、APIを呼び出しウィンドウを作成していく方法です。メッセージループなどの基本的なUIフレームワークはあります。
この方法でアプリケーションの作成はできますが、複数のウィンドウコントロールがあり、ある程度デザインにこだわったウィンドウを作成する場合、
ビジュアルデザイナがなく、すべてコードベースで画面デザインを実装する必要があり、画面をデザインする労力が大きいです。
また、画面デザインの結果もビルドして実行してアプリケーションの画面を確認する必要があります。
当時のC/C++(Visual C++ version 2.0 - 1995年ごろ)のビルド速度は遅く、時間もかかるため、繰り返し修正をして画面デザインを確認する作業は非効率でした。
Windows NT 3.5の動作も遅いことがさらに負担を大きくしていました。
UIの画面デザインの労力が大きいことから、一部のアプリケーションで採用しましたが、主流の開発環境としては採用されませんでした。
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で導入された機能がいち早くライブラリとして
提供されるメリットはあります。
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に開発環境が移っていくことになりました。
1995年ごろのJavaでGUIアプリケーションを作成するフレームワークです。当時のJavaは実行も開発環境も非常に重く、
試してはみたものの、パフォーマンス面で実用に耐えず採用にはなりませんでした。
(当時の最速CPUはPentium 100Mhz程度のため、SPARCやSGIワークステーションであれば、もっと快適に動作したのかもしれません。)
1995年ごろのJavaでWebアプリケーションを作成するフレームワークです。こちらも非常に動作が遅く、採用にはなりませんでした。
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でのメンテナンスはあり)
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への移行時期です。)
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継続で利用しています。
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に移植しなおすこともありました。
Windows 8登場のタイミングで新しいMetro Appが登場しました。Windows 8の新しい全画面スタートメニューから起動し、
全画面で表示されるアプリケーションです。そもそもPCで全画面表示アプリケーションが流行るのかと疑問でしたが、
懸念通り流行らずに衰退となりました。
Microsoft Storeで配布することが前提となっており、配布はappxパッケージであり、appxパッケージをシステムにインストールして
利用する仕組みです。インストールはMicrosoft Storeからのインストールになり、
ストア経由でない場合は、開発者モードにする必要があります。appxの署名等の作業も必要です。
また、セキュリティ面も強化されており、ローカルリソースへの制限(ローカルファイルへのアクセスなど)もありました。
全画面での起動や、配布の敷居が非常に高く、ローカルリソースの制限もあるため内製ツールのフレームワークとしては使えず、
動作環境もWindows 8以降とのことで、ほぼ使うことはありませんでした。
その後、ウィンドウ起動ができるようになりましたが、配布の難しさのため採用はありませんでした。
Windows 10登場のタイミングで提供された新しいUIフレームワークです。
様々なデバイス上で動作するアプリケーションを単一のフレームワークで作成可能なフレームワークですが、
クロスプラットフォームが流行った歴史はないため、クロスプラットフォームはメリットとしては感じられず、
どちらかというと、Modern Appの進化系というとらえ方でした。
(同じ言語で複数のプラットフォームのアプリケーションを作成できるという意味でのマルチプラットフォームはあると考えていますが、
同一コードベースで複数のプラットフォームに対応できる仕組みは幻想だという立場です。デバイスやOSごとにUIパーツとその挙動は異なるため、
プラットフォームのUIパフォーマンスを最大限活用する場合は、プラットフォームに適したUIを設計、実装する必要があると考えています。
ゲームなどすべてのUIパーツが独自に実装されOSやプラットフォームに依存していない場合は、UIのマルチプラットフォーム対応はできると思います。)
配布形式はappxでの配布となり、アプリケーションの実行には、配布パッケージのシステムへのインストールが必要になり、
簡易な配布はできず、配布の敷居は高いままです。
また、ファイルアクセス等のロジックも.NET Framework とは異なる仕組みでのアクセスとなり、移植のコストが高い点も懸念でした。
appx形式の時点で内部ツールとしての採用はなく、Microsoft Storeでの配布するアプリケーションも無いことから採用はありませんでした。
Model View Controller （MVC）パターンでWebアプリケーションを開発するフレームワークです。
こちらもiPentecでは採用事例は少ないです。大規模なアプリケーション作成には向いていますが、
小規模なアプリではフレームワークの手続きが重く、生産性やコードの見通しが良くないといった点があります。
小規模なWebアプリの開発が多いiPentecでは採用したプロジェクトはありませんでした。
ASP.NET MVCのビューエンジンのRazorPagesのみを利用するフレームワークです。こちらの場合はMVVMモデルになります。
小規模なアプリケーションの実装が容易です。ある程度の自由度があるため使いやすいです。iPentecでもWebアプリで採用しています。
シングルページアプリケーション（SPA）を開発するためのフレームワークです。
AJAXと同様のページ遷移のないWebアプリケーションを開発できます。
iPentecでもいくつかのWebアプリで採用しています。
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 スクリプト ブロック
などがサポートされていませんが、あまり使わない機能なので大きな影響は出ていません。
Windows 10, Windows 11 のデスクトップアプリを作成するためのフレームワークです。
当初はProject Reunion と呼ばれており、Modern App, UWPをWin32アプリに再統合するというプロジェクト計画でした。
基本はWin32アプリケーションのため、Windows Formから違和感なく移行できそうです。
Unpackaged形式の出力も可能で、自己完結型のアプリケーションをビルドすればランタイムの配布に関する問題も解消できそうです。
現時点ではビジュアルデザイナーが無いためWindows Formsの開発からの移行が増えるにはビジュアルデザイナーの提供が必要な気がします。
逆にASP.NETでのWebアプリ開発に慣れている場合は、Webアプリではビジュアルデザイナーを使用することは少ないため、WinUI 3のXAMLのコードデザインも
比較的受け入れやすいのではないかと思われます。
iPentecではまだ、採用はありませんが、これから検証していく予定です。
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)
