和田憲幸のブログ

ちなみによくJavascriptとJAVAを混同している方がいますが、まったく別物なのでご注意ください。もう全然ちがいますから。Javascriptはジャバと略さないでjsとかジャバスクリプトって言います。ちなみにジャワティーもJAVA TEAって書きます。いや、全然関係ないんですけどね。ジャバティーじゃないですから。

完全に脱線しましたが、私がjsを好きな理由。それはとても簡単にプロセスが完結できるから。というか負荷を分散できたり、サーバサイドに値を渡さなくても処理ができる点なんですね。最初に使ったのはメールフォームだったと思います。メールフォームの場合、文字コードなど多くの問題があって、それを全てサーバサイド側でチェックすると、エラーがあった場合、前のページに戻ったりなんだったり、処理が複雑になるうえにユーザビリティも低下するわけです。

ユーザビリティとしてのJavascript

なので、クライアントサイドでサクサクッとレスポンスを返すことができるJavascriptは非常に魅力的でした。もちろん文字コードもサーバサイドと違って大きく干渉されません（※Mac IEを除く）。なんで、チェック系だとかプレビュー系は断然jsで処理したほうがいろんな意味で便利だったんですね。

Perlとjsが既に半々

で、いま作ってる携帯サイト用のCMSに至っては、処理の3割～4割がjsで行われています。現在、メールフォームを簡単に作れる機能を作ってるんですが、それに至っては８割以上がjs側で処理されています。だって楽なんだもん…。DOMとAjaxがもたらした恩恵は計り知れず、Web開発の根底を揺るがしたと言っても過言ではない。これは楽だよ。

CMSのメールフォームの例

いま作ってるメールフォーム生成に関してどういう処理を行ってるかっつーと、HTML側で選択された値、入力された値をjsから参照してformタグとinputタグ、selectタグを生成します。その生成したタグを単純にhideされたtextareaに渡しているだけ。それをPerlやPHPでやろうとすると、まぁメンドクサイ。文字関連の処理もいろいろとトラブルがつき物ですしね。ようは通常３画面使う処理を１画面のバックグラウンドで実行できるのです。ほんとステキですよね。

リスクも少なくない

ただjsを扱う上でのリスクも少なくない。jsはどこかの処理でつまずくと以後の処理全てでつまずきます。なのでエラーを確実に出さないように書かないとダメなんですね。オブジェクトを生成せず、または生成するまえにオブジェクトを参照しようとすると、エラーになりますが、エラーになったとしても一般的なブラウザの設定ではエラーになったことすら確認ができません。Webアプリケーションではたまにそういう事があるんですよね。

onloadでローディングが終わるまでさわれない

で、本題の画像の話になるんですが、一番多いトラブルでonloadやインクルードされるタイミングでのエラーを防ぐためにonloadが完了するまでのあいだ、触らせない！という技があります。透過したdivを最前面に100%×100%で配置して、onloadがキックされたタイミングでhiddenにするってだけなんですが。一般のサイトでコレをやったら単純にレスポンスが悪くなるだけですが、Webアプリではこの処理はほぼ必須と言えます。トラブルが起こるより多少レスポンスが落ちたほうがいいですからね。

デモはコチラから「wadasamadaisuki」でログインしてみてください。
※js使いすぎのためchromeのスゴさが群を抜いているのを実感できます。

と、言うことで長くなりましたが、コイツもライブラリにしてぇなぁ！
公開したいものが溜ってきました・・・。

ともあれJavascriptさんには本当にお世話になっています。ありがとうJavascript！