HTML / JavaScriptのみのWebアプリの長所と短所

Question

私はASP.NETフォームのバックグラウンドを持っており、過去にサーバー側のコーディングが非常に強力であることに気づきました。しかし、最近では、フロントエンドのサーバー側コードを段階的に廃止し、JSON Webサービスを介してデータにアクセスする純粋なHTML/JavaScriptに置き換えたいと思っています。私はこれについて実際の経験がないので、これが実証済みのテスト済みモデルであるかどうかを聞きたいと思います。また、それを取り巻く落とし穴は何ですか？

ASP.Netユーザーコントロールは非常に便利だと思うので、マークアップテンプレートをサーバー上の個別のHTMLファイルに保存することで、理論を維持したいと思います。これらは、jQuery AJAXおよびjQuery HTMLテンプレートプラグインを介してそれぞれ取得および使用されます。

任意の入力は非常に高く評価されます。

追伸noobの質問で申し訳ありませんが、このタイプのWebアーキテクチャはweb-2.0と呼ばれるものですか、それとも私は完全にオフトラックですか？

jmort253 · Accepted Answer

この手法は、現在取り組んでいるWebアプリケーションにのみ使用しています。私のバックエンドはJava SDKを使用してGoogle App Engineでホストされており、フロントエンドはHTML、CSS、およびJavaScript（jQueryを使用）を使用しています。

このプロジェクトは、私とWebデザイナーだけの小規模なプロジェクトであり、この方法により、作業が大幅に速くなり、何かをより早く市場に投入できるようになったと感じています。

利点：Webデザイナを使用する

この手法の主な利点は、PHPは知っているがプログラマーとは思わない）のWebデザイナーが、JSPの無数の行をたどる必要なく、HTMLとCSSに邪魔されずに作業できることです。、taglibタグ、および私たちが長年にわたって教えてきた他のサーバー側マークアップは、フロントエンド開発者の生活をはるかに容易にするためにが想定されています。

すべてのサーバー側マークアップがなければ、より機敏になりました。 Webデザイナーは、元のデザインを3〜4回直接交換して修正しましたが、私の変更はほとんどありません。

彼への彼のコメントは、HTMLを編集してすぐに動的データで自分のマシンの変更を確認できるという点で、HTMLが生きているように感じたというものでした。統合がほとんど自動で行われるという点で、これによって両方にメリットがあります。

サーバー側コードとHTML/CSSハンドオフ

過去のプロジェクトでは、HTMLとCSSをJava開発者に引き渡さなければならず、開発者はHTMLとCSSを取得し、JSPテクノロジーを使用して完全に書き直しました。これには多くの時間がかかり、通常はその結果、ページの実際のレンダリングとW3Cバリデーターでの検証に微妙でありながら重要な違いが生じます。

全体として、私たちは両方ともこの手法に非常に満足しており、HTMLページにはまだJSPページもサーバー側コードもありません。

REST/JSONテクニックの落とし穴

おそらく最大の落とし穴は、まだ遭遇していないものです。より経験豊富なJava Apache開発者とSpringチームがタグライブラリによってフロントエンド開発者が簡単に作業できるようにする方法について教えられたことで洗脳された開発者との不一致があることを私は完全に期待していますコードです。このプロジェクトが拡大するにつれて、学習曲線が現れると私は完全に期待しています。私は、経験上、これらの古い手法を学習しなければならない可能性がある開発者を引き受けます Webデザイナーの仕事をより困難にしました。

別の落とし穴は、JavaScriptコードが非常に大規模になったことです。これは、おそらく私がこのテクニックを初めて使用しているため、および迅速なリリースに向けて作業する際に若干の技術的負債を導入しているために、さらに問題になります。おそらく、より優れたフレームワークを選択することで、コードの大部分を軽減することができたでしょう。私の意見では、これは見事なものではありません。このテクニックを使い続け、この分野でのスキルを磨くことをお勧めします。

利点：他のアプリケーションをプラットフォーム上に構築できる

最後に、隠れた利点について触れておきます。私のバックエンドRESTful Webサービスとフロントエンドの間にはある程度の分離があるため、簡単に拡張できるプラットフォームも作成しました。

