jQuery Mobile 1.0 日本語リファレンス

アルファ版からは当然ながら大きく変わっていて、特にAPI関連は、まったくの別物。放置していて申し訳ありませんでした。

jQuery MobileではjQueryの知識も必要になる部分が(当然ながら?)結構あり、こちらも直近の更新はキャッチアップしてないなと思ったり。余計なことですが、名前がそのまんまな「jQuery日本語リファレンス」は前職時代に自分が作って遺してきたものです。後輩の子たち、全然更新してくれないな…とか。

最近jQuery Mobile関連の仕事を続けてもらいまして、特に米国では急速にユーザが増えていることを実感します。ギャラリーに上げられるサイトも増えていて、アプリ(多分、PhoneGapを使用)でもjQuery Mobileを利用したものが散見されるようになりました。

自分でも、趣味サイト1本作ろうかと画策中。楽しみです。

[PR] jQuery Mobile リファレンスが書籍として発売されることになりました

jQuery Mobile ポケットリファレンス

森 直彦 (著)

技術評論社 (2012/1/20)

新品 ￥2,709

Related posts:

1. [jQuery Mobile] 1.0.1公開
2. [jQuery Mobile] チートシートつくりました
3. [jQuery Mobile] ページイベント・チートシート

ベータ2のリリース内容

今回のリリースでは、ライブラリに大幅な向上があります。

• ウィジェットの切り離しによって、必要なコンポーネントだけを選択取り込み可能に
• DOMキャッシュ機能により、メモリ使用量の低減
• ページのプリキャッシュ・オプション
• ページ構造が柔軟に
• チェックボックス、ラジオボタンのデザイン向上
• JavaScriptによる動的ページを作る場合の拡張機能追加

ベータ1リリースから5週間の尽力で、正式版リリースに大きく前進しています。

ベータ3

正式版のRCとしてバグフィックスやパフォーマンス調整に入る前に、更に追加したい幾つかの重要な機能が残されています。来月リリース予定のベータ3では pushState のサポートや、切り替え動作の Firefox や Opera での向上、開発者向けの拡張機能実装などが含まれます。

jQuery Mobile 1.0では、ベースとなる jQuery core の 1.6.2 以上が必須となることに注意してください。jQuery coreでリリースされている更に上のバージョンもサポートされますが、基本線はこのバージョンを基にしています。

サポート対象プラットフォームの更新

ベータ2では、OperaとFirefox向けのCSSサポートを強化しました。また、Android 2.3搭載モバイルとHoneycombタブレット、HP Palm WebOS 3.0タブレットをサポート対象としています。更にNokia S60以降のデバイスをBグレードに加えました。

Nokia S60以降をBグレードとしたのは、これらの端末がハッシュの変更イベントを正しく検知しないためです。つまり、Nokia端末ではAjaxを使ったページ切り替え機能のような拡張機能が動作しないことになります。

この段階で、jQuery Mobileは現在使われている大部分のデスクトップ、スマートフォン、タブレット、電子リーダー上で動作するようになりました。加えて、プログレッシブ・エンハンスメント手法を採っていることで、古いブラウザ上でも動作します。ここでサポートしている広範囲のプラットフォーム上で、ユニヴァーサルなアクセシビリティを担保することが出来ています。

詳しくは、更新した jQuery Mobile 日本語リファレンス：サポートするプラットフォーム 参照。

ウィジェット：分離により柔軟なビルドが可能に

ページプラグインからウィジェットを「分離」させることは長年の課題でしたが、遂にそれが実現しました(参照 1 2 3)。「分離」とは、実際にどういうことか。各ウィジェットやユーティリティは、各個のスクリプトファイルに分割されています。しかし、ページプラグインが全ての公式プラグインをページ上にマークアップされていないかどうか確認するために、結局全てのプラグインファイルを読み込む必要があったのです。これによって、不要なプラグインを外すとエラーを起こすことになってしまいました。今後のウィジェット追加に際しても、非常に良くない慣行です。

