JavaScriptライブラリ中毒者(ジャンキー)にならないために


Web コンテンツに、より高度で複雑な機能を求められる昨今、jQuery のような外部の JavaScript ライブラリを利用しない Web サイトはほとんどないでしょう。

たしかにそれらは汎用性が高く再利用が可能なので、さまざまな機能を自分で実装する必要はなく、工数を圧縮し開発生産性を高めることができます。

また、昨今の技術系のニュース記事では、新しいフレームワークが次々と登場して話題となり、それらを使用して開発することが、さも「モダン」であるかのように書かれています。

はたして本当にそうでしょうか?

DOM のセレクターを使用するためだけに大量の機能セットを含むライブラリを参照しているソースや、UI バインディングを行うためだけに大げさなフレームワークを利用しているソース、それは「モダン」で「クール」な作りなのでしょうか?

今回の記事では、外部 JavaScript のライブラリやフレームワークの使用について、その意義とリスクについてあらためと考えてみたいと思います。

 

あらためて意識しておきたい

外部の JavaScript ライブラリを
使用する際の影響

外部の JavaScript ライブラリは便利である一方、どのようなコードであろうと第三者が開発したものであるかぎり、自分の感知しえない不具合やセキュリティ、パフォーマンス問題、または予想外の振る舞いを潜在的に導入することになります。たとえば、JavaScript ライブラリを使用するにはブラウザーにロードされる必要があり、それには追加のサーバー ラウンドトリップやライブラリそのもののサイズが多少なりともパフォーマンスにネガティブな影響を与えます。また、コードの品質も必ずしも保障されているものではありません。

これはいたずら不安を煽っているわけではなく、外部の JavaScript を導入するのであれば、前述のようなマイナス面について最低限理解しておくべきあたりまえの事実です。

こういったマイナス面を担保するにはどういった方法がとれるでしょうか?

もっとも確実な方法は使用しないということです。しかしながら、前述したように Web コンテンツに複雑な高機能を要求される昨今では、外部の JavaScript ライブラリを一切しないというのは現実的ではありません。

よって現実的な 1 つの解として導きだされるのは、実装する処理に外部の JavaScript ライブラリの機能が本当に必要であるかどうか、Web 標準技術の活用だけで実装可できないのか、正しく見極めることです。

2 番目の方法は、ライブラリの更新情報をフォローし、各ライブラリの最新の安定バージョンに常にアップグレードするかどうかを判断することで、リスクを抑制することができます。

 

JS ライブラリ(jQuery)の機能を置き換える

今現在、最も一般的に使用される JavaScript ライブラリの 1 つは jQuery でしょう。この JavaScript ライブラリは、Web 開発者に HTML DOM をクエリーして簡単に操作する方法を提供します。

特徴的な jQuery セレクターの記述によってもたらされるコードの簡潔化とその機能は、初見の際には誰しもが新鮮な驚きと少なからぬ感動を覚えたことでしょう。

しかしなから、過去の我々の目に魔法のように映った jQuery のセレクターの機能も、いまや JavaScript の標準的な機能で記述することができるのです。

以下のコードは jQuery で一般的に使用される機能のいくつかです。

//Id 'party_goods' を持つ DOM 要素の取得
var product = $('#party_goods');

//子要素であるすべてのimg要素を取得
var productImages = $('#party_goods').find('img');

//指定した要素のクラスを追加
$('#party_goods').addClass('crazy');

//指定したクラスの要素を列挙
var crazyItem = $(‘.crazy’);


 

現代の JavaScript では、標準の機能を使用して以下のように記述することができます。


 

//Id 'party_goods' を持つ DOM 要素の取得
var product = document.getElementById('party_goods');

//子要素であるすべてのimg要素を取得
var productImages
            = document.querySelectorAll('#party_goods img');

//指定した要素のクラスを追加
document.querySelector('#party_goods').classList.add('crazy');

//指定したクラスの要素を列挙
var crazyItem = document.querySelectorAll('crazy');


さきほど “現代の” と書きましたが、これらの記述は結構以前から使用することができました。

querySelector や querySelectorAll は以下 caniuse.com のリンクが示すとおり Internet Explorer 9 の時点で Safari 以外のメジャーな PC 用の Web ブラウザーで使用することができました。

Can I use... Support tables for HTML5, CSS3, etc querySelector/querySelectorAll

JavaScript の標準的な機能を使った書き方は jQuery の記述よりも冗長かもしれません。

しかしながら要素を取得するための getElementById などは、一度どこかで以下のように宣言しておけば、


var $id = function (id) {return document.getElementById(id);}


以降は以下のように記述すれば良くなります。


//Id 'party_goods' を持つ DOM 要素の取得
var product = $id('party_goods');


 

「そうは言っても、他の機能で jQuery を参照しているんだからべつに使ったって良んじゃネ?」という意見もあるでしょう。

たしかに CSS のフレームワークである Bootstrap などは jQuery を使用するので、望むと望まざるとにかかわらず jQuery ライブラリはブラウザにロードされることになります。「ロードされたんだから使わなければ損」という気持ちもわからなくもありません。

