プログレッシブエンハンスメントとシングルページアプリ

ボストンで開催されたAn Event Apartというカンファレンスから戻ってきました。

スピーカーの間で本当に人気のあるテーマは、プログレッシブエンハンスメントのアイデアでした。サイトのコンテンツはHTMLに入れ、JavaScriptは動作を強化するためだけに使用する必要があります。

スピーカーがプログレッシブエンハンスメントに対して行った議論は非常に説得力がありました。古いブラウザや低帯域幅のネットワーク上のデバイスをサポートするための堅実なパターンであるだけでなく、HTMLはJavaScriptよりもはるかに優雅に失敗します（つまり、サポートされていないマークアップは無視されますが、ブラウザが実行中に例外をスローした場合スクリプト-あなたはうんざりしています）。

ジェレミー・キースはこれについて特に洞察力に富んだ講演を行いました。

しかし、BackboneやAngularなどの単一ページのWebアプリはどうでしょうか。これらのフレームワークの背後にある設計全体が、開発者をコンテンツをHTMLからJSON APIのようなものに移行させるように思われます。

プログレッシブエンハンスメントとシングルページWebアプリの2つのデザインパターンを融合させることはできません。一方が他方より優れている場合はありますか？それとも、敵対的な技術でさえないのか、ここに私の精神モデルで何かが欠けていますか？

単一ページのアプリは、プログレッシブエンハンスメントの砂の中に線を引くように思えます。実装と機能が何十年も前のブラウザー間で異なるという事実を回避しようとする前に、SPAは、特定のサイトのほとんどの訪問者が満たすことを合理的に同意できる特定のベースラインがあると仮定します。この2つが対立しているとは思わない。<video>タグを開始し、その上に独自の機能豊富なプレーヤーをレイヤー化するなど、SPAの開始後も引き続き拡張を続けることができます。

次に、スクリプトが無効になっている訪問者がいますが、彼らは自分が何を始めているかを知っています。「このサイトにはスクリプトが必要です」というメモは別として、開発者がこれらの訪問者のために後ろを向く必要がある理由はわかりません。それを許可したら、CSSが無効になっている訪問者にも対応してください。無効な画像はどうですか？これらはコアWebテクノロジーです。作品を選んで選択するときに、完全に機能するWebエクスペリエンスを期待するべきではありません。

車のアナロジーなしで逃げないようにするために、特定の機能が気に入らないと判断した場合に車が機能するとは考えないでください。土木技師に「ヘッドライトを無効にしたので、訪問するすべての場所に125フィートごとに街路灯を設置するようにしてください」と言うことができました。ヘッドライトがなければ、私の車は多くの時間動作しますが、いくつかの場所は訪問できません。

SPAは、従来の要求/応答ページモデルに適合しないアプリケーションを作成する場合に最も有益です。最近の傾向として、通常のWebサイトはWebのリクエスト/レスポンスサイクルにうまく適合している場合でもSPAとして記述されており、私見では愚かな努力が行われています。これらのWebサイトが好むのは、バグが多く機能が少ないWebブラウザーの再実装が不十分なことです。

プログレッシブエンハンスメントとSPAのアイデアは、これらの愚かな単一ページのアプリWebサイトにとって相互に排他的ではありません。事前にレンダリングされたHTMLページの代わりに、SPAのJavascriptがレンダリングできるJSONリソースを受信するために、コンテンツネゴシエーション（つまりAcceptヘッダー）を行うためにJavaScriptが必要です。この種のWebサイトSPAの問題は明らかであり、サーバーとクライアントの両方でWebサイトのレンダリングを重複して実装する必要があります。

真のWebアプリケーション、つまり、標準の要求/応答パターンに適合しないため、SPAでなければならないアプリケーション。プログレッシブ拡張は、アプリケーションを移植可能に記述するためのテクノロジープラットフォームとして実際にブラウザを使用しているだけなので、真のアプリケーションにとってははるかに困難です。スクリプト言語は、拡張のためにオプションでボルトで固定できるものだけでなく、真のWebアプリケーションの重要な部分です。いくつかのプログレッシブエンハンスメント技術はまだ機能しますが（例：フラッシュビデオ/オーディオを<video>/ <audio>タグで置き換える）、真のウェブアプリケーションはベースラインとしてjavascriptを必要とします。

単一ページのWebアプリとプログレッシブエンハンスメントは、ほぼ敵対者だと思います。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を生成しないことに注意してください-users）。

執筆時点では、React.jsとEmber（今後のFastBootを含む）は、サーバーサイドレンダリングをファーストクラスの市民にした、またはしようとしていることを知っています。サーバー側でレンダリングされたページは、クライアントブラウザーで解析されると、引き続き機能するSPAです。

私は、ページ負荷の削減は、おそらくサーバーとネットワークに非常に適していると考えています。より多くのSPAが正しく使用されるのを楽しみにしています。

ただし、これには2つのことを必要とするという見解はありません。

1）すべてのリンクを初期読み込み時に標準の要求/応答リンクとして設定し、SPAフレームワーク/ライブラリをブラウザが読み込まれ、JSエンジンがSPAサポートが利用可能であると特定したら、これらを更新された（インタラクティブ）バージョンに置き換えます。これは本当に進歩的な機能強化です。JSは既存のhtml Webサイトの上にロードされます。これは、検索エンジン、支援技術、古いブラウザーに適しています。

そして

2）サーバーは、正しい形式を提供することにより、/ foo / bar / jsonやfoo / barなどのルートに応答する必要があります。現実的には、レイアウトとパーシャルですべてをラップして最初のページを取得する場合、2ページ目以降のレイアウトとパーシャルでもすべて取得できるはずです。

ここにはかなりの作業があります。確かに、フルスタックを制御できれば、2つのテクノロジーのバランスが取れます。