web-dev-qa-db-ja.com

jQueryを使用しない経験的な技術的理由は何ですか?

コンテキスト:1日中HTML、Javascript、CSSをハックするフロントエンド開発者の数とignore jQuery(または他の同等のヘルパーフレームワーク)やrefuseなどのツールを使用してそれらを使用します。私はJavaScriptの達人のことを話しているのではなく、ジョーのプロダクション開発者の日々のtrenchの中で話しているのです。言い訳や個人的な意見のような、技術的なメリットはないと思う多くの議論があります。何かを見逃していないことを確認したいと思います。

質問:jQueryを使用しない経験的な技術的理由は何ですか?

「他のフレームワークが優れているように」宗教的または独断的な議論や主観的な意見を探しているわけではありません。

72
user177800

更新2015:

2011年のこの回答では、jQuery、YUI、Prototypeなどのライブラリについて話しています。 2015年現在、この推論は、Angular、React、Emberなどのフレームワークに引き続き適用可能です。この4年間で、テクノロジーは飛躍的に進歩しましたが、ReactまたはAngularに対する偏見は、jQueryやYUIに対する見方よりもかなり少ないとはいえ、同じように考えていますが、範囲-現在でも存在しています。

更新2016:

数日前に公開された記事を強くお勧めします。

この記事は、基本的にこの質問に対する非常に詳細な回答です。以下の回答を書いていたときにそれが利用できていたら、間違いなく引用したでしょう。

元の回答:

JQueryについてお答えしますが、これらはYUI、Prototype、Dojo、Extなどを使用して聞いたのと同じ引数です。私が聞いた主な議論:

  1. ファイルサイズ、実際には jQuery 3.2.1 の場合は84.6 KB-おそらく平均してロゴよりも小さいほとんどの訪問者のキャッシュに既にある可能性が高いGoogleのCDNから提供できます。 jQueryを使用すると、常に独自のJavaScriptファイルのファイルサイズが小さくなることを意味するため、ブラウザーキャッシュにまだない場合でも、実際にはsmallerダウンロードを意味します。

  2. speed-純粋なJavaScriptの記述は高速ですが、portableJavaScriptの記述はほとんどの場合不可能です人々。より高速ですが、すべての一般的なブラウザで機能しないWebサイトは、現実の世界では役に立ちません。 jQueryはいくつかの非常に重い最適化を使用して実際に非常に高速であり、リリースごとにさらに高速になり続けているため、些細な例以外の高速コードを手で書くのはそれほど簡単ではありません。(*)

  3. "知的財産"-会社は他人のコードを使用して怖がっています-実際、jQueryはオープンソースであり、おばあちゃんのブログのいたるところで使用されているフリーソフトウェアですアマゾンに、ツイッターからバンクオブアメリカに、グーグルからマイクロソフトに-もし彼らがそれを使えるなら、どんな会社でもそれを使うことができます。

  4. 他の議論が真剣に使用されているのを聞いたことを思い出せません。

(*)以下は簡単な例です:getElementById( 'someid')vs. jQuery( '#someid')

GetElementByIdの使用は高速ですか?はい。そしてもちろん、Blackberry 4.6がドキュメントに存在しないノードを返したときにキャッチするために、全員が常にparentNodeをチェックします。 jQueryはそうします。そして、IEおよびOperaがIDではなく名前でアイテムを返す場合を誰もが処理します。 jQueryはそうします。そうしないと、コードが移植できなくなり、見つけにくい微妙なバグが発生します。そして、getElementByIdはおそらく見つけられる最も些細な例です-イベントやAJAXとDOMで始めてはいけません...

更新:

実際、誰かがjQueryを使用したくない理由を尋ねる4番目の結果があります。実際に答えではなく、あらゆる答えのlackなので、このリストに入れるのを忘れました。 comment 昨日手に入れたので、それについて思い出した。これは、リストに追加する「技術的理由」ではありませんが、それでも興味深いかもしれず、実際にはthe最も一般的な反応かもしれません。

私が個人的にこれらの反応のすべての主な根本的な理由であると疑っているのは、コンピュータサイエンスの進歩に対する最大の障害であると信じているものです:「使用したことがないので、使用したくないので、それほど重要ではないはずです。」

それはかつてアセンブラ、コンパイラ、構造化プログラミング、高レベル言語、ガベージコレクション、オブジェクト指向プログラミング、クロージャ、または私たちが当然と思っていたほぼすべての最適化に対する反応でした。そして今日はAJAXライブラリです。たぶん、アプリケーションレベルで生のDOM APIと手動でやり取りしたことを誰も覚えていないかもしれませんが、今まで誰も 生、装飾なし、計り知れない16進数

127
rsp

jQueryはeverythingをDOM中心のパラダイムで表現します。これは誤解を招く可能性があり、アプリケーションパターンで物事を表現する必要はありません。

