最近 jQuery Mobile のフレームワークを使って、今まで作ったWebアプリ(かっこよく言えば・・・ですがw)をスマートフォン向けに手を加えています。
jQuery Mobile をかじり立ての頃は、なんとなく、最終的に結果を吐き出すHTMLテンプレート部分をスマートフォン用に用意すればいいだろう？、なんて簡単に考えていたんですが・・・、それは甘い考えだったようです(ーー;;;

なんというか、極端に考えれば簡単なWebアプリなら、サーバーサイドでHTMLビューを作成してクライアントにHTML出力を返す、というような工程はハッキリ言って要らないんじゃない？ と。サーバーサイドのプログラムを単にJSON形式を返す、簡単にいえばREST形式のウェブAPI仕様にしてしまえば、HTMLビューは、クライアントサイドのJavascript(ECMA Script)で全部任せることができる。

クライアントサイドJavascriptにHTMLビューの作成を任せてしまえば、サーバーサイド側の実装が簡潔になるし、メンテもラクになる。今時のクライアントマシン(モバイル端末を含めて)は例えエントリ向けであっても性能が無駄に？性能が向上しているので、スペック的なパフォーマンスは考えなくていい。

サーバーサイドのプログラム(PHPであれ、PerlのCGIであれ)は、単にデーターベース情報の出し入れを仲介するだけ、と割り切ってしまえば・・・とか思いましたが・・・クライアント側にJavascript実行環境が無ければ、全く機能しないことになる。そういう作り方が、はたして良いのか悪いのか。

どの程度までクライアントサイドにHTMLビューを任せればいいのか、そのバランスがなんとも悩みどころ。。。というか、サーバーサイドでHTMLビューの作成がどうしても必要なケースって僕が作る用途では少ない気がする。円グラフや棒グラフなんかも、HTML5で描けちゃうし。

それに、なんと言っても、DOM + jQuery の方がHTMLを組み立て易いし、はるかに簡単！
結局、僕の中では、Webアプリはクライアントとデータ(データーベースとかクラウド上の何かしらのデータ)をくっつけるグルーみたいなもん、という認識に変わりつつある。jQuery Mobile は、そのきっかけになった気がする。

HTMLビューを単にjQuery Mobile用のHTMLに書き換えただけのプログラム(CGI/Perl)。スマホならページナビゲーションは、「次のXX件を読み込む」でAjaxとかで続きを読み込むのが普通かな。