呼び出し JavascriptとJavascript HTMLテンプレートでウェブアプリ全体を構築してみませんか?



htmlから外部js内の関数呼び出し (3)

私は物事をキャッシングする必要があるアプリのポイントに達すると、それは私に考えさせてくれた...

  1. アプリのいくつかの部分では、純粋なJSONを取得し、Mustache、jquery.tmplなどの方法でテーブルの行(jqGrid、slickgridなど)または空のdiv行(New Twitterなど)をレンダリングします。
  2. アプリの他の部分では、純粋なHTML(サーバー側のHAMLテンプレート)で情報をレンダリングします。検索/ページングがある場合は、新しいURLに移動して新しいHTMLページを読み込むだけです。

今問題はキャッシュと保守性です。

一方では、JavascriptのHTMLテンプレートを使用してすべてが構築されていれば、私のアプリケーションはHTMLレイアウト/シェルとJSONの束にしかならないと思っています。 あなたがFacebookとTwitterのHTMLソースを見ると、基本的に彼らがやっていることです(95%json / javascript、5%html)。 これにより、私のアプリケーションはJSON(ページ、アクション、レコード)をキャッシュするだけで済むようになります。 これは、リモートAPI開発者がJSON APIにアクセスしているかどうかに関係なく、キャッシュにヒットすることを意味します。 つまり、JSON用とHTML用の2つのキャッシュは必要ありません。 それは私のキャッシュストアを半分に減らし、物事を少し効率化するように思えます。

一方、私は、私が見た/経験したことから、静的なHTMLサーバーサイドを生成し、それをキャッシングすることから、より良いパフォーマンスの賢明なクロスブラウザと思われることを考えています。 あなたは即座にグラフィックスを取得し、それをレンダリングするためにJavaScriptを分割するのを待つ必要はありません。 StackOverflowはプレーンなHTMLですべてをやっているようだが、Googleもそうだ。 twitter.comでは、ページが0.5〜1秒間空白で、ページがチャンクしていますが、javascriptはjsonをレンダリングする必要があります。 これの欠点は、動的なもの(無限のスクロールやグリッドのようなもの)のために、とにかくjavascriptテンプレートを作成しなければならないということです。そのため、サーバーサイドのHAMLテンプレート、クライアントサイドのJavaScriptテンプレート、キャッシュにもっと。

私の質問は、これにどのようにアプローチするかについてコンセンサスがあるかどうかです。 2つを混ぜて100%を重ね合わせた場合の利点と欠点は何ですか?

更新:

何故私がまだ100%のjavascriptテンプレートを使用するかの決定を下さなかった理由をいくつか挙げておきます:

  • パフォーマンス 。 正式にはテストされていませんが、私が見てきたことから、生のhtmlはjavascriptで生成されたhtmlクロスブラウザより速く、より流動的にレンダリングされます。 さらに、モバイルデバイスが動的なhtmlパフォーマンスをどのように処理するのかよく分かりません。
  • テスト 。 私は静的なHTMLでうまくいく統合テストをたくさん持っているので、javascriptのみに切り替えるには、もっと集中的な純粋なjavascriptテスト( jasmine )と、2)javascriptをcapybara統合テストに統合する必要があります。 これはちょうど時間と仕事の問題ですが、それはおそらく重要です。
  • メンテナンス 。 HAMLを取り除く。 私はHAMLを愛しています。書くのはとても簡単です。かなりのHTMLをプリントします...コードをきれいにして、メンテナンスを簡単にします。 javascriptを使うと、簡潔には何もありません。
  • SEO 。 私はGoogleがajax /#!/path処理することを知っていますが、これが他の検索エンジンにどのように影響し、古いブラウザがそれをどう処理するかを理解していません。 重要な設定が必要なようです。

Answer #1

私はここから離れているかもしれないが...

あなたはCouchDBを見たことがありますか? 私は間違っている可能性がありますが、あなたの状況はApache CouchDBの使用に最適かもしれないように聞こえます。私はそれを実際に使っていませんが、私はよく見ました。それは非常に興味深いデータベースです。

これは、接続にREST APIを使用するドキュメントベースのデータベースです(非常に多用途で使いやすい)。 それはまた非常にJSON中心で、非常に速く、小さなフットプリントです。 携帯電話やその他の埋め込み用途にも使用できると言われていますが、同時に、非常に拡張性が高いとされています(上向きです)。 あなたのような大きなJSユーザ(あなたのように聞こえる)なら、あなたはそれで家にいるかもしれません。

私はちょうどここに提案されている方法の任意の数に便利になるかもしれないと思っていたと私はちょうどあなたにストレージオプションのアイデアを与えるためにチャイムだと思った:)


Answer #2

私はこれらの2つのアプローチを混在させていましたが、クライアント側のレンダリングに切り替えました。なぜなら、重いJavaScriptを正しく処理することが本当に難しいからです。 完全なソリューションとして、 JavaScriptMVCフレームワークのアプローチを推奨できJavaScriptMVC

それはEJSと呼ばれるビューレンダリングエンジンを備えています。このレンダリングエンジンは、アプリケーションのプロダクションビルドのためにビューをプレーンJavaScriptに圧縮できます。 これにより非常に高速になります(すべてのHTMLは単一の圧縮されたJavaScriptファイルでプリロードされ、モデルJSONデータを受け取るとすぐにレンダリングされます)。 私は個人的には、EJSレンダリングとプレーンHTMLの転送のパフォーマンスの違いに気づくことができませんでした。

次に、RESTの原則に従ってAPIを使用する場合、キャッシングは重要な制約の1つです。 したがって、アプリケーションでJSONデータのHTTPキャッシュが適切にサポートされていて、圧縮されたクライアントサイドテンプレートを使用している場合は、パフォーマンスが向上することもあります。


Answer #3

永続的なプライベートデータストレージ。

さまざまなレベルのパブリック/プライベートアクセスでデータを格納するサーバーが必要です。 安全なクローズドソース情報のサーバーも必要です。 あなたはクライアントでやりたくない重い荷物を運ぶためのサーバーが必要です。 複雑なデータのクエリは、データベースエンジンを使用することをお勧めします。 インデックス作成と検索はまだjavascriptには最適化されていません。

また古いブラウザの方がはるかに遅いという問題もあります。 FF4 / ChromeまたはIE9を実行していない場合、クライアントとサーバーのデータ操作とページ作成には大きな違いがあります。

私自身は、MVCフレームワークとテンプレートを使用して完全に作成されたWebアプリケーションを構築しようとしていますが、サーバーを使用して安全で最適化されたデータベースに接続します。

しかし、一般的に、アプリケーションは実際には完全にjavascriptとテンプレートを使用して構築することができます。 さまざまな構成要素やJavaScriptエンジンがこれを行うのに十分なほど進歩しています。 そこには、これを行うのに十分な一般的なフレームワークがあります。 純粋なjavascript Webアプリケーションは、もはや実験とプロトタイプではありません。

ああ、このためのフレームワークを推薦していたら、 backbone.js見てください。

セキュリティ

私たちがクライアントを信用していないことを忘れてはいけません。 サーバサイド検証が必要です。 JavaScriptは、動的に解釈され、実行時に操作できます。 私たちはクライアントの入力を信用しません。





templating