複製:これは.NET WebBrowser Control as User Interfaceの複製です。この質問を閉じて、元の回答に新しい回答を向けましょう。
こんにちは皆さん、このような経験が必要です。最近、クロスプラットフォーム GUI を提供する簡単な方法として、C++ で記述されたアプリケーションに組み込み Web サーバーを使用することを考えていました。このテクニックについてどう思いますか？誰かがそれを使用していますか？軽く、クロスプラットフォームで、簡単に開発できます。アプリケーションを自己完結型の 1 つのバイナリ ファイルとして保持する機能
移植性のために UI として Rich Web App を使用するという考えは非常に合理的ですが、クロスブラウザーのサポートはかなり多くの作業を追加します。
サーバーを埋め込むことは私には思い浮かびませんでした (私はプレゼンテーション層を独自の層に自然に分離する多層アプリで作業する傾向があります) が、これを行わない根本的な理由はわかりません - あなたが言うように、単一の自己含まれている実行可能ファイルには、いくつかの魅力があります。HTML、画像などをアプリに分割するのではなく、ファイル システムにファイルとして展開することを選択した場合でも (更新を容易にするためにそうする場合があります)、全体的なアプローチは私には理にかなっています。
このアプローチの欠点の 1 つは、エンド ユーザーが 2 つのプロセス (Web サーバーと Web ブラウザー) を開始する必要があることです。アプリケーションに両方を実行させることで影響を抑えることができますが、アプリケーションが新しいタブを起動するのではなく、既存のブラウザーで新しいタブを開くほどスマートでない限り、1 つではなく 2 つのブラウザー ウィンドウを使用することになる可能性があります。
しかし、それは氷山の一角にすぎません。この道を進む前に、決定がエンド ユーザーに与える影響を考慮する必要があります。あなたの主な目標は、高品質のエンド ユーザー エクスペリエンスではなく、クロスプラットフォームのサポートのようです。あなたにとってどちらがより重要ですか?
Web ベースのフロント エンドがユーザーにとって最適な場合もあれば、従来の GUI ツールキットを使用した方がよい場合もあります。少ない労力でユーザーに豊富なエクスペリエンスを提供できるクロスプラットフォーム GUI ツールキットが多数あります (たとえば、Tk with python、ruby、または Tcl)。
Tk や wx などのツールキットはクロスプラットフォームであるためには妥協が必要だと言う人もいるかもしれませんが、Web ベースのフロント エンドを作成するときに受け入れなければならないよりもはるかに少ない妥協しか提供しないと思います。
もちろん、この決定を行う際には、市場投入までの時間や自分のスキルなども考慮する必要があります。結局のところ、ソフトウェアはエンド ユーザーにとっていくつかのタスクをより簡単にする必要があることを覚えておいてください。そのため、自分の選択がそれをサポートするか、または妨げるかを自問してください。