私はextend.jsに精通したばかりで、ネイティブJavaScriptを使用するよりもライブラリを使用することに付加価値があるかどうか疑問に思っていました. 実演させてください。
extends.jsでは、次のように名前空間を宣言します。
extend('some.madeup.namespace',{
foo : 'bar'
});
…一方、それがなければ、次のようにするだけで済みます。
var some = { madeup : { namespace : { foo : 'bar' } } };
私は KISS の原則を固く信じており、物事をもう少し単純にするために、外部への依存関係を減らすべきだと本当に思っています。したがって、このライブラリが (1 回限りの) 代入宣言を保存するだけである場合は、手間をかける価値があるかどうかを考えます。
ここに欠けているものはありますか、これですべてですか？
この質問に対する賢明な答えは、サードパーティ製ツールの一般的な答えに大きく依存していると思います。
人々は、仕事をより速く、より洗練されたものにするのに役立つ場合、サードパーティのツールを使用します。少なくともそれが理論です。しかし、私も含めて、依存関係を減らしてゼロから実装する方が洗練されていると考える人がいます。私たちにとって、プロジェクトに砂糖を含めることにはほとんど価値がありません。
他の人にとっては、書かなければならないコードの量が減り、おそらく少し構造化されたように感じるので、価値があります。彼らは自分たちで同じ抽象化を行っていたはずなので、よく考えられ、テストされたライブラリを使用することは理にかなっています。
それはあなたの個人的な好みと使用法に大きく影響します。確かに、このライブラリの使用法については特に触れていませんが、わずか 51 行のコードです。提供されている機能を読み、独自の結論に達するのにそれほど時間はかかりません。
私が知る限り、このライブラリは名前空間階層を作成し、名前空間の競合をチェックするだけです。ほとんどのコードは、階層の作成と名前空間の区別の検証に重点を置いているようです。これは、競合が発生する可能性がある状況での汎用ツールとして設計されていることを示唆しています-たとえば、大量消費のために独自のライブラリを公開している.
私の意見が欲しいなら、それは勝手に使わない人の意見でしょう。名前空間は実際には不要です。名前空間の競合を実際に懸念している場合は、ウィンドウで複数の名前空間の競合を防ぐためのすべての努力が必要に思えますが、優れた設計は決してそうではありません。