今回のリリースで、全てのUIウィジェットはjQuery Mobileライブラリから完全に分離されました。そのため、もし特定のプロジェクトにおいて不要なプラグインがあれば、それを単純に削除することが出来ます。この変更によって実際に必要なプラグインだけを取り込めば良くなり、ダウンロードされるライブラリのサイズを劇的に小さくすることが出来るでしょう。現在、更に完全な分離が進められています。現時点で、次のファイルは分離されていますので、カスタム・ビルドの際に不要なものは取り除くことが可能です。

• page header/content/footer
• collapsible
• controlgroup
• fieldcontain
• fixheaderfooter
• button
• checkboxradio
• select
• slider
• textinput
• links theming
• listview
• navbar
• grid

いくつかのウィジェットは相互に関係しているので、依存関係表の作成も必要になってきます。たとえば、上記の多くのプラグインが動作にはbuttonプラグインを必要としますので、これを削除するには依存関係にある全てのプラグインが不要である場合だけということになります。

こうした推奨依関係表の作成や、分離機能自体も現在なお更新中です。究極的には、この機能はダウンロード・ビルダーに実装されることになると思われます。

“create”イベントの追加

個々のプラグインにウィジェットを適用する作業は、多くの場合、”pagecreate”イベントで自動的にウィジェット自身によって初期化されます。ページ上で該当するウィジェットがあった場合、プラグインスクリプトが自動的にエンハンス処理を行っていました。たとえば、セレクトメニュープラグインがロードされれば、ページ上のセレクト要素は自動的にエンハンスされます。

この処理が、今後は要素に対して “create” イベントを発行することでも可能になりました。これによって、手動で初期化する際の手間が大きく軽減されます。これまでは、コンテンツがAjaxや動的なマークアップによって変更された際、全てのプラグインを手動で初期化する必要がありました。

今後は、マークアップに “create” イベントを発行することで、ページが作られた時同様に必要なプラグインのチェックや処理を自動的に行わせることができます。たとえばログインフォームなどでAjaxを用いてHTMLのブロックを持ってきた場合、このブロックに対して “create” イベントを発行することで自動的に内包する input や button などのウィジェットをエンハンスすることが出来ます。例えば、次のようなコードになるでしょう。

$( ...new markup that contains widgets... ).appendTo( ".ui-page" ).trigger( "create" );

ここで “create” イベントと “refresh” メソッドの違いに注意してください。新しい “create” イベントは、生のマークアップに対して包含する複数のウィジェットを適用します。一方 “refresh” メソッドは(幾つかの)ウィジェットに実装されており、既に適用されたウィジェットに対してプログラムから操作を行った場合などに、見た目の更新をするために呼び出すものです。

たとえば、ページがロードされた後で動的に ul 要素を追加し、そこに data-role=”listview” 属性を指定したとします。この要素に対して “create” イベントを実行させれば、この要素は listview スタイルのウィジェットになります。このリストに、プログラムから更に幾つかのアイテムを追加したとします。その場合は、リストビューウィジェットの “refresh” メソッドを呼び出して、リストの見栄えを更新してやります。

DOMキャッシュ管理機能

従来、Ajaxによるページ遷移時には、移動前のDOMに移動先のDOMを追加していくようになっています。これまで、この追加されたページは全体がリフレッシュされるまで追加されたままになっている仕様でした。そのため、あまりに多くのページを行き来されると、ブラウザ上のメモリを消費して動作を重くさせたり、最悪はクラッシュさせる危険性がありました。

ベータ2では、DOMを小さく保つための簡単な仕組みを実装しています。それは、次のように機能します。Ajaxによってページがロードされた場合、遷移が完了すると以前のページはDOMから一度削除されます。このページにユーザが戻ってきた場合、ブラウザはページ内容をキャッシュから取り出すか、必要であれば再度サーバへ要求するようになります。これが階層化リストの場合であれば、ユーザがリストに含まれないページへ遷移した際に全てのリストページを削除することになります。複数ページを内包したファイルである場合はこの限りでなく、あくまでjQuery MobileによってAjaxで取得されたページに限った動作です。