私たちの運用担当者の1人が別のアプリケーションで概念実証を試してみたかったのですが、私のRESTfulサービスのおかげで、まったく異なる問題を解決するために、アプリケーションにまったく異なるフロントエンドを作成することができました。急速に開発された概念実証では、独自のHTML、CSS、JavaScriptを使用しましたが、RESTfulサービスをバックエンドおよびデータソースとして使用しました。

結局、別のプロジェクトマネージャーが私がやったことを見て、機能は単なる概念実証以上のものである必要があることがすぐに明らかになり、彼のチームがそれを実装しました。

このアーキテクチャがアプリケーションレベルとHTML/CSS/JavaScriptレベルの両方でどれほど再利用可能であるかを十分に強調することはできません。これを次のプロジェクトで試すことをお勧めします。

tdammers · Answer

これは確かに実行可能な戦略ですが、特効薬ではありません。

長所：

正しく行うと、この方法で開発されたアプリケーションは非常に応答性が高くなります
ロジック（サーバー上）とプレゼンテーション（クライアント上）が明確に分離されている。サーバーは、アプリケーションの表現面にまったく関係する必要はありません。
ネットワーク帯域幅の潜在的により効率的な使用（生データのみを送信し、プレゼンテーションのボイラープレートは送信しません）
リクエスト/レスポンスのパラダイムにあまり依存しないため、デスクトップのようなGUIを簡単に開発できます。

短所：

クライアントコードをJavascript、またはJavascriptにコンパイルできる言語で記述する必要があります。これは、ブラウザで使用できるのはそれだけだからです。
クライアントでのリソース使用率が高くなる可能性があるため、アプリケーションは標準以下のデバイス（モバイルブラウザなど）ではうまく機能しない可能性があります。
javaScriptが無効になっていると、まったく機能しません。公開されているWebサイトがある場合は、このリスクを負う意思があるかどうかを特に考える必要があります（特に、SEOとアクセシビリティを検討する場合-JavaScriptを多用するアプローチは、通常、これら2つの面で壊滅的です）。
多くのロジックを2回記述する必要があります。1つはクライアント上で、もう1つはサーバー上で（クライアントを信頼することはできないため）
並行性は地獄になる可能性があるため、クライアント側のコードを慎重に設計し、あらゆる種類の並行性の問題に備える必要があります。

Ken Fehling · Answer

1つの欠点は、JavaScriptとASP.netのロジックの一部を複製する必要があることです。アプリケーションによっては、これは大きな問題ではない場合があります。サーバーに細かいことすべてをチェックするように要求する必要がないため（「この状況でユーザーがこのボタンを押すか、このオプションを選択することを許可されていますか？」）、頻繁に表示されますが、依存したくないユーザーがクライアントを制御できるため、検証を行う唯一のクライアントとしてクライアント上で。

gbjbaanb · Answer

それは間違いなく可能であり、おそらくベストプラクティスとして奨励できます。あなたが提案しているのは、UIをビジネスロジックから分割することです。これは本当に良いです。

多くの場合、私たちが物事を混同しようとするフレームワークは、UI、ビジネスロジック、およびデータがすべて相互に絡み合ったモノリシックなソフトウェアになってしまいます。これにより、保守と変更が困難になります。

アプリケーションを2つに分割したら、UIを完全に別のもの（デスクトッププログラム、またはデスクトップブラウザーと比較してモバイル用の別のUI）に置き換えることができます。

これを実行するときに見つけるトリッキーなビットは、理論的にはサーバーにあるはずの少しのコードがクライアントに配置されることです-検証、たとえば、ユーザーが検証コードをたとえば、テキストフィールドに英数字のみが含まれていることを確認するためにサーバーをヒットするのではなく、クライアント上のフォーム。同じことがデータ層とビジネス層にも当てはまります。レイヤー間の区別にいつ違反するかについて、情報に基づいた実際的な決定を行う必要があります。

šljaker · Answer

ASP.NET WebFormsをまだ使用していて、アプリケーションを高速化したい場合は、次のことを行ってください。

最後に、www.porsche.seをチェックしてください。それはすごく速いウェブサイトではありませんか？