ステートフルJavaScriptの使い所って結構限られてるんじゃなイカという話

クライアントサイドJavaScriptでのビューの作り方4つ - id:anatooのブログ

このエントリについての雑感。
結論から先に言うと、javascriptテンプレートエンジンやデータバインディングを使いまくったサイトを作っても検索エンジンへの対応を考えると面倒だし用途によっては凄い無駄な労力を使うことに成るんじゃないかっていう。DisられてるDOM操作が最適解な場合もけっこう有るんじゃないかっていう内容。
まあ、最初からwwwで勝負してる人にとっては当たり前過ぎる話かもしれないですが、企業イントラのWebアプリ屋がwww上のWebアプリを作るときに見逃しやすいんじゃなイカということで、このへんで右往左往した自分の経験を書き綴ってみる。

ステップ1. わーいJSでMVCアプリ作って、それはとっても嬉しいなって

会社で「フルスクラッチでWebアプリ作って（ただしぼっちで）」と言われたので、Jersey使ってWebAPIをサクッと組み上げ、ちょうど読んでた

ステートフルJavaScript ―MVCアーキテクチャに基づくWebアプリケーションの状態管理

を参考にして、WebAPIから取得したJSONデータを簡易的にjsオブジェクトへバインドしてbackbone.jsでテンプレートにはめ込み……というモックアプリ（使用するデータがモックなだけで、RDBからデータをCRUDして表示するという基幹機能はほぼ完成状態）を作った。

ここまでは、「ヒャッハー、WebAPIをこんなに簡単に作成できるJersey最高！JSフレームワークとの相性最高！」というよくある話だった……

「で、Googleクローラはこれちゃんと読んでくれるの？」

という疑問に気付くまでは（気付くのが遅いって言ってもイントラの経験しか無かったからしょうが無いんじゃよー）。

ステップ2. 宜しい、ならばhijaxだ

そこでAjaxなサイトがクローラに対応する方法についてGoogle先生にお伺いを立ててみたところ

「AJAX クロール: ウェブマスターおよびデベロッパー向けガイド」

各 AJAX URL の HTML スナップショットをサーバーで提供する。これが、ユーザー（ブラウザ）に表示されるコンテンツになります。AJAX URL は、ハッシュ フラグメントを含む URL です。たとえば、www.example.com/index.html#mystate では、#mystate がハッシュ フラグメントになります。HTML スナップショットは、JavaScript の実行後にページに表示されるすべてのコンテンツです。

http://support.google.com/webmasters/bin/answer.py?hl=ja&answer=174992

（2013/03/02 追記、上記ドキュメントは「Googleウェブマスターツール」のものです。Googleクローラについてはある程度ajax対応済みとのこと）

とのお告げがあった。つまりは「AjaxでサーバからJSON取ってきてクライアントサイドで動的にhtmlを組み上げる」と同時に「サーバ側でHtmlを生成して表示する仕組みも作ってね」という事だ。そういうのって昔言ってたhijax（参照: GoogleはAjaxに弱い。 SEO見習いの覚書）と何か違うの？

いやまあ、Google先生のおっしゃることなんで検討しますけどね。なんか凄い蛇足感っていうか将来にわたってjavascript使ったクライアント側で動的生成する画面と、サーバ側で生成する画面の両方に相互矛盾が出ないように開発・メンテしないといけないんですよねそうですよねそうですか。
いや結構本気で両立しようと頑張ったけどなんかこれだけ労力かけてやることもないよなと。人手足りないし。

ステップ3. 私は如何にして心配するのを止めてpjaxを愛するようになったか

で、サーバ側で全ての画面について静的htmlを生成するようにしたところで、もうjavascriptでデータバインディングとかjavascript MVCとかどうでも良くなっちゃってさ……先進的な設計を求めれば求めるほど、ドツボにハマらずには居られない……私達三流IT屋って、そういう存在なんだね……私ってほんとバカ。

とかたそがれてても給料は出ないので（比喩表現、金額はともかく給与支払はしっかりした所に居る）pjaxライブラリを使って静的htmlをajaxっぽく表現する方向に転換。まあ、平たく言うとDOMの差し替えっていう所まで退歩した訳だ。

defunkt/jquery-pjax · GitHub

で、上記のライブラリを使って静的htmlをajaxっぽく表示できるようにした。まあIEから見たら何の工夫もないレガシーhtmlサイトなんだけど。ついでだしdatatablesを使ってajaxで生成していた検索結果一覧とかも強引にサーバ側で生成してしまえ。何この本末転倒なレガシー加減。
あと、もう呼ばれなくなったWebAPIが何か盲腸のように残ってしまったけど、モバイル対応とかで後々使えるんじゃないかな……たぶん。とりあえずapache側で塞いどく。

まとめ

とりあえず、googleクローラがjavascriptの実行に対応してない現状では、javascriptフレームワーク使ってサーバからのデータを基にhtmlを動的生成するという設計のメリットより、クローラ対応のためのメンテコストによるデメリットが大きい場面は結構あるはず。
もちろん、そういう設計が有利な場面（たとえば認証を通った後でしか表示されない画面でgoogleクローラのことを考えずに済み、かつクライアントサイドで複雑な処理を行う場合など）もあるはずだけれど。

その辺の見極めをせずに面白そうな技術をガンガン投入して行ったらそれなりに苦労しますよというお話でしたとさ（まあ個人的には結構面白かったからいいけど。給与査定とか色々な世のしがらみが無ければもっと良いんだけどな）。

これで「明後日からgoogleクローラがajax完全対応！」とか言われたら泣く。超泣く。

追記

元々「Web系の経験が深い人はこのへんで悩んで無いんだろうか」とか「上で書いた経緯は本当に最適解だったんだろうか」とか書こうとしたはずなのに書いてるうちにすっかり忘れてた。