新しく追加されたページオプション “domCache” によって、以前のようにDOMをキャッシュし続けるか、それとも削除して小さく保つかを制御することが出来ます。初期状態では、この “domCache” オプションは “false” に指定されています。これは、ベータ1以前とは異なりDOMのサイズを積極的に制御しようとします。もしこれを “true” に変えるならば、DOMのサイズに関する問題を自分自身で、複数のデバイスに対してテストする必要が出てくるでしょう。

もしこの “domCache” を各ページ単位で指定したい場合、ページコンテナ要素に対して data-dom-cache=”true” 属性を指定するか、次のようなコードを記述します。

elem.page({ domCache: true});

この domCache オプションはグローバル設定も可能です。

$.mobile.page.prototype.options.domCache = true;

ページのプリフェッチ・オプションの追加

今回追加されたクールな機能のひとつが、このプリフェッチ・オプションです。Ajaxによるページ取得をプリフェッチさせることができます。たとえば、各写真が別個のHTMLページになっているフォトギャラリーを作るとしましょう。スライドショーで前後のページをプリフェッチさせることにより、Ajaxローダが逐一動かずに写真を表示させることが可能になります。使い方は簡単で、ページ上のリンク要素に data-prefetch 属性を指定するだけです。フレームワークがバックグラウンドで自動的にページをレイジー・ロードしてDOMに追加しておきます。jQuery Mobileによるサイト構築時、HTMLページは個別に分けられることを奨励していますが、実際は複数ページのテンプレートやネスト構造リスト(!)を使って、ページ切り替えを速くしようとしている姿を見かけます。このプリフェッチ機能が、そうした手法の代替になることが期待されます。

link text

プログラムから $.mobile.loadpage( url ); を呼ぶことでも、ページをプリフェッチできます。プリフェッチリンクは、当然ながらそこに遷移されない場合でも追加のHTTPリクエストを発生させますので、ユーザが遷移する可能性の高いリンクのみに適用するよう心がけましょう。

グローバル・コンフィグ・オプションの追加：autoInitializePage

ページの初期化処理を更に制御したい開発者のために、新たに autoInitializePage オプションを追加しました。これを false に設定すると、ページ作成時の自動初期化処理が停止し、開発者が手動によるページ初期化を行う前にマークアップを操作したりすることができるようになります。初期状態ではオプションは true に設定されています。

ロード時のメッセージを、実行後に指定可能に

以前は、ロード時のテキストメッセージを初期化オプションとして設定可能なだけで、特定の状況で動的にメッセージを変えることは出来ませんでした。追加機能により、実行時にプログラムから動的にメッセージを変えることが可能です。

$.mobile.loadingMessage = "My custom message!";

スワイプイベント発生の閾値設定追加

スワイプに関するコードは、jquery.mobile.js内でかなりハードコーディングされています。このイベントが発生するための閾値も定数になっていますが、開発者がこの値を調整したい場合もあるでしょう。そのための指定が出来るようになりました。

• scrollSupressionThreshold (default: 10px)
• durationThreshold (default: 1000ms)
• horizontalDistanceThreshold (default: 30px)
• verticalDistanceThreshold (default: 75px)

vClick機能の停止

ベータ1で実装されたvClick機能ですが、テストの結果、様々な問題を引き起こすことがわかりました。そこで、元通りに戻すことになったとのことです。問題について詳しくは、翻訳は割愛します。興味がある方は元記事を。

ページコンテナがオプションに

文書構造をよりフレキシブルにするため、ページコンテナとしての data-role=”page” 属性付きの要素はオプション扱いとなりました。これによって既存のサイト流用や外部コンテンツとのマッシュアップがしやすくなったはずです。

これで page, header, content, footer の data-role 要素は全てオプションとなりました。ここで、ページのコード例を確認できます。

実際背後では、コンテナが無い場合にはフレームワークが自動的にマークアップを追加しています。しかし、実際に記述するマークアップはシンプルに出来るでしょう。ただし、複数ページを包含させるためには、やはりページコンテナは必要となります。

チェックボックスとラジオボタンのデザイン変更

