Document Actions
JavaScriptライブラリのバージョンアップ問題
ProjectA(http://www.ariel-networks.com/airone/)で最初に使い始めた汎用JavaScriptライブラリはprototype.jsでした。その後、animator.jsが加わりました。animator.jsは個人的には結構気に入っています。animator.jsについては、昔、記事(http://dev.ariel-networks.com/Members/inoue/animator-js-usage)を書きました。
prototype.jsやanimator.jsは比較的低レベルの汎用ライブラリです。これらはGUIウィジェット的な機能は提供していません。昨今のGUIウィジェット的な機能を提供する汎用JavaScriptライブラリの中から選んだのは、YUI(http://developer.yahoo.com/yui/)です。理由はアリエルはYahoo!が好きだからです。
社内では他にscriptaculous(http://script.aculo.us/)、Ext JSも使っています。Ext JSなんてライセンスまで購入しています。Ext JS採用企業のトップにアリエルの名前が載っています(http://extjs.co.jp/)。
遊びで作っているソフトではYUI2.xとYUI3.xの混在です。理由はYahoo!が好きだからです。
これらのJavaScriptライブラリのバージョンアップが悩ましい問題です。
製品に使うライブラリは、基本的に保守的な選択をします。バージョンアップのたびにAPIが激変されると困るからです。CやJavaの世界で比較的枯れたライブラリを選んでおけばバージョンアップでAPIはあまり変わりません。文化的に公開APIという思想があるからです。もっとも、CやJavaでもライブラリのバージョンアップには大きな決断が必要です。
JavaScriptライブラリの世界での公開APIの位置づけが微妙です。バージョンアップのたびに、書き方が変わってこんなに簡潔に記述できるようになりました、と言われても正直嬉しくありません。
prototype.jsぐらいの分量ならすべてのソースコードの変更点を見られるのですが、YUIレベルの量になると見る気になりません。そもそもすべての変更点を見ないと恐くてバージョンアップできないprototype.jsもどうかと思いますが。
そんなに嫌ならバージョンアップしなければいい、と言われそうですが、バージョンアップで速度が数十倍になったとか聞かされると、すごく重いライブラリを使わされている気分になるのが困った点です。
- Category(s)
- カテゴリなし
- The URL to Trackback this entry is:
- http://dev.ariel-networks.com/Members/inoue/js-libs/tbping
どのライブラリを使っているか、っていう問題とかはwrapperを作ればいいのではないでしょうか?
そうすることで、影響範囲が少なくて済むはずです。(jsに名空間が無いので云々は...聞き飽きましたが)
例えば、といっても代表例を出せないので、window.openを例にすると
var MyUtils = {
windowOpen: (url, name, param){return window.open(url, name, param)}
}
みたいな感じで、全く一緒の引数のものをwrapするだけで、影響範囲はclass methodに落とせると思います。
もしライブラリがバージョンアップしてしまって、互換性がなくなったとしても
上記の場合は MyUtils.windowOpen までが影響範囲で済みます。
なのでもし、互換性が崩れてしまってもその範囲で後方互換を行えばいいのではないでしょうか
ライブラリにさえもその負担を負わせるのは、ライブラリの開発速度やライブラリの利点を損なうことに
結びつきます。利用する側がちょっと工夫するだけで、うまく付き合えると思います。