他の人が述べたように、それはトレードオフの問題であり、正しい知識を持つことです。
あなたが考慮したいと思うかもしれない唯一の落とし穴はこれです：あなたはあなたがあなたが利点として「クロスプラットフォーム」を持っているとしてあなたがあなたの質問であなたが質問をすることを述べます。しかし、本当にそうですか？このように考えてください。デスクトップ用に何かを開発する場合、サポートするプラットフォームとその要件のリストを定義する必要があります。
間違いはありません。ウェブでも同じです。また、以前よりも非常にシンプルになっていますが、幅広いパブリックアプリを設計する場合は、あらゆるWebブラウザーのあらゆるバージョンを処理する必要があります。そして、それがエンタープライズアプリの場合は、自分自身を引き締め、サポートされているブラウザプラットフォームの要件を非常に正確にドラフトする準備をしてください。
重要な何かを構築する場合、あちこちでプラットフォーム固有のハッキングを避けることを避けるとは思わないでください。
そして楽しい部分です。最高は何ですか？Chromeのように非常に定期的に自分自身をほぼ自動的に更新するブラウザですか または、セキュリティ更新プログラムを毎月のみ更新し、石器時代ごとに主要な機能（IEなど）を更新しますか？これらの頻繁な「透過的な」更新の一部はコードを破壊する可能性があるため、答えはあなたが思うほど明白ではありません。あなたはこれに従い、迅速に対応する必要があります。または、開発およびテスト中にベータ版と開発版のプレリリースに注目してください。あなたが愚かにもサポートしたいと言ったすべてのブラウザについて（幸運）。
ああ、UIの考慮事項を忘れないでください。また、あなたが一貫性のあるUIたいかどうかを決めるの喜びに直面ACROSSすべてのターゲットプラットフォームを、または一貫性のあるUI WITHを各ホストのターゲットプラットフォーム。Webページで表示できる小さなボタンをすべて表示しますか？どこでもまったく同じにするか、ユーザーが使用する環境と統合する必要がありますか？もちろん、この問題は新しいものではなく、他の開発モデルにも存在しますが、ここではより重要であり、ターゲットとするユーザーのタイプと期待するものに依存します。公共のエンドユーザーは、プラットフォームに統合することを望みますが、それでも「すごい！」それらは派手なもので-エンタープライズユーザーはデスクトップアプリのように見えるものを望みます。そして、モバイルプラットフォームには、これらすべてに新しい次元がありました。
最後の2段落については、一般的には、事前に構成されたWebブラウザーをインストーラーにパッケージ化して、Webアプリ（ローカルでホストされているか、Web上にある）に接続します。更新頻度を制御し、状態を「フリーズ」でき、何をサポートおよびテストするかを正確に知っているため、素晴らしいです。さらに、専用のユーザー拡張機能などのクールなものを追加できます。たとえば、さまざまなタイプのユーザーがWebアプリを簡単に使用できるように開発した小さな「Chrome Extensions」で「凍結」されたChromiumをパッケージ化すると、非常に便利です。一方、...リリースサイクルを凍結したためにセキュリティ違反が発生した場合、あなたは今責任を負い、アプリは速度の改善の恩恵を受けません（もしあれば）。
多くのものと同様に、それは両刃のxです。
注： OSIレイヤーに至るまで、基本的に中途半端なテクノロジーの山である（そしてここでは丁寧です）ために、Web に対して強いバイアスがあります。またはそれらを修正します。
そうは言っても、私はプラットフォームとしてのユビキタスな性質からウェブに賛成です。あなたの会社の動きは（おそらく）正しいものだと思います。明らかに、ターゲット市場とターゲットとするプラットフォームに依存します。何かをサービスとして公開したい場合は、おそらく大丈夫です（必要ではありませんが）。そうでない場合は、それほど多くの理由がないかもしれません。
うーん、そして、既存のオペレーティングシステムのより軽量なバリアントがモバイル環境（ネットブック、スマートフォン、PDA、タブレット、電子書籍など）で生成され続け、軽量の組み込みブラウザの使用に重点が置かれている現在、将来のいくつかの楽しい開発を期待しています。 ..しかし、UIレンダリングの不具合がすべて新たに共有されています。
プラグインベースの技術に関して...私はそれらから遠ざかることを言うでしょう。それらはアプリのパワーを強化しますが、市場への浸透を制限します。場合によっては、新しいプラットフォームが突然サポートを拒否するまで、クロスプラットフォームサポートの観点からはプラスになると思われます。Web Standardsには理由があります（HTMl5のすべてに興奮しすぎないように注意してください。
編集：その他の考慮事項...
募集
知識のあるWeb開発者を見つけるのは非常に困難です。あなたはそれらの群れがあると思うだろうが、彼らはフォームにいくつかの検証を実装するためになんとか700行のJavaScript / ECMAScriptを書くことができたと考えるかなり無能な人々の巨大なプールで失われているそして、高度なスキルの観点から達成できることのすべて。
冗談ではありませんが、最近、すべてのWeb開発インタビューの最初の質問は、変数を宣言する方法と、使用するかどうかvar（回答方法に応じて）に違いがあるかどうかです。憂鬱です。平均的または高度なWeb開発者を見つけることは、平均的または高度なデスクトップ開発者を見つけることよりもはるかに難しいと思います。
知覚
「私はWeb開発者です」と言っても、誰もあなたを真剣に考えません。サブクラスのプログラマー、開発者向けではありませんか？あなたが無視し、遠くからock笑し、コーヒーを飲みに行くときに参加しないもの。:)
これは明らかに真実ではありませんが、ほとんどの場合あなたのために管理されている環境のために開発するという事実に帰着します。ブラウザは、ねじ込みマークアップ、ねじ込みスタイルを修正し、それらの一部のねじ込みスクリプトも修正し、必要に応じて最適化します。そして、あなたがWeb開発者なら、あなたはあなたが低レベルのプログラミングについての手がかりを持っているとは思わないでしょう。
そして、彼らはECMAScriptがどれほどクレイジーに複雑であるかを認識しますが、彼らの意見を検討することを拒否します。それはウェブだからです。私たちは本質的にそれが好きではありません。