控えめなJavaScript

歴史的にJavaScriptは本格的なアプリケーション開発には適さない、扱いにくい言語とされてきた[3][4]。これは主に、言語そのものと、各種ブラウザでのドキュメントオブジェクトモデル (DOM) の一貫性のない実装[5]、さらにバグを生みやすいコピー・アンド・ペーストで作られたコードが広く使われてきたことによるものである。ランタイムエラーは非常によく見られる上にデバッグが非常に困難であるため、スクリプトが多かれ少なかれ意図したとおりに動いている限り、それを修正しようとするプログラマはほとんどいなかった[6]。しかし、一部のブラウザでは全く動かないスクリプトもあった。

一部のWeb開発者は、1994年以降、グレースフル・デグラデーション（適切な低均作用）を推奨してきた[7]。近年、標準に準拠したブラウザや、JavaScriptフレームワーク、高品質なデバッグツールの出現により、体系化され、拡張可能なJavaScriptコードが可能になった。そして、Ajaxインターフェースの出現によって、そのようなコードが望まれるようになった。JavaScriptはかつて、バリデーションや装飾的な真新しさを出すなどの、比較的シンプルで非クリティカルなタスクを行う言語だとされてきたが、現在はWebサイトの中核機能の一部にもなりうる巨大で複雑なコードベースを記述するために使われている。ランタイムエラーや予期しない動作は、もはや小さな厄介ごとではなく、致命的な欠陥である。

控えめなJavaScriptの支持者は、それをより大きなウェブ標準の動きの一部として見ている。ブラウザ間の互換性への要求によって、標準化されたマークアップとCSSがより重視されるようになったが、リッチインターネットアプリケーションの需要によって、JavaScriptの使用法のベタープラクティスを志向した動きが促進されている。JavaScriptプログラミングに関連した控えめさ (unobtrusiveness) の概念は、2002年にStuart Langridgeによって、彼の記事”Unobtrusive DHTML, and the power of unordered lists”の中で考案された[8]。彼はその記事の中で、イベントハンドラを含むすべてのJavaScriptコードをHTMLの外に置くという方法を主張している。その後、Stuart Langridgeはこの考え方を本や記事の形式でさらに詳しく述べた[9][10]。

David Flanaganは控えめ (unobtrusive) なパラダイムの本質的な要素を洗練して定義しようとした。彼は影響力のある著書”JavaScript: The Definitive Guide”の中で、具体的な公式はないものの3つの主要な目標があると述べている[11]。

1. JavaScriptのモジュールをほかのモジュールと分けるとともに、JavaScriptをHTMLマークアップと分離すること
2. 控えめなJavaScriptは、グレースフル・デグラデーションする必要がある。つまり全てのコンテンツはJavaScriptが動作せずとも利用可能でなればいけない。
3. 控えめなJavaScriptは、ユーザが障害を持っていたり、一般的でないブラウザを使っていたり、一般的でない設定をしていたりしても、HTMLのアクセシビリティを低下させてはならず、理想的にはそれを向上させるべきである。

ウェブスタンダードプロジェクトはJavaScriptマニフェストの中で控えめなDOMスクリプティングの4つの利点を説明している[12]。

1. ユーザビリティ：控えめなDOMスクリプトは、ユーザの注意を引かない。つまり、サイトの訪問者は、それについて考えなくても利用できる。
2. グレースフル・デグラデーション：控えめなDOMスクリプトは、あらゆるブラウザで、たとえうまく動作しなくても、決してエラーメッセージを出さない。機能が正しく表示できなくても、静かに消える。
3. アクセシビリティ：あるスクリプトが動作しなくても、そのページの中核の機能と情報は、マークアップ、スタイルシートやサーバサイドのスクリプトによって提供される。
4. 分離：他のWeb開発者や将来のWeb開発者への利点として、他のファイルやスクリプト、HTMLに影響を与えずに、すべてのJavaScriptコードが別々に維持されていることがある。

2007年のパリWebカンファレンスに向けて、Christian Heilmannは控えめなJavaScriptの7つのルールを同定した[13]。

1. あらゆる仮定を行わない：防御的プログラミング (Defensive programming) の技法はJavaScriptが動かなかったり、ブラウザが期待されたメソッドをサポートしていない可能性を見込まなければいけない。また、HTMLが変更されていることや、予期しない入力デバイスが使われること、他のスクリプトが存在しなかったり、他のスクリプトがグローバルな名前空間に侵入してきたりする可能性もある。
2. 結びつけるものや関係を見つける。想定しているHTMLの、IDや他の性質などである。
3. 個々のDOMオブジェクトを縦断的に見るのは、その専門家に任せる。例えば、ブラウザに組み込まれたCSSハンドラなどである。
4. ブラウザとユーザを理解する。特にそれらがどのように動作しなかったり、どんな仮定をしているかということや、一般的でない設定や使い方をしているかということである。
5. イベントを理解する。どのようにイベントが発生するかということや、ほとんどのイベントハンドラに渡されるEventオブジェクトの機能の理解も含まれる。
6. 他のスクリプトとうまく共存して実行する。グローバルな関数や変数名を避けるなどする。
7. 次の開発者のために作業する。わかりやすい変数や関数名を使ったり、論理的で読みやすいコードを書いたり、依存関係を明らかにしたり、混乱をきたす可能性のあるすべてのコードにコメントを書いたりする。

伝統的に、JavaScriptはHTMLドキュメントのマークアップとともにインラインに記述されることが多かった。例えば、下の例はインラインに記述された典型的なJavaScriptのフォームバリデーションの実装である。

<input type="text" name="date" onchange="validateDate()" />

控えめなJavaScriptの支持者は、マークアップの目的は、プログラム的な動作ではなく文書の構造を記述することであり、その2つを一緒にすることで、コンテンツと表示を一緒にするのと同様に、サイトの保守性に悪影響を与えると主張している。また、1つの要素に対して複数のイベントを設定するときや、同じイベントハンドラを複数の要素に設定しなければいけないとき、イベントデリゲートを使うときに、インラインのイベントハンドラは利用するのも維持するのも難しいとも主張している。さらに、カスタムイベントを使うこともできない。

控えめなパラダイムによる解決策は、インラインではなく、必要なイベントハンドラをプログラム的に登録することである。onchange属性を上の例のように明示的に記述するのではなく、適切な要素をclassやid属性などによって単純に識別する。

<input type="text" name="date" id="date" />

以下は、ページが最初に読み込まれたときに実行され、適切な要素を探してそれぞれに設定を行うスクリプトである。

window.onload = function() {
    document.getElementById('date').onchange = validateDate;
};

• レスポンシブウェブデザイン