デスクトップGUIにローカルWebサーバー+HTML/CSS/JSフレームワークを使うのはアリ？ なぜ流行らないのか、デメリットと代替案を徹底議論！
デスクトップアプリケーションのGUIに、ローカルWebサーバーとWebフロントエンドの組み合わせがもっと使われても良いはずなのに、なぜそうならないのか？ 個人的には、Webサーバー（Axum、Actixなど）とWebフロントエンド（HTML/CSS + JSフレームワーク、wasmなど、好きなもの）を使うことで、アプローチの柔軟性が高まり、長期的に見ても学習する価値が高いと考えています。Web開発スキルは応用範囲が広く、専門的な技術を学ぶよりも保守性も向上するはずです。 もしデスクトップアプリケーションにしか対応しない場合、Tauriのようなものを使うメリットは何でしょうか？ Tauriは、ある意味で制限が多いと感じています。 1. バックエンドとフロントエンド間のデータ転送方法は、実装と設計の両面でかなり制限されています（JSによるパフォーマンスの低下は、通常のWebページよりも顕著）。さらに、Tauri固有の方法を学ぶ必要があり、Tauri以外では役に立ちません。既存のWeb標準のデータ転送を使わないのはなぜでしょうか？ 2. TauriはLinuxではWebKitGTKしかブラウザの選択肢がなく、多くの最新ブラウザ標準をサポートしていません。機能が不足しているだけでなく、パフォーマンスも非常に悪いです。 3. Tauriは、Windowsのウイルス/マルウェア認識で誤検出されることがあります。これはかなり深刻な問題であり、Tauriの開発者は何もできないと言われています。 4. Tauriはまだ新しいプロジェクトであるため、ドキュメントが不足しています。最悪のFOSSプロジェクトではありませんが、基本的なタスク以外を行う場合は、もっと明確な説明が必要です。 QTのようなものは、どのようなメリットがあるのでしょうか？ 私には、QTは可能性の面でより制限が多いように思えます。デスクトップのデザインに限定され、知識も他のプロジェクトや技術に応用しにくいです。 Rustとは直接関係ありませんが、ElectronがローカルWebサーバー+Webページよりも優先されるのはなぜでしょうか？ 唯一のメリットは、ファイルシステムへのアクセスが容易なことと、プログラムがブラウザで開くのではなく、デスクトップアプリのように動作/見えることくらいです。前者は解決可能であり、後者もWebViewのみという極端な選択肢を選ばずに解決できたはずです。標準化されたブラウザをターゲットにできるというメリットもありますが、これは以前ほど問題ではありません。 ローカルWebサーバー+Webフロントエンドのアプローチの主な欠点は次のとおりです。 1. 独立したデスクトップアプリケーションとしてではなく、ブラウザで実行されること。需要があれば解決できると思います。つまり、WebView/Electron/Tauriのように、選択したブラウザに、ブラウザのオプションやメニューなしで実行する起動オプション/モードがあれば良いのです。これは、すでに開いている他のブラウザプロセスとは別に、最小限のWebページを実行するようなものです。 2. ローカルコンピューター上のものがプログラムのフロントエンドとバックエンド間のAPIやトラフィックを見ることができるため、プライバシーの観点からは安全ではありません。これは、そもそも環境が侵害されていることを前提としているため、大きな問題ではないと思いますが、他のデスクトップGUIアプローチと比較すると、より露出している可能性があります。 3. 例えばTauriは、完成した製品を単一の実行可能ファイルまたはappimageにまとめてパッケージ化できます。これは非常に便利で簡単です。Axum + Webフロントエンドのようなもので手動で行うことも可能ですが、より多くの設定と労力が必要です。 他に何か見落としていることはありますか？ 私には、メリットと利点しか見えません。より優れた柔軟性と、目的を達成するためのより多くのリソースが得られます。しかし、このコンセプトを検索しても、あまり例が見つかりません。関連する議論を見つけても、ほとんどの人がTauriを勧めてきますが、これは私には理解できません。Tauriが標準的なデスクトップアプリに近いという点を除けば、私にとってはメリットというよりは制限のように思えます。私の意見は少数派なのでしょうか？ Tauriのような制限なしに、私が求めているものをターゲットにしたプロジェクトはありますか？ ありがとうございます！