しかし、考えてほしいのです、想像して、推測してほしいのです。「(‘#hoge’)」と記述して、本来の getElementById メソッドに行きつくまでに、標準的な書き方をすれば処理する必要のない JavaScript コードがどれくらいあるのかを。もし、想像できなければブラウザーの開発者ツールを起動して jQuery ライブラリの中をステップ実行してみると良いでしょう。「id からエレメントを取得する」という処理のために結構な量の JavaScript コードを処理しなければならないということがわかるはずです。

つまり、jQuery のセレクターを使用する毎にこの大量のコードが実行されるのです。はたしてそれが効率の良いプログラムと言えるでしょうか?

さらには、ライブラリに依存しすぎると移植性が犠牲になります。

あたりまえですが、jQuery の使用を前提として書いたコードは jQuery のある環境でしか動作しません。もしなんらかの理由で jQuery が使用できない環境に移植する場合は修正が必要になります。しかし、前述したような JavaScript の標準機能を積極的に活用し、ライブラリへの依存度を極力下げることで修正の範囲を狭くおさえることができます。

(※じつはここから、外部フレームワークなしで実現するシンプルな JavaScript コードによるデータと UI のバインド方法について書いたのですが、長くなったので、近日別途記事にします。)

 

JavaScript ライブラリ導入後の
メンテナンス

JavaScript ライブラリはある一定期間ごとにバージョンアップが行われますが、バージョンアップで行われるのは機能追加だけではありません。

既知のものや、前バージョンリリース後に発見された不具合の修正も行われます。

これらの修正内容は、Web コンテンツの動作に関わる内容も含まれる場合もあるので、外部の JavaScript を採用したのであれば、継続して更新の内容を確認しておくことをお勧めします。

image

 

JavaScript ライブラリについて

問題を含むバージョンをチェックするツール

JavaScript のライブラリの更新情報については、提供元の Web サイトを参照するのが基本ですが、マイクロソフトでは、Web サイトで使用している JavaScript ライブラリが問題をふくむバージョンでないかどうかをチェックするツールを提供しています。

このツールにアクセスするには以下の URLにアクセスし、ページ内にある 「URL の入力」とキャプションのあるテキストボックスに対象の URL を入力し、虫眼鏡ボタンをクリックするとページのスキャンが行われます。

image

ちなみに以下は、このブログのサイトの検証結果です。

image

このブログで使用しているのは jQuery 1.5.2 であり、ソースコードの 24 行目になにがしかの問題があることを指摘し、かつ、互換性のある問題のないバージョンとして 1.6.4 を提示しています。

このツールについてはオープンソース版が GitHub で公開されており、このブログでも以前、配置の方法を記事にしています。

Web 制作での外部ライブラリの使用があたりまえとなった昨今、導入は進んだものの公開後のバージョンのメンテナンスはおろそかになっている場合があります。(じっさいのところ、毎回更新の内容を確認するのはたいへんです)

こういったツールを積極的に使用してメンテナンスを楽にしてみてはいかがでしょうか。

 

まとめ

今回の記事では、jQuery のような外部の JavaScript を使用する際のリスクについてあたらめて確認しました。

外部の JavaScript は便利な反面、依存しすぎるとパフォーマンスの低下やコードのロックインにつながります。どこまでをライブラリに任せ、どこまでを自前で書くのか意識されると良いでしょう。

Real Time Analytics

Clicky


Comments (1)

  1. js より:

    とても興味深い記事ありがたいです。
    babelでフューチャーシンタックスで記載で作れるならそれが一番良いのですね。

    比べるべきでは無いと言われてしまうのですが素のJSをBabelでトランスパイルするのとreactは、js基礎をやっている人にはどちらの方が簡単に理解出来、Webアプリが作れるでしょうか。
    Htmlは解るので、タグを使うRiot.js 、Reactは非常に分かり易いのでしょうかね?

    reactはjQueryのように、よく使うメソッドがまとめられていて、
    バニラjsだと大量に記載をしないといけないのが、iQueryのようにほんのわずかなメソッドを記載しただけで実現できるメリットはあると考えてよいでしょうか?

    jQueryはそれでバニラjsより圧倒的に簡単になっていると思います。
    どうもそのようであるという話をいただいているのですが、Riot.js 、reactも同じでしょうか?

    バニラjsですと、仮にbabelをつかってフューチャーシンタックスで記載しても、
    jQueryやRiot.js 、reactよりも大量のメソッドの記述が相変わらず必要で大変なことに変わりはないのでしょうか?
    それともフューチャーシンタックスでは、ライブラリのように、よく使うメソッドがまとめられていて、大量に記載しないといけない問題が解決されているのでしょうか?

    人によって答えが違ってくる質問なので、たくさんの方の意見が聞きたく質問しています。
    お忙しい中大変恐縮ですが、フリーランスで小規模サイト制作を受ける程度の、WEBクリエイターなら、どのJSを学ぶべきでしょうか?

    Riot.js は、やはり、将来すたれた時に癖がないので、すぐに他に移れる。
    jQueryの次に学習が簡単なので一番でしょうか?
    恐らくbabelでフューチャーシンタックスで記載しても、ライブラリを使わないと、
    とても多くのメソッドを覚え、沢山のコード量を記載しないとWEBアプリが作れないので、こちらは難易度が高いのでしょうね。

Skip to main content