JavascriptによるクライアントサイドのUIレンダリングは良い考えですか？

Question

Web開発の「古典的な」アプローチは、シンクライアントと太いサーバーの間にありました。サーバーはHTMLを生成し、ブラウザでレンダリングするためにHTMLを吐き出します。しかし、現在のブラウザでは（また、良いライブラリやフレームワークが利用できるため）、Javascriptが動作するようになりました。 Web開発者は、Javascriptコードがうまく動作し、迷惑にならないようにすることができます。

これは確かにウェブ開発のための新しい可能性を開いた。アプリケーションは、サーバーから返されたHTMLコンテンツから大部分を構成し、ブラウザ側でレンダリングできるようになりました。一部のUI操作はクライアント側で実行されます。クライアントは、UIの一部を更新するための新しいデータをサーバーに照会することさえできます。しかし、我々は他のすべての方法を下に行くことができますか？アプリは、ユーザインタフェース全体の構築と制御を担当する太字のJavascriptクライアントに貼り付けられた最もシンプルなJSONだけを吐き出すサーバとして確かに設計できます。ええ、このアプローチは、人々がもはやポインタを送ることができない程度にURLを真剣に破ることができますが、その周りにあなたのやり方をデザインすることは確かに可能です（電子メールやフィードリーダーのようないくつかのアプリでは、問題）。

あなたはどう思いますか？あなたはこれまで試みたことがありますか？物事が遅すぎるのですか？現代のブラウザは、その量のJavascriptコードを処理できますか？最新のライブラリを使用しているにもかかわらず、未実装の開発者を依然として噛み付かせるブラウザの実装には、大きな違いがありますか？このアプローチがどのようなアプリケーションに適していると思いますか？それは実際に何かのために適しています？

Answer 1

私はちょうどこの種のアプリをビルドの最後にあります。これは、Zend FrameworkのJSON-RPC Webサービスの上にあるExtJSのGUIで、iGoogleのようなガジェットポータルを実装しています。

利点：

• 非常に敏感UI、ExtJSのはあなたに優れたユーザーエクスペリエンスを提供します。
• 非常に予測可能なクライアントとサーバー間の通信。すべてのjson（デバッグしやすい）。 APIに固有の標準化されたエラー処理があります（少なくとも私はそれをどのように設計しましたか）。
• フロントエンドは交換可能です。私は同じサーバーのバックエンドの上にC++アプリケーションを書くことができました。フロントエンドとバックエンドをクライアント/サーバーラインに分けることは、独立してテストすることが容易であることを意味します。
• あなたは生き生きと息を吹き返します。もしあなたが好きなら、素晴らしいです。

短所：

• あなたは生き、あなたはそれを嫌う場合は吸うJavaScriptを、息をする必要があります。私たちのケースでは、これはPHPが重かったので開発チームの大規模な再訓練を意味しました。
• すべてが1つの長寿命DOMに収められているので、メモリ管理で足元に留まり、物がきれいに整理されるようにする必要があります。あまりにも多くのUIを読み込むと、IEは「うーん、私の脳を傷つけている」ということになります。
• UIの生成中にオプションを取得するクイッククエリは実行されません。クライアントでの生活のプログラム設計上の制約は、最初は気にしません。あなたはそれに慣れていますが、それはちょっとしたハードルです。
• javascriptをすべて読み込むと、ユーザーは高速接続と最新のブラウザーが必要です。

これを実行する主な理由は、優れたユーザーエクスペリエンスを提供することでした。ユーザーはデスクトップのようなエクスペリエンスを期待しており、サーバー往復でそのようなエクスペリエンスを提供することはできません。私たちは今、それを実現するようになっていますが、このようなアプローチで大きな課題があることは否定できません。全体的に私は満足しています。

アップデート（2013年9月）：

それでも、このアーキテクチャを使用して、まだあなたは本物のWebアプリケーション（いくつかの動的な機能を持つだけでなく、Webページ）を構築している場合、それは右のアーキテクチャの考え方。私たちのチームと製品は現在はるかに大きく（500,000行にも及ぶ）、アーキテクチャは問題なく拡張されています。今ではスケーラブルなスケーラブルなjavascriptフレームワーク（angle、ember、...）がたくさんあるので、このような作業方法を採用するのがこれまで以上に簡単です。

@rwooが尋ねたので、我々はまだ持っているいくつかの課題：jsのコードの

• オンデマンドロードが予想よりもトリッキーな問題であることが判明しました。あなたのアーキテクチャでこの部分を正しく取得することが重要です。
• jsは構文エラーに耐えられず、製品が顧客に届くまで気付かないことが多いので、自動jshint検証をsubversionのpre-commitフックに組み込む必要がありました。
• データベースはWebサービスリクエストの反対側にあるため、WebサービスAPIを慎重に設計する必要があります。そうしないと、XHRリクエストが多すぎるのを待っているため、パフォーマンスが低下します。これは解決可能ですが、挑戦的ですが、時間とともに簡単にはなりません。
• 正しいフレームワークでブラウザ間の問題は最小限に抑えられますが、すべてのブラウザでテストする必要があります。これは、セレンのようなものを使って自動化する必要があり、クライアント側のレンダリングされたUIでは、サーバー側のレンダリングされたUIよりも難しいことが分かります。

Answer 2

Google GWTのようなツールは、あなたが何を記述するか - JavaScriptのクライアント側の多くをレンダリングします。粗いレイアウトのいくつかは、HTMLを使用してまだダウンしていますが、面白いビットはクライアントサイドで動的に行われます。

しかし、GWTは手書きではなく、生成されたjavascriptを使用します。これを手で行うのは苦しいです。

Answer 3

ExtJS、YUI、dojo ...基本的にはあなたが私たち（私の職場では）多くの多くの大&小規模なアプリケーションのために成功し、このようなアプローチを使用し

を記述しているような実装のアプリに手を提供するフレームワークそれは虐待され、使用されていない場合は...一般的には道場（Zend Framework（あなたがすべてではPHPの世界を気にしている場合）道場の要素を持つ便利な統合を提供する）

にいくつかのケースでは、ExtJSに+ jQueryの上で我々のアプリのほとんどを基づか単にそれを使用したり、クールネスファクターをバンプするために、それはすばらしいツールです。

適切な設計では、それ自体がアプローチとして重くも遅くもありません。

Answer 4

私は手作業で行っています。それは一種の痛みでしたが、いくつかの逆さまがあります。これは、フォールバックがほとんど意味をなさないリッチインターネットアプリケーションにのみ適しています。私は、特に、Cappuccino Atlasのようなフレームワークが到着した後に、JavaScriptを必要とするアプリケーションがますます増えていくだろうと考えています。

Answer 5

恐ろしいですね。開発が難しい。デバッグが難しい。あなたが望む機能を得るのは難しいです。できるだけシンプルなWebアプリケーションを維持し、より複雑なものが必要な場合は通常のGUIアプリケーションを使用することをお勧めします。

Answer 6

ウェブ開発者が「Javascriptコードが正常に動作していると思われる」というあなたの主張は、同意するのが難しいものです。私の経験では、Javascriptはほとんど常にあなたがそれを供給することができるすべての時間とエネルギーを吸うブラックホールです。 PrototypeやScript.aculo.usのようなフレームワークでは、多くのことが改善されましたが、あなたの疑問と同じようにまだ固まっていません。

2つの主な問題は、ブラウザのサポートと2つの開発時間です。アプリケーションの作業負荷の大部分を処理するために制御できないアプリケーションに頼っています。これがブラウザへのほとんどのマイナーアップデートでも壊れるかもしれないという事実は、私に関係しています。 HTMLサーバー側を生成することは、このリスクを大幅に緩和します。豊富なJavascriptフロントエンドの開発は、時間がかかり、デバッグが難しく、使用可能なブラウザの幅広いテストでも同様に困難です。

これらの懸念は真実ですが、クライアントサイドのJavascriptで素晴らしいユーザーエクスペリエンスを達成できるという事実は無視できません。私が以前に触れたフレームワークは、1〜2年前には夢でもなかった機能性を公開しており、その結果、場合によっては開発コストを前払いにしています（フレームワークが効果的に実装されると大幅に短縮されることもあります）。

私は、そのルートに行くという決定がよく考え出されている限り、Javascriptで動作するUI用のアプリケーションがあると思います。この戦略を使用するUIの可能性が素晴らしいという事実ではないので、私たちはこれについて議論しません。 Webベースのデータを使用するWebベースのアプリケーションは、完璧な候補者（RSS、REST Services）です。リレーションシップデータベースや複雑なWebサービスに襲われるアプリケーションは、必然的にサーバー側との緊密な連携を維持する必要があります。

私の2セント。

Answer 7

私があなたの質問を正しく理解していれば、あなたはExtJSのようなものを使っている開発の種類を指していると思います。 Extでは、HTMLを書くのではなく、デスクトップ上の開発GUIアプリに似たテクニックを使用して、JavaScript全体でアプリケーション全体をデザインします。

現代のツールキットのほとんどは、ほとんどのブラウザの特徴をほとんど取り除いています。あなたは間違いなくクロスブラウザーのレンダリングの問題に遭遇することはありますが、すべてのJSを自分で書き込もうとすると、それほど大きな問題ではありません。速度はIE6でも許容されるはずですが、一般的にはSafari、Chrome、Firefoxの最新バージョンでパフォーマンスが向上します。 （IE7や8について十分には分からない）

あなたはURLとその共有能力に関して有効な点を挙げました。データを共有するユースケースの外でも、これはアプリケーション内の場所をブックマークするために重要です。アプリケーションの状態を保存し、それを再構築できるテクニックがありますが、私が知っている限り、これはまだ簡単ではありません。こうした理由から、リッチWebアプリケーションが必要でない状況でのWebアプリケーションの使用を避けることは理にかなっています。簡単なWebアプリケーションは、デバッグ、テスト、およびメンテナンスを簡単に行うことができます。

しかし、リッチなWebアプリケーションが大いに役立つ状況があります。たとえば、多くの内部エンタープライズデスクトップアプリケーションをリッチなWebアプリケーションに書き換えることができます。 Webアプリケーションへの移行を容易にするデスクトップアプリケーションと同様のルックアンドフィール、ウィジェット、インタラクションパターンを提供できます。データの操作（電子メール/ニュースリーダー、会計アプリケーションなど）を伴う外向きのアプリケーションもまた最適です。

Answer 8

デスクトップを制御できる内部で使用されるビジネスアプリケーションの場合は、javascriptが理にかなっています。

消費者がどのブラウザを使用しているのかわからない外部/公開アプリケーションの場合、シンプルにして、できるだけ使用しないでください。

Javascriptがフレームワークのために動作していると言えば、それは正確ではありません。 Internet Explorer 6はSafariのように広く普及しています。 FF 2.xと1.xでもある程度は、消費者市場のかなりの部分を占めています。

それに加えて、誰もが高速インターネットを持っているわけではありません。これは、多くのこれらのフレームワークの要件です。さらに、ほとんどのライブラリはIE 7で動作しますが、ほとんどの操作では犬です。

ライブラリのサイズには、最大1MBのjavascriptをクライアントに注入するような数の.netコントロールがあります。おばあちゃんに送ろうとしています。

最後に、電話機がプライマリインターネットアクセスデバイスとしてユーザーを迎えています。残念ながら、キャッシュのサイズは小さく、ほとんどの場合、クールなjavascriptのものはうまく動作しません。

Answer 9

YUI劇場は、私はあなたの質問に非常に関連性があると思うのビデオを持っている - 私は強くタイトルは少し誤解を招くおそれがあり、彼は実際には非常に問題の話それを

High-performance JavaScript: Why Everything You've Been Taught Is Wrong

を見ることをお勧めします直面している。

Answer 10

私はハイブリッドアプローチを実装するのが好きです。ページが最初に要求されたときは、URL /クエリー・ストリング/ポストから推測できる情報を入力する必要があります。それ以降の状態の変更は、Ajaxを使用して照会および更新できます。

多くの人が、単純にページを読み込み、javascript/ajaxに読み込みの作業をさせるというアプローチをとる傾向があります。この結果、クライアントはページがロードされるのを待ってから、クライアントがデータのロードを待機します。

サーバーにその初期データを読み込ませ、すべてのUI要素を読み込ませるほうがずっと良いです。