デスクトップアプリケーションに対するWebアプリケーションの利点
私が働いている会社では、突然すべてのアプリケーションをすべてWebアプリケーションに移植する必要があるようです。私が理解できる限り、唯一の理由は、Webアプリケーションの誇大宣伝が最終的に私たちの意思決定者の一部を汚染したことです。
デスクトップアプリケーションはユーザーフレンドリーであるため、私はデスクトップアプリケーションのファンです。私の意見では、それらはより反応が良く、より良いユーザーインターフェースを持ち、よりカスタマイズ可能で、より良いキーボードサポートを持っています。 WebバージョンのVisual StudioまたはOpenOfficeを使用している自分を見ることはできません。さらに、シンクライアントデスクトップアプリケーションは、対応するWebアプリよりも簡単に実装できるという印象を持っています。
たぶん、私はいくつかのWebアプリケーションの品質を見落としているかもしれません。そして、私は上記の欠点について間違っているかもしれません。したがって、私の質問：デスクトップアプリケーションよりもウェブアプリケーションの利点を見ることができる人はいますか？
更新： これまでのところ、いくつかの興味深い反応がありました。ただし注意してください 私はシンクライアントとファットクライアントの違いについて話しているのではありません アプリケーション。ただし、Webブラウザプラットフォームとデスクトッププラットフォームの開発の間のみ。
更新： 「Webアプリケーション」とは HTML/CSS/JavaScript、Silverlightなどのリッチインターネットアプリケーションではありません。これらはデスクトップアプリケーションと非常によく似ていますが、主な違いはサンドボックスで実行されることです。
Webアプリケーションは、各クライアントマシンでdeployingの負担を回避します。
クライアントマシンでバージョンチェックを強制する必要はありません。
更新の方が簡単です。
バグ修正を簡単にします。
管理者なし権限チェック。
どこからでもアクセス可能。
プラットフォーム非依存。
サポートとメンテナンスの方が簡単です。
モバイルアプリケーションの適応性。
デスクトップアプリケーションは、Webアプリケーションよりも優れたユーザーエクスペリエンスfarを提供します。
確かにすべてのオプションには長所と短所がありますが、これらも評価する必要があります。あなたにとって重要なのは、ユーザーエクスペリエンスとプラットフォーム非依存のどちらですか？ユーザーエクスペリエンスを多くのものよりも高く評価しています。はい、私たちは犠牲を払っていますが、それは人生の一部です。
上司を説得する1つの方法は、デスクトップアプリケーションでユーザーエクスペリエンスが光年先にあることを彼らに証明し、デスクトップアプリケーションを作成するように説得することですbefore Webアプリケーションを作成します。
私たちは会社にも顧客にも、ウェブアプリよりもデスクトップアプリの方が好きです。彼らは、デスクトップアプリケーションの使用に伴う不利益を受け入れてくれます。
他の人が行ったように、私は答えにウェブアプリの利点をリストしていません。 Webアプリとデスクトップアプリの両方に長所と短所があります。 両方を行う！顧客に選択させます。統計について教えてください。 ;-)
リッチデスクトップアプリとWebサイトの両方を作成するために、かなりの開発を行ってきました。
一般に、デスクトップアプリのコードを記述する方が簡単で、使用できるコントロールが多くなり、アプリの動作をより細かく制御できます。
Webアプリケーションを作成するには、ブラウザーのHTML（CSS、Javascript）、およびブラウザの制限（またはIEについてのバグ）を理解する必要があります。状態とその永続化について心配する必要があり、利用できるメカニズムは限られています。
そうは言っても、時間の経過とともに、Webアプリケーションの作成をますます楽しんでいます。プラットフォームの制限により、作業が簡素化されます。また、Webのステートレス性は、複雑さの一部を管理するのに役立ちます。私の最後のWebプロジェクトは稼働しましたが、非技術者はWebページとその動作方法に精通しているため、ビジネスではほとんどトレーニングは必要ありませんでした。修正を入れてすぐに公開することも素晴らしいことです。デスクトップアプリのアップグレードに取り組んだことがあるなら、それがどれほど複雑で苦痛なのかは間違いないでしょう。
最近、メインシステムをWebサイトとして記述し、より多くの機能を必要とするパワーユーザーにクライアント側アプリケーションを提供する、混合戦略（Webtop）である程度の成功を収めました。これは、ブラウザーコントロールをホストする（WindowsでIEを簡単に埋め込むことができ、OS Xでもsafariで同じことを行うことができます））か、APIを使用できます。バージョンですが、パワーユーザーはTweetDeckなどを使用できます。
- すべてのユーザーは常に最新バージョンを使用します
- 著作権侵害なし
- ユーザーがどこからでもアクセス可能
- クロスプラットフォーム
- ユーザーがインストールする必要はありません
- ユーザーが何をしているかを簡単に測定できます（機能XXなどを使用しているユーザーの数）
- すべてのデータが一元化されるため、必要に応じてユーザー間で簡単なコラボレーションを提供できます
デスクトップアプリよりもWebアプリの長所：-
- プログラムのコピーを1つだけ更新する必要があります。
- コードの99％はプラットフォームに依存しません。
- 保守、サポート、およびパッチの提供が簡単です
- クライアントコンピューターが課した制限を見つける可能性が低い
- さらに多く
デスクトップアプリよりもWebアプリの欠点：-
ネットワーク接続がダウンしている場合、アプリもダウンしています
アプリケーション（サーバー側スクリプト、SQL、XHTML/CSSなど）を正常に開発するために複数の言語を学ぶ必要がある
- セキュリティの必要性が低い（ユーザーは会社で信頼されており、「外部の脅威」はありません）
- ウェブサーバー専用のマシンの必要性
このすべては、この会話で見つけることができる多くの賛否両論の少数です
多くのポイントがすでに言及されています。しかし、私が完全に同意できないいくつかがあります：
- Webアプリケーションの展開は簡単ですが、デスクトップアプリの展開は、Microsoft ClickOnceやJava Web Startの時代にはそれほど複雑ではありません。
- バグ修正は、Webアプリケーションは本当に簡単ではありません（セッションが少なく、Webサーバープロセスで実行されます...）。
- Webアプリケーションには、セキュリティ上重要な操作の実行やハードウェアへのアクセスに関して、常にいくつかの制限があります。
Webプラットフォームとデスクトッププラットフォームの両方には、長所と短所があります。両方について良い議論ができます。ハイブリッドアプリ（一部のWeb、一部のデスクトップ）にも、この点で利点/欠点があります。
アプリケーション開発は、技術のトレンドや宗教的な設定、または一般的な長所/短所の比較ではなく、常に要件によって推進される必要があります。
ブロードバンドアクセスがむらがある、または存在しない米国またはその他の国の地域の人々にWebアプリを販売しようとしたことがありますか？ :)モバイルアクセスはどうですか？ネイティブ、ウェブベース、またはハイブリッド？インターネット接続が必要ない場合、データへのローカルアクセスはどうですか？等。
アプリケーション要件から始めて、テクノロジーに戻ります。それを行うとき、あなたは正しい決定を下し、手元のプロジェクトに最適なプラットフォームになります。
例：「デスクトップアプリケーションは、Webアプリケーションよりもはるかに優れたユーザーエクスペリエンスを提供します」というコメントを受け取ります。要件（A）が、Webブラウザーとインターネットアクセスを備えたコンピューターからのいつでもどこでもアクセスを要求し、（B）デスクトップのようなパフォーマンス（たとえば、ページの更新を必要としないライブデータベースデータ）を要求する場合、（ C）開発者は、AJAX、Flash、Silverlight、Java、またはブラウザーコントロールとして読み込まれるネイティブクライアントなどのテクノロジーを検討するように導かれます。
繰り返しますが、テクノロジー主導ではなく、要件主導であると言います。
アプリケーションのタイプに依存します。 cmsアプリケーションがある場合、アプリケーションはプリンター、バーコードリーダー、フィスカルプリンター、ディスプレイなどのローカルリソースで動作する必要があるため、web（少なくとも一部）に置き換えることができません。
したがって、ローカルリソースを必要とするこのタイプのアプリケーションでは、デスクトップを置き換えることはできません。
また、cmsアプリケーションの場合、デスクトップアプリはWebよりも非常に高速です。
多くの顧客が注文の支払いを待っており、Webアプリケーションでウィンドウに支払いをしている大きなスーパーマーケットを想像してください。私はそのようなことを見たことがありません。
しかし、Oracle ADFのようなデスクトップasspよりもさらにリーチのあるWebフレームワークもあります。 ADFを使用すると、デスクトップアプリの構築方法と同様の方法で、デスクトップアプリと同じWebアプリを構築できます。しかし、それは高価ですか、学習曲線は高く、「良い」ハードウェアが必要です。
ただし、Webでテスト済みのコンポーネントを使用していない場合、Javaスクリプトはミッションクリティカルなアプリにはあまり適していませんが、エラーが発生しやすいことに注意してください。
通常は完全にWebベースである私にとって、デスクトップアプリに向かわせる要因はハードウェアの統合です。 Webアプリは、データの読み取りと送信のみが必要な場合に最適ですが、ラベルプリンターやその他の特殊なハードウェアなどとのインターフェイスに関しては、デスクトップアプリが唯一の現実的な方法です。 「Webアプリ」のチェックボックスをオンにする必要がある場合は、これらをWebサービスなどにリンクできますが、専門的なハードウェアサポートはブラウザーの領域の大部分を占めており、既存のAPIを使用してアクセスします。
私はデスクトップアプリケーションのファンでもあります。 Webアプリケーションのその他の短所をいくつか挙げてみましょう。
- Webアプリケーションのプレゼンテーションロジック/ UIの開発は、デスクトップアプリケーションに比べて困難です。
- 異なるブラウザでのユーザーエクスペリエンスは異なる場合があります。
- 遅延操作：Webとデスクトップで同じトランザクションを検討します。 Webアプリケーションは、デスクトップアプリケーションよりも高いWebサーバーをシークする遅延を保持する場合があります（ほとんどの場合）
- クライアントのCPU使用率：これはデスクトップアプリのデメリットと見なされる場合がありますが、Webアプリは、クライアント側サーバーの合計処理作業負荷を平準化するために考慮される場合があるクライアント側プロセッサの利用に優れた機能を保持しません。
最近は、linux/osx/windowsプラットフォームの独立性を選択する人々がいる大きな機能です。これにより、はるかに大きな市場をターゲットにできます
もちろん、アプリケーションを世界中のどこでも使用できるという明らかな利点があります...便宜上
アプリケーションをWebアプローチに開発する主な理由は、デスクトップアプリケーションと比較する場合よりもアクセスしやすいことですが、そうする場合は、ニーズに応じて何を使用するかを十分に把握する必要があります。
Webアプリケーションは、非常に機密性の高いデータを渡さないアプリケーションを開発する場合にのみ有効です。Webアプリケーションはオンラインで展開されるため、デスクトップアプリケーションと比較する場合よりもハッカーになりやすいため、 Webアプリケーションをセキュリティで保護するためのセキュリティ対策は既にありますが、デスクトップアプリケーションはWebアプリケーションよりもセキュリティリスクを軽減できますが、時間の経過とともに人々はこのセキュリティ対策を破壊する方法を発見し、ほとんどの使用はそのほとんどを知っていると思います特にあそこに存在する筋金入りのハッカー。デスクトップアプリケーションにもセキュリティ上の欠陥がありますが、非常に最小限です。
しかし、誰かが本当にソリューションを提供するためにWebアプリケーションを使用したい場合は、デスクトップアプリケーションを開発する人々にとっても同じことになるリスクを十分に知らされている方が良いでしょう。
デスクトップアプリケーション用にリストした利点については正しいです。言及するのを忘れたもの（セキュリティ、メンテナンスなど）がさらにあります。Webアプリケーションの主な利点は、Webブラウザを介して消費できることです。実質的にどこでも。
Visual WebGui は、デスクトップ（Windows）アプリケーションを開発し、それらをWebアプリケーションとして実行できるようにするため、まさにこれを目指したソリューションであり、デスクトップの開発と展開（直感的、応答性、ユーザーフレンドリー）であると同時に、ウェブアプリケーションのアクセシビリティをお楽しみください。
見てください、それはあなたに多くの時間と手間を節約するかもしれません。
上記の点に同意します...
webアプリにプロを追加したいだけです。テーマを変更することもできます（CSSを変更するだけです）。デスクトップアプリはユーザーによっては退屈に見えるかもしれませんが、wepアプリでは、テーマ/デザインを変更でき、ユーザー（およびボス）に感銘を与えます。
実装する方が安価です。たとえば、.NETでアプリケーションを開発する場合、Windowsをインストールするクライアントが必要です。しかし、Webアプリケーションでは、一度開発すれば、すべてのクライアントがどのプラットフォームでもWebアプリにアクセスできます。
webアプリの開発は簡単です（CSSのJavaScriptとフレームワークについて知っていれば）、それはあなたの生活を楽にすることができます。
ウイルスがなく、クライアントに簡単に展開/インストールできます。
短所：WebアプリのUIはより複雑で、UIの品質を高めるためにJavaScriptやCSSの機能が必要です。
最初から作成するのは面倒なことですが、それはWebアプリで新しいモジュールを作成することをお勧めします。それは賢明でしょう:)
あまり一般的に認識されていないWebアプリケーションの利点の1つを挙げたいと思います。通常、適切に設計されたWebアプリケーションは、オンラインヘルプをアプリケーションに統合します-簡潔でわかりにくいデスクトップアプリと、その冗長で整理されていないヘルプファイルとの間の通常の不格好な区分は見当たりません。これはおそらく、Web開発者/デザイナーとデスクトップ開発者の文化的な違いです。
- すべての処理はサーバー側で行われるため、Webアプリケーションはクライアント側で多くの処理要件を必要としません。ブラウザーは単なるビュー部分またはユーザーインターフェイスです。
- すべてのリクエストがサーバーに到達してログに記録されるたびに、ログ情報とユーザーブラウジングパターンを監視するWebアプリケーションを簡単に変更できます。
ほとんどの場合、ユーザーはアプリケーションを使用するためにブラウザのみを必要とします。すべてのstuffアプリケーションのニーズをデプロイする必要はありません。また、アプリケーションがクライアントで動作しない理由を考える必要もありません。
以前は、アプリのデスクトップインターフェイスを開発していました。過去3年間で、純粋なWebインターフェイスに移行しました。ここに私がそれをした方法があります：
- コアアプリケーションは、RESTを介して公開するサービスのコレクションとして作成します。
- 私はWxWidgetsに似た「ライブラリ」を作成しました。
- GUIは、デスクトップアプリで使用したように、画面をプログラムで作成するJSコードです。
- すべてのスタイリング/スキニングは、CSSクラスを使用して行われます。
- 現在、私はインタラクションに長いポーリングを使用していますが、将来はWebSocketsまたはWebRTCを使用する予定です。
すべてのユーザーはChromeの最新バージョンを使用し、アプリケーションは会社のイントラネットからのみアクセスできます。ほとんどのユーザーは、Chrome社内サーバーへの画面モード：あまり知識のないユーザーは、デスクトップアプリではなくなったことを認識していません（そうする必要もありません）。