多くの開発者は、このDOM中心のパターンを使用してプログラミングを隅々まで行い、最終的に、拡張性または再利用可能なものを作成していないことに気付きます。

Rebecca Murpheyには jQueryのDojo への切り替えに関するすばらしい記事があります-ブログ投稿では、なぜnotについて説明していますjQuery vswhyDojo。

23
philwinkle

フレームワークを使用しない1つの理由-これは極端なEdgeのケースです-バナーなど、別のWebサイト用の埋め込み可能なコードを作成する場合です。複雑なライブラリや別のライブラリを任意に挿入すると、ネームスペースが汚染され、他の誰かのサイトが破壊される可能性があります。とにかく、いくつかの広告主を過ぎて、池を吸っているスカムを試してみたわけではありませんが、私は脱線します...

フレームワークが既に存在し、同等に機能している場合、フレームワークを追加することに同意しません。私はそれをあまりにも頻繁に見ます、そしてそれは私のペット嫌いです、私はそれを不当な肥大化として見ます。それは完全に別の質問です。

それ以外は、正当な理由が考えられない。

18
clockworkgeek

ファイルサイズ-しかし、実際には、それを超えて、クロスプラットフォームのJavaScriptとブラウザの違いに対する絶対的な神の送信です。ツールキットでそれを望まない(または原理主義の開発者バカになる)には、いくつかの非常に良い理由が必要です。

11
jpea
  • ファイルサイズを正当化することはできません(おそらく、提供されている抽象化を利用しないスクリプトよりも小さいかもしれませんが)。
  • 彼らはサードパーティのツールに依存したくありません。
  • 彼らのビジネスは(何らかの理由で)ライブラリを実行したくない。
  • 彼らのビジネスは、従業員によって書かれていないJavaScriptコードを実行したくないのです。
7
alex
  • 学習:実際にすべてをコーディングし、さらに学習する。 (事前にコード化されたものを使用するのではなく)
  • サイズ: jQueryには必要のない機能がたくさんあります。使用しない場合、なぜユーザーに大量のコードをダウンロードさせるのですか?
  • 代替案:この時点で、より強力で適切に構造化されたWebフレームワークが多数あります。
  • 柔軟性: jQueryは非常に柔軟ですが、提供されていないものが必要になる場合があります。
5
JCOC611

どうしてもjQueryが好きですが、jQueryを使用しない理由がいくつかあります。

  1. ダウンロードサイズ/帯域幅:jQuery 1.5は200Kを超える非圧縮になりました。一部のライブラリのサイズは、メリットを正当化するには大きすぎます。
  2. パフォーマンス:ネイティブJSの記述は、ライブラリの背後で抽象化するよりも常に高速です。
  3. 複雑さの追加:多くの人がjQueryライブラリー全体をダウンロードするのは、実際には必要な機能がいくつかしか必要ない場合です。
  4. アプリケーションの依存関係:依存関係を導入すると、常にハングアップします。 jQueryにバグがある場合、ファイルをデバッグおよび編集できますが、後でアップグレードすると問題が発生します。バグを残すことはできますが、今では修正のためにjQueryのタイムテーブルに依存しています。
4
Eli

非常に多くの場合、それは単に不要だからです。入力を検証したり、フィールドをハイライトしたりするだけなら、単純なjavascript/domコードを書くのも簡単です。そして、jQueryはそのような単純なケースでは実際には役に立たないので、質問はwhy使用すべきでしょうか?

明らかに、非常に有用なケースは多くありますが、実際の理由もなく使用されているようです。

3
jcoder

私はjqueryをdomの操作またはdomのトラバースに使用したいと思いますが、これはjqueryを使えば非常に簡単です。さらに、jqueryまたは他のフレームワークを使用すると、イベントまたはイベント委任を簡単に添付できます。そうしないと、IEまたはnon IEブラウザーなどのカスタムイベント添付を作成する必要があります。

ただし、Vanilla JSの代わりに$ .eachを使用するとarray.Push()を使用するとパフォーマンスが低下します。イベントをバインドし、バインドを解除せずにイベントを削除すると、メモリリークが発生します。

私の結論は、複雑なdom操作にはフレームワークのみを使用し、残りはVanilla JSを使用することです

2
paul

JQueryを使用しないのはなぜですか?

JQueryではなくVanilla JavaScriptを使用する良い言い訳は考えられません(何か新しいことを学ぶという脅迫要因は別として)が、他のJavaScriptフレームワークを好む人もいます(優れた MooTools )それらの間の哲学的な違いのため。

JQueryの [〜#〜] dsl [〜#〜] -ish構文が嫌いな人もいますが、堅牢なJavaScriptフレームワークを使用することの重要性を認識しています。

個人的には、私lovejQueryですが、他のフレームワークを使用しており、生産性が劣らない人は知っています。

2
ClosureCowboy