以前のチェックボックスやラジオボタンは、ハイライト時に背景が全て変わっていました。これは、特にチェックリストで複数のアイテムが選択可能な時に、少し目立ち過ぎの感がありました。そこで、デザインをよりスッキリしたものに変更することにしました。

コントロールの新デザインは、ややシンプルなものになっています。チェックボックスやラジオボタンは、タップするとボタン全体がハイライトされるのではなく、シンボルの色が変わるだけになっています。ただし、横方向に並べてグループ化されたチェックやラジオは、依然としてボタン全体が彩色されます。

サポートプラットフォームの拡大

ブラウザのサポート対象拡大に伴い、CSS3によるbackground gradients指定のベンダープレフィックスを追加しました。Opera用(-o)、Internet Explorer用(-ms)のプレフィックスが、通常のルールに追加されています。

background-image: -webkit-linear-gradient(top, #3c3c3c, #111); /* Chrome 10+, Saf5.1+ */
background-image:    -moz-linear-gradient(top, #3c3c3c, #111); /* FF3.6 */
background-image:     -ms-linear-gradient(top, #3c3c3c, #111); /* IE10 */
background-image:      -o-linear-gradient(top, #3c3c3c, #111); /* Opera 11.10+ */
background-image:         linear-gradient(top, #3c3c3c, #111); /* Standard, non-prefixed */

これによって、backgroundのgradients機能が WebKit, Firefox, Opera, Internet Explorer 10, そしてプレフィックスを付けないことによって標準準拠している全てのブラウザで使えるようになりました。以前ブログで書かれたように、一度 -ms プレフィックスを外さなければなりませんでした。これは IE9 が border radius などの機能についてコンフリクトを起こし、Microsoftがこれを修正してくれないためです。このため、WP7やMangoを含む古いバージョンのIEでは、背景色がフラットなものになってしまいます。この問題について詳しくは issue #2046 を参照してください。

コードフォーマットのクリーンアップとJSLint対応

全てのコードフォーマットがjQueryコアのスタイルガイドに準拠したものになりました。これによって、ライブラリが JSLint などバリデーションツールで動くようになっています。

ベータ1からの更新

ベータ1で追加された useFastClick オプションは、削除されています。これは、前述のとおり vclick が使われないようになっているためです。

この他、細かいバグ修正などの変更履歴は元記事参照のこと。

日本語リファレンスについては、徐々に更新していきます。

Related posts:

1. [jQuery Mobile] BartenderプラグインでフッタをiOSアプリ風にする
2. [jQuery Mobile] ActionSheetプラグイン
3. [jQuery Mobile] SEOとユーザビリティを両立させるポイント

jQuery Mobile 日本語マニュアル

jQuery MobileはjQueryコアベースのモバイル端末用フレームワークですが、触ってみてもらえるとわかるようにJava Scriptのコーディングが必要な部分は、ほとんどありません。マークアップを基本に、jQuery Mobileが data- で始まる属性値を探してプラグイン化していくスタイルで、昔自分が作った jGlycy と基本的な発想は同じ。HTML5で data- 属性が使えるようになったことで、きっちり採用になりました。

雑感

しばらくいじってみた感想ですが、「さすが…」の部分と、「やっぱりまだアルファ版」の部分が、結構あります。

基本コンセプトは、分かりやすいものです。Ajaxによるページの切り替え機構も見事ですが、トランジションがスムーズなだけにDLのディレイがモッサリ感じてしまうことも確か。パケット料金がかかることとのトレードになりますが、サイト構造によってはプリロードの機能が欲しいかも。

フォームの制御は、文句無く使うべき。やっぱりネイティブコントロールは、タッチパネルにフレンドリーでないので、操作キツいですから。長めのセレクトリストなどが別ページに自動的にジェネレートされるのも自然だし、開発者は大分助かると思います。

ちょっとひっかかるのは、ひとつはブラウザの履歴制御。ハッシュを書き換えながらやっていくのですが、途中でリロードなどを挟むと上手く繋がらないことが多い感じが。スマートフォン上では余計な操作が減るので問題は大分減ると思いますが、ちょっとストレスです。

その他、現時点では意外とバグが多い印象です。リファレンスに記載されていることでも、実際には動かない機能が幾つか。公式ドキュメントでもデモは実際には説明してあるコードでは無かったり、デモ自体が上手く動いていなかったり。この辺は、日本語リファレンスの方では注意書きを添えたり、割愛してしまったりしました。ベータ版では、ちゃんと仕上げてくると思います。

jQuery UIであまり盛り上がらなかったテーマローラーについては、今後の提供予定に入っています。確かにデフォルトのテーマもすぐに見飽きる感じなので、センスの良い選択肢が幾つかあると嬉しいですが、デザイナーさん次第でしょうか。

最後に、ここで前に説明したレスポンシブ・レイアウト対応の機能もキッチリ入っています。ここは特に今後キモになってくると思いますので、スマホ対応サイト構築時は初手から考慮しておくことをオススメします。

Related posts:

1. [jQuery Mobile] ActionSheetプラグイン
2. [jQuery Mobile] ベータ2 リリースノート
3. [jQuery Mobile] Paginationプラグイン

「F5」でXHR通信結果が更新されない

通常、キャッシュが設定された外部ファイル取り込みは、その期限が来るまでは再通信されません。しかしブラウザをF5やCtrl+rなどで明示的にリロードした場合はその限りではなく、ファイルの再取得が行われるのが一般的です。
しかし、キャッシュ指定の条件によっては、XMLHttpRequestを用いた、いわゆるAjax通信時が発生しなくなってしまうとHttpWatchの記事で伝えられました。
これを検証するために、簡単なプログラムを作ってみます。

検証プログラムの説明

まずは、取り込まれるjsファイルを用意します。
サーバサイドで毎回ジェネレートされる、現在時刻を指定された要素に出力するだけのスクリプトです。

検証用スクリプト

呼び出す度に日時が更新されることが分かると思います。

そして必要なのはキャッシュコントロール。
パケット監視などが出来る人は見ていただけばわかるのですが、パラメータに応じて次のようなヘッダを付与します。

cache=1

キャッシュ有効。Expiresを30日後にし、Cache-Controlのmax-ageも30日間に設定します。

cache=-1

キャッシュ無効。Expiresを30日前にし、Cache-Controlのmax-ageは0とします。

cache=0

キャッシュ指定無し。ExpireもCache-Controlも指定しません。

ついでに、画像も用意してみました。同様にサーバサイドで現在時刻の画像を作成して返します。キャッシュ制御も同じです。

検証用画像

これを、テスト用のHTMLで取り込みます。
スクリプトは、scriptタグによる単純な取り込みと、XMLHttpRequestによるAjax通信の2種類。画像はimgタグで指定しています。
前述の3種類のキャッシュ制御を行うページは、次の通りです。

• キャッシュ無効
• キャッシュ有効
• キャッシュ指定無し

これで、ページを開いた時の時刻(正確には、サーバがリクエストを受け付けた時刻)が表示されるはずです。リロードや再訪問時に、キャッシュが効いていれば日時はキャッシュされた時のままになります。

順に見ていきましょう。

キャッシュ無効の場合

いずれの場合も期待通り、キャッシュは全くききませんでした。
ページ遷移を行った場合も、F5でリロードした場合も、全て最新に更新されます。

キャッシュ有効の場合

動作が分かれました。
通常にページ遷移を行った場合は、Opera10を除き一律にキャッシュが使われる期待通りの動作です。(Opera10はまだbetaのため、最終的にどういった仕様になるかは不明です)
F5などでリロードを行うと、画像やscript要素で取り込んだものは、いずれも再読み込みされます。
しかしXMLHttpRequestでの通信は、ChromeやFFでは再通信が行われるのに対し、IEとOpera9ではそのままキャッシュが有効になってしまいました。これはCtrl+F5のようなスーパーリロードを用いても、変わりません。

キャッシュ指定無しの場合

かなり無軌道になっています。Operaに至っては、通常のページ遷移でも動作に違いが出てしまいました。

ETagについて

StevesSuders氏の検証ではETagについても含まれています。
今回は検証結果を見やすくするために、レスポンス304については確認していません。
氏のページによれば、Safari4はIf-Modified-Sinceを送らずに常に再送信されてしまうようです。

まとめ

1. Expiresを指定しないことは、動作を全く制御しないのと同じこと。可能な限りきちんと、用途にあわせてキャッシュの制御を行うべきです。
2. Ajax通信でキャッシュをされたくない場合(多くの場合、この用途でしょう)、Expiresを過去に指定してキャッシュを無効にしましょう。
3. 或いは、通信にエポックタイムのようなユニークなIDをパラメータに付与し、キャッシュできないようにするのも良い方法です。
4. Ajax通信をキャッシュしたい場合、Expiresをキャッシュしたい期間、きちんと指定しましょう。ただし、その際にはF5でリロードしても更新されないブラウザがいることを知っておきましょう。
5. Operaを対応ブラウザにするならば、バージョン10がどのような仕様になるか注意しておきましょう。

Related posts:

1. [js] 外部ファイルロードを便利、高速に

今回は本書の5章から「へー」と思った、外部スクリプトを他のファイルのロードを妨げることなく取得し、なおかつそのファイルのロードが終わった際に後続のスクリプトが実行されるための方法(複雑)を確認してみます。

SCRIPTタグを減らすテクニック

この技法はまず、jQueryの作者であるJohn Resig氏のblogポスト Degrading Script Tags に端を発します。
まず、次のコードを見て下さい。

<script src="jquery.js"></script>
<script>
  jQuery(document).ready(function($){
    $("div").text("loaded!");
  });
</script>

これを、次のように書けたら幸せだよね、という話。

<script src="jquery.js"></script>
  jQuery("div").text("loaded!");
</script>

これなら、SCRIPTタグが少なくて済むし、コードの依存関係もハッキリする。srcに記述されたファイルのロードが失敗したら中身のコードが実行されない形なら、万が一の場合にもスクリプトエラーにならずに済むと。

次のようなコードを外部ファイル(この例で言えばjquery.js)の最後に加えれば、これが実装できます。

(function(){
var scripts = document.getElementsByTagName("script");
var curScript = scripts[ scripts.length - 1 ];

if ( curScript.executed )
  return;

// ... jQuery ...

curScript.executed = true;
var script = curScript.innerHTML;
if ( script ) {
  jQuery(document).ready(function(){
    jQuery.globalEval( script );
  });
}
})();

もちろんこれは、jQuery以外のライブラリでも適用可能な、非常にクールな手法です。
正直なところ、自分は最初のこのポストが投稿された際にはそれほど感銘を受けなかった記憶があります。それは「スクリプトのロードと実行が連動する」点に私が着目できていなかったからで、単にscriptタグを減らせるシンタックス程度の認識しかありませんでした。
今回改めて読み返してみて、直観的な良い記述方法だなと思いました。

他ファイルのロードブロック問題

見たように素晴らしいテクニックなのですが、この方法にもまだパフォーマンスの観点から改善の余地があるとSteve Sounders氏は指摘しています。
それが、スクリプトのダウンロードが他の外部ファイルのダウンロードをブロックしてしまう問題の回避についてです。

前述のテクニックはjsファイルのロードについては通常の方法であるため、ブロックは発生してしまいます。これを避け、なおかつロード完了とスクリプト実行がきちんと連動するように改良されたスクリプトが、こちらで紹介されています。

function init(){
  jQuery("div").text("loaded!");
}

var domscript = document.createElement('script');
domscript.src = "jquery.js";
if ( -1 != navigator.userAgent.indexOf('Opera')){
  domscript.innerHTML = 'init();';
}else{
  domscript.text = 'init();';
}
document.getElementsByTagName('head')[0].appendChild(domscript);

この呼び出し方と前述のテクニックを組み合わせることで、高速な外部ファイル呼び出しと、そのロード完了に依存するスクリプトの記述が可能になります。

但し、この方法を使うには外部ファイル側に自要素の中身をコールバック(?)する仕組みを埋め込まなければならず、汎用的に使うのは難しくなってしまいます。
将来的にこの記述をブラウザ側がサポートしてくれた場合であればまだしも、現時点では同書の別項で紹介されているOnload技法の方が優れているとしています。
こちらの検証は、また機会があれば。

Related posts:

1. [Javascript] nullとundefinedとfalseと0と空文字と
2. [Web] Google Page Speedでサイトを高速化(3)

今回は個人的に最も良かったパメラさんのGoogle Maps高速化セッションから、大量マーカーの効果的なプロット方法…は、また今度時間がある時にして、その際に彼女がポロっと漏らした「+=は-=に比べて遅いし」を軽く検証してみました。（FOXでアメリカン・アイドルを観ながら）

検証は、ループカウンタをアップしていく/ダウンしていく方法で比較しています。

※2009.09.27
検証プログラムの問題を指摘いただき、末尾に追加してあります。

検証プログラム

/* (1) sum */
var s = get_ms();
for(var i=0; i<arr.length; ++i){
  arr[i] = i;
}
var e = get_ms();
dump(e-s);

/* (2) subtract */
var s = get_ms();
for(var i=arr.length; i>0; --i){
  arr[i] = i;
}
var e = get_ms();
dump(e-s);

get_msはミリ秒を取得する関数、dumpは結果を出力する関数として用意しました。arrは、500,000個の添え字を持つ単純な配列です。
これを、公平を期すために同一プロセス内で交互に実行します。結果の単位はミリ秒となります。

結果

[Firefox3.0.1]

(1) 107
(2) 92
(1) 106
(2) 92
(1) 107
(2) 90
(1) 107
(2) 92

足し算、引き算の順です。

[Internet Explorer 7]
IEはFFに比べてこの実験では遅く、しかも「スクリプトの実行に時間が…」というエラーが出てしまいます。止める方法はあるのでしょうが、調べるのも面倒なので、配列のサイズを200,000に減らし、繰り返し回数も減らしてあります。

(1) 110
(2) 94
(1) 125
(2) 93
(1) 110
(2) 93

まとめ

疑う余地はなく、減算の方が高速という結果が出ました。FF2やIE8などはTV前のここの環境には無いので試していませんが、傾向としては充分だと思います。
特に大きなループでは可能ならば和算よりも減算を使うようにするのが良さそうです。

なお、カウントダウンでのループが可能なアルゴリズムであれば、比較演算も省略できる次の形の方が、より高速でした。

/* (3) while-subtract */
var s = get_ms();
var i=arr.length;
while(--i){
  arr[i] = i;
}
var e = get_ms();
dump(e-s);

[Firefox3.0.1]

(1) 110
(2) 91
(3) 77
(1) 106
(2) 92
(3) 77

コード量も少なく、お勧めの記述です。

2009.09.27追記

コメント欄で指摘をいただきました。
初歩的なミスで、lengthの評価回数が釣り合っておりませんでしたので、改めてやってみます。

var len = arr.length;

/* (1) sum */
var s = get_ms();
for(var i=0; i<len; ++i){
  arr[i] = i;
}
var e = get_ms();
dump(e-s);

/* (2) subtract */
var s = get_ms();
for(var i=len; i>0; --i){
  arr[i] = i;
}
var e = get_ms();
dump(e-s);

結果

[Firefox3.5.3] (500,000ループ)

(1)100
(2)97
(2)100
(1)95
(2)100
(1)97

[Internet Explorer 8] (200,000ループ)

(1)47
(2)62
(1)47
(2)62
(1)47
(2)63

[Chrome 2] (5,000,000ループ)

(1)29
(2)26
(1)29
(2)26
(1)28
(2)25

再まとめ

結果、FF3.5やChrome2では傾向は変わらないものの、その差は縮まりました。
また、IE8では寧ろ加算の方が速くなっています。
前回テストした際のバージョンに該当するブラウザが手元に無いので比較実験になっていませんが、加減算の速度差は気にするほどではないと言えるかもしれません。

No related posts.

大抵の、特に変数の型宣言を行わないタイプの言語では、型の異なる値の条件式は悩みの種です。
Javascriptもご他聞に洩れずというか、undefinedとnullが異なる分だけ更にややこしくなっているようです。
暗黙の型変換で痛い目にあわないよう、ちょっと実験してまとめてみます。
実験にはとりあえず、手っ取り早いので Jash を使用。
一緒に試してみるならば、こちらのBookmarkletをクリックしてコンソールに入力しながら読むとわかりやすいかもしれません。

nullとundefined

nullとundefined。たまに「同じもの？」と聞かれることもあるので、とりあえず確かめて見ます。

>> null==undefined
true

あれ、同じでしょうか？

>> null===undefined
false

もちろん違います。
しかし、== 演算子で比較する限りは「同じ」と言ってもよいようです。
では、実際は何が違うのでしょうか？typeofで確認してみます。

>> typeof null
object
>> typeof undefined
undefined

nullはobjectなんですね。
根本的に型が違う（undefinedには型が無い？）ようです。

演算子: ==

ではこの == という曖昧な演算子について検証してみます。
登場人物はfalseと、それと等しくなりそうな7つの値「undefined」「null」「”(空文字)」「0(数値のゼロ)」「’0′(文字列としてのゼロ)」「”\n”(改行)」「” “(スペース)」。
先ほどのように、それぞれを == で結んでみましょう。

>> false==null
false

全て試したマトリックスが次のものです。（undefはundefined）

さて、いかがでしょう。
かなりの無秩序さにゲンナリです。
かろうじて文字列同士はキャストが行われない分だけ理解しやすいですが…つまり、ここで挙げた文字列は全てfalseや0と等価になるものの、お互いは等価にはならないと。

演算子: ===

では、型まで含めた === 演算子を用いた場合はどうでしょう。

>> false===0
false

これは、予想通り全ての異なる値間で false となりました。
厳密な比較を行うのならば、やはりこれを使うのが良さそうです。

演算子: !

では、if文の中での暗黙の条件式はではどうでしょう。
前項で false との等価比較だったので、あわせてここは「!」を付けた条件式に真と評価されるかどうかを試してみます。
わかりにくいですね。つまり例えば undefined のテストであれば、次のような式で試したということです。

>> (!undefined ? true : false)
true

先ほどと同じ値を用いて試したのが、次の表です。

なんと、 == 演算子のどの列とも合致しない結果です。
つまり、こういうことなのですね。

>> hoge=null
null
>> (hoge==false?true:false)
false
>> (!hoge?true:false)
true

まとめ

では、実際にはどうコーディングすれば安全なのでしょうか。
動きをある程度ちゃんと把握していれば、あとは用途にあわせて…という言い方に結局はなると思います。
しかし、型が怪しい場合は極力 == は使わない方が良いと言えそうです。

未定義の変数を調べる場合は typeof を使う

( typeof v == 'undefined' )

型を意識して正確に比較するなら === を使う
当然のことながら。
しかし実のところ、Javascriptでこういったケースはあまり多くないと思います。

テキストボックスに入力があるかを確かめる場合
これは、よく見ると結構難問です。
純粋に文字列が全く入っていないことを確かめるならば、=== を使えば確実です。

( text.value==='' )

しかし、必須入力確認をしたい場合、空白文字や改行が入っただけの状態は望ましくないはず。この条件では、そうした状態はパスしてしまいます。JavaScriptにはtrim関数が標準で無いので、これはそれなりに厄介。

では、意外とこれではどうでしょう。

( text.value==false )

こうすれば空白や改行は大丈夫ですが、「0」や「000」などと入力された場合に未入力と判定されてしまいます。

ここはやはり、正規表現などを用いるのが良さそうです。

まとめてみましたが、あんまりスッキリしませんでした。

Related posts:

1. [PHP] 論理演算子「and, or」と「&&, ||」の違い
2. [jQuery Mobile] PhotoSwipeプラグイン