HTML / JavaScriptのみのWebアプリの長所と短所[非公開]

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

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

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

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

この手法は、作業中のWebアプリケーション専用に使用しました。バックエンドはJava SDKを使用してGoogle App Engineでホストされ、フロントエンドはHTML、CSS、およびJavaScript（jQueryを使用）を使用します。

このプロジェクトは、私とWebデザイナーだけの小さなプロジェクトであり、この方法は私たちの仕事をずっと速くし、何かをより早く市場に出すのに役立ったと感じています。

利点：Webデザイナーとの連携

この手法の主な利点は、PHPをある程度知っているが、自分をプログラマーとは見なしていないWebデザイナーが、JSP、taglibタグ、およびその他のサーバー側の無数の行を歩くことなく、HTMLおよびCSSで邪魔されずに作業できることです。長年私たちに言われてきたマークアップは、フロントエンド開発者の生活をずっと楽にするはずです。

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

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

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

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

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

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

おそらく最大の落とし穴は、私たちがまだ遭遇していないものです。Apacheライブラリの基礎とSpringチームがタグライブラリを使用してフロントエンド開発者がコードを簡単に操作できるようにする方法について洗脳された経験豊富なJava開発者との意見の相違があることを完全に期待しています。このプロジェクトが拡大するにつれて学習曲線が生まれることを完全に期待しており、私たちの経験では、Webデザイナーの仕事をより困難にしてきたこれらの時代遅れの技術を再学習しなければならない開発者を増やしています。

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

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

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

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

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

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

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

長所：

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

短所：

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

それは間違いなく可能であり、おそらくベストプラクティスとして勇気づけることができます。提案しているのは、UIをビジネスロジックから分離して、懸念事項を明確に分離することです。これは本当にいいです。

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

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

これを行う際に気づくのは、理論的にはサーバーにあるはずの少しのコードをクライアントに配置する方が良いということです。たとえば、テキストフィールドに英数字のみが含まれていることを確認するためにサーバーにアクセスするよりも、クライアント上のフォームの方が適切です。多くの場合、データ層とビジネス層にも同じことが当てはまります。レイヤー間の区別をいつ侵害するかについて、十分な情報に基づいた実用的な決定を行う必要があります。

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

まだASP.NET WebFormsを使用していて、アプリケーションを高速化する場合は、次のことを行う必要があります。

• SOLIDを念頭に置いてアプリケーションを設計する
• ViewStateすべてのページとユーザーコントロールで無効にする

• サーバー側のコントロールを使用しないでください

  <％：<asp：Literal id = "Title" runat = "server">ではなくVeiwModel.Title％>

• バックエンドで、OnInitメソッドをオーバーライドし、そこですべての初期化を行います。

  protected Override void OnInit（System.EventArgs e）{CreateViewModel（）; base.OnInit（e）; }

• SquishItを使用して、すべての.cssおよび.jsファイルを1に圧縮します

• 遅延読み込み画像
• 複雑なオブジェクトをキャッシュする

最後に、www.porsche.seをご覧ください。それは非常に高速なウェブサイトではありませんか？