プログレッシブエンハンスメント対シングルページアプリ
An Event Apart と呼ばれるボストンでの会議から戻ってきました。
講演者の間で本当に人気のあるテーマは、 プログレッシブエンハンスメント のアイデアでした。サイトのコンテンツはHTMLで記述し、JavaScriptは動作を向上させるためにのみ使用する必要があります。
スピーカーが進歩的な強化のために与えた議論は非常に説得力がありました。古いブラウザや低帯域幅のネットワーク上のデバイスをサポートするための堅実なパターンであるだけでなく、HTMLはJavaScriptよりもはるかにうまく失敗します（つまり、サポートされていないマークアップは無視されますが、ブラウザが実行中に例外をスローした場合スクリプト-あなたは夢中になっています）。
Jeremy Keith はこれについて特に洞察に富んだ講演を行いました。
しかし、BackboneやAngularなどの単一ページWebアプリはどうでしょうか？これらのフレームワークの背後にある全体的なデザインは、コンテンツをHTMLからJSON APIのようなものに移動するように開発者をプッシュしているようです。
プログレッシブエンハンスメントとシングルページWebアプリの2つのデザインパターンを統合することはできません。一方が他方よりも優れている場合はありますか？それとも彼らは敵対的な技術すらありません、そして私は私のメンタルモデルでここに何かが足りないのですか？
単一ページのアプリは進歩的な拡張の砂の中に線を引くように私には思えます。実装と機能が何十年も前にブラウザー間で異なるという事実を回避しようとする前に、SPAは、特定のサイトのほとんどの訪問者が会うことに合理的に同意できる特定の基準があると想定しています。この2つが対立しているとは思わない。 SPAの開始後も、<video>タグで開始し、独自の機能豊富なプレーヤーをその上に重ねるなど、引き続き機能を強化することができます。
次に、スクリプティングを無効にした訪問者がいますが、彼らは何をしているのか知っています。 「このサイトにはスクリプトが必要です」というメモを除いて、開発者がこれらのビジターのために逆方向に曲がるべき理由はわかりません。それを許可する場合は、CSSが無効になっている訪問者にも対応してみませんか？無効になっている画像はどうですか？これらはコアWebテクノロジーです。作品を選んだり選んだりするときに、完全に機能するウェブ体験を期待するべきではありません。
車の類推なしに逃げないようにするために、特定の機能が気に入らないと判断した場合でも、車が機能することを期待すべきではありません。 「ヘッドライトを無効にしたので、訪問する可能性のあるすべての場所に125フィートごとに街路灯を設置してください。」ヘッドライトがなければ、私の車はほとんどの時間機能しますが、訪問できない場所もあります。
SPAは、従来の要求/応答ページモデルに適合しないアプリケーションを作成する場合に最も役立ちます。最近の傾向として、通常のWebサイトがWebの要求/応答サイクルにうまく適合している場合でも、SPAとして記述される傾向があります。彼らがしていることは、愚かな努力です。これらのWebサイトが好むことは、多くのバグと少ない機能を備えたWebブラウザーの不十分な再実装です。
プログレッシブエンハンスメントとSPAのアイデアは、これらのばかげた単一ページのappli-websiteで相互に排他的ではありません。コンテンツネゴシエーション（Acceptヘッダーなど）を実行するには、JavaScriptが必要なだけです。これにより、SPAのJavascriptが、事前にレンダリングされたHTMLページの代わりにレンダリングできるJSONリソースを受け取ります。この種のWebサイトSPAの問題は明白です。サーバーとクライアントの両方でWebサイトのレンダリングを重複して実装する必要があります。
真のWebアプリケーション、つまり標準の要求/応答パターンに適合しないため、本当にSPAである必要があるアプリケーション。実際のアプリケーションでは、アプリケーションを移植性の高い方法で作成するためのテクノロジープラットフォームとしてブラウザを使用しているだけなので、プログレッシブ拡張ははるかに困難です。スクリプト言語は、機能強化のためにオプションでボルトで固定できるだけではなく、真のWebアプリケーションの重要な部分です。一部のプログレッシブ拡張技術はまだ機能しますが（たとえば、フラッシュビデオ/オーディオを<video>/<audio>タグで置き換える）、真のWebアプリケーションはベースラインとしてJavaScriptを必要とします。
単一ページのウェブアプリとプログレッシブエンハンスメントはほぼ敵対的だと私は信じています。 HTMLがjson apiから取得したデータからクライアントで計算される場合、正常に低下することはほとんどありません。ただし、よりリッチで快適なユーザーインターフェイスを提供できます。
アプリケーションをクロールして静的バージョンを保存するボットを設定できます。この手法は、JavaScriptを使用せずにブラウザにHTMLを提供するために使用できます（視覚障害者や検索エンジンボットで使用されます）。これは投資であるため、実際には要件によって決まります。
特定の会社の人事管理Webアプリを作成していますか？あなたは優雅な劣化を必要とせず、SPAはより簡単に構築できます。会社は特定のブラウザの使用を強制する場合があるため、実行するテストが少なくなる場合があります。
アクセシビリティ要件と検索エンジンの可視性のニーズに関連する公開Webサイトを作成していますか？次に、サーバーでHTMLを作成することを検討してください。または、予算に応じて、静的バージョンのSPAを作成します。
プログレッシブエンハンスメントをどの程度使いたいかによって異なります。これは、ハードで高速な一連のルールではなく、設計パラダイムです。
SPAフレームワークを使用している場合、Javascriptを許可することは当然のことだと思います。ただし、ページを拡張するために作成するJavaScriptは、フレームワークが作成できるHTMLをすべて処理できるほどスマートでなければなりません。
また、最近のブラウザーリリースでの最新のCSS機能の利用や、HTML5からHTML4へのデグレードなど、他のPEテクニックを活用することもできます。
プログレッシブエンハンスメントとシングルページアプリは共存できます。この方法でアプリを構築することについて私が聞いた最も説得力のある2つの主張は次のとおりです。
- フォールトトレランス完全にダウンロードされているが参照されたスクリプトでのHTMLファイルのダウンロードが、ネットワーク接続がドロップイン（モバイルネットワークで可能）するため完全にダウンロードできない場合
- 可能性改善された知覚パフォーマンス（レンダリング開始時間を短縮することにより）初期ページ読み込み時
サーバー側のレンダリング（これはユーザーのためであり、SEOの理由だけではありません）と切断マスタードは、最新のクライアント側のJSフレームワークで段階的に拡張されたシングルページアプリの構築に役立つ2つの手法です。
一部のクライアント側JSフレームワークは、他のサーバー側レンダリングよりも簡単にサーバー側レンダリングを操作できます（サーバー側レンダリングソリューションとフレームワークの組み合わせによっては、サーバーレンダリングページと同じように、機能するSPAが生成されないことに注意してくださいエンドユーザーではなく、検索エンジンの消費のみを目的としています）。
執筆時点では、React.jsとEmber（次のFastBootを含む））は、サーバーサイドレンダリングをファーストクラスシチズンにするか、サーバーサイドレンダリングを作成しようとしている2つです。サーバー側でレンダリングされたページは、クライアントブラウザーで解析された場合でも、機能するSPAです。
ページの負荷の軽減はサーバーとネットワークにとっておそらくかなり良いと私は思います。より多くのSPAが正しく使用されることを望んでいます。
ただし、これには2つのことが必要です。
1）すべてのリンクを初期読み込み時に標準のリクエスト/レスポンスリンクとして設定し、SPAフレームワーク/ライブラリーにブラウザーが読み込まれ、SPSサポートが利用可能であることをJSエンジンが識別したら、これらを更新された（インタラクティブ）バージョンに置き換えます。これは本当に大きな拡張です。 JSは既存のhtml Webサイトの上にロードされます。これは、検索エンジン、支援技術、および古いブラウザーに適しています。
そして
2）サーバーは、/ foo/bar/jsonやfoo/barなどのルートに応答して、正しいフォーマットを提供する必要があります。現実的には、レイアウトとパーシャルですべてをラップして最初のページを取得する場合、2ページ目以降のレイアウトとパーシャルを介してすべてを取得できるはずです。
ここにはかなりの作業があります。確かに、フルスタックを制御できる場合は、2つのテクノロジーのバランスを取ります。