JQueryよりも純粋なJavaScriptを使用する利点


86

Javascriptのみを使用することと、JQueryのみを使用することの利点は何ですか?

JavaScriptおよびJQueryコーディングの経験は限られています。HTMLページに各ビットとスニペットを追加しましたが、ほとんどの場合、サーバー側のものを他の言語でコーディングしました。2つのアプローチのいずれかを使用して理論的に同じことを行うことができます(もちろん、同じプロジェクトでそれらを混ぜることもできます)が、最初から常にJQueryを使用し始める傾向があるようですプロジェクトが要求するものは何でもありません。

だから私は単純に疑問に思っています、JQueryのみを使用せず、代わりに単純な古いJavaScriptを使用するだけの時間的な利点はありますか?

「明確な答えはありません」または「永遠に議論できる」と言うことができるので、これは非質問のように見えますが、実際には「あなたはこれを行うことができます」などの時間通りの答えを望んでいます1つのアプローチであり、他のアプローチではできません」。


scrwtpのコメントにあるように、私は単にDOM処理の部分に言及しているわけではありません。私の質問はむしろ:JQueryはライブラリです。Javascriptの場合。他の言語の他のライブラリとは対照的に、このライブラリについて私が奇妙に感じるのは、JQyeryの場合、それを排他的に使用できるように設計されており、Javascriptに直接触れる必要がないことです。これはHibernateとSQLとは対照的です。ライブラリ(またはこの場合はフレームワークですが、類似性はまだ当てはまると思います)が多くの側面を処理しますが、それを使用するときはSQLを使用できます。 、少なくとも一部のフリンジケースでは。しかし、JQueryとJavascriptの場合、JQueryのみを使用してJavascriptで行うことができます(少なくとも、私にはそう思われます)。


Stargazer712のコメントによると:はい、私はあなたに同意します。ここでの質問は、「JavaScriptをどのように使用するかという問題」です。それは私が実際に尋ねることに成功していたことですが、私はいくつかの悪い処方をしました。もう1つの例えは次のとおりです。SpringExpression Language。これはJavaライブラリです。Javaなしで使用することはできません。Javaに基づいており、Javaを使用するために必要なことはすべて実行できます。しかし実際には、このライブラリをJavaプロジェクトに追加してから、Spring ELの式言語を使用してすべてのコードを記述し、コードを事実上Javaに似せないようにします。これを使用する場合の強力な型の強制)。私はJQueryが単なるJSライブラリであることを理解していますが、実際にはSpring ELがJavaで持っているのと同じ効果があるようです。つまり、プロジェクト全体でそのAPIのみを使用し、JavaScriptのAPIを避けることができます。そして、それが良いことなのか、落とし穴などなのかと思っていました。

(そしてはい、みんなの答えを読んだ後、私はそれを理解しています:

a。私の質問はやや無意味です

b。質問が完全に正確であったとしても、その答えはほぼ「JQueryのみを常に使用することはできません」


25
「JQueryのみを使用する」と言うのは正しくありません_ JQueryはJavaScriptライブラリです。
superM

4
forループやwhileループ、変数、関数はありませんか?それはすべてJavaScriptです。
superM

2
「プレーンな古いJavaScript」とは、おそらくJavaScript DOM APIを意味します。混乱を避けるために、確認して質問を編集することをお勧めします。
scrwtp

4
ブラウザー間の互換性は十分ではありませんか?
サイモンホワイトヘッド

10
「それ(jquery)は、それを排他的に使用できるように設計されているようで、Javascriptに直接触れる必要はありません。」それは事実上正しくありません。jQueryは、JavaScript関数の単なるコレクションです(ただし、「$」などの変な名前が付いています)。jQueryを理解する上で重要な部分の1つは、この実現です。DOMの操作とループを処理するJUST追加機能。
グラハム

回答:


113

最初に-jQueryのみを使用することは不可能です。jQueryは、グローバルオブジェクトに$オブジェクトを追加し、その中に多数のメソッドを追加するだけです。プロトタイプのようなさらに操作性の高いライブラリはJavaScriptの代替ではなく、一般的な問題を解決するためのツールベルトです。

jQueryをツールベルトに追加する主な利点は次のとおりです。

  • ブラウザーの互換性-.attr()のようなことを行うことは、ネイティブの代替よりもはるかに簡単であり、ブラウザー間で壊れることはありません。
  • 通常複雑な操作の簡略化-XHRメソッドのクロスブラウザー互換バージョンをよく見たい場合は、$。ajaxのソースをご覧ください。このメソッドだけでは、jQのオーバーヘッドの価値がほとんどあります。
  • DOM選択-イベントのバインドやDOM要素の選択のような単純なことは複雑で、ブラウザごとに異なる場合があります。多くの知識がなければ、それらは簡単に不十分に書かれ、ページを遅くする可能性があります。
  • 将来の機能へのアクセス-.indexOfや.bindなどはネイティブjavascriptですが、多くのブラウザーではまだサポートされていません。ただし、これらのメソッドのjQueryバージョンを使用すると、クロスブラウザーでサポートできます。

Javascriptはもはやクライアント側の言語ではなく、jQueryはDOMに依存しているため、サーバーに移行するのはひどい候補です。なぜ jQueryを使用しているのを理解し(この質問をすることは素晴らしい最初のステップです!)、必要なときに評価することを強くお勧めします。jQueryは危険な場合があります。主な危険のいくつかは次のとおりです。

  • コード品質-jQueryには巨大なコミュニティがあり、学習曲線が低いです。これは多くの貧弱に書かれたオープンソースプラグインにとって完璧な嵐です。
  • 非効率-jQueryは非効率的に書くのは簡単です。たとえば、forループの代わりにjQueryのeachを使用することは不要であり、場合によってはパフォーマンスに影響を与える可能性があります。JSPerfでこのようなものに関する多くの良い情報
  • 膨張-jQueryは巨大なライブラリです。ほとんどの場合、その機能の小さなサブセットを使用し、ライブラリ全体を取得します。zepto.js、underscore.jsなど、機能のサブセットを提供する優れた代替手段がいくつかあります。状況に応じて、ニーズに合ったライブラリを選択することでバイトを節約できます。

最終的に、jQueryは適切に使用すると、非常に便利で役立つライブラリになります。ただし、javascriptに代わるものではありません。これは、zepto.jsYUIDojoMooTools、およびPrototypeのようなライブラリーです。そのうちの1つは、現在のプロジェクトに適した選択肢です。

Javascriptは誤解された言語であり、最近ではほとんどの人がスクリプト言語以上のものと見なされています。私はそれをもっと読むことを本当にお勧めします、始めるためのいくつかの良い場所があります:

編集07/2014-この投稿がまだ注目されていることに気づいたので、たくさんのリンクを追加しました。これらは特定の順序ではありませんが、役立つはずです。

  • Ben Almanのブログ -ここには多くの優れたベストプラクティスがあります。私はそれらすべてに同意するわけではありませんが、彼のブログから常に新しいことを学びます。
  • コードアカデミー -基本的なjavascriptおよびjQueryトレーニング。時々、基本に戻ることは助けになります。
  • Javascript Garden -javascriptのよりトリッキーまたは誤解された機能に関する投稿。すべてが理に適うまで、これを時々読んでください
  • Bocoup-これらはトレーニングクラスです。近くにいる場合は、そこに行きます。最高のJSスピーカーと教師の多くがこれらを教えています。
  • Paul Irishのブログ -厳密にはJSではありませんが、多くのベストプラクティスがここに記述されています。彼とベンのツイッターフィードはどちらもフォローするのに最適です。
  • Javascript:The Good Parts-「The Javascript Bible」と呼ばれることが多いダグラス・クロックフォードによるこの本は、javascriptの理解を開始する素晴らしい場所です。
  • Isaac Schlueterのブログ-Isaacはnpmの作成者であり、ノードコアで動作します。彼はコードの慣習ではなくjavascriptコミュニティについて多くのことを書いていますが、あなたが本当にjsに興味を持っているなら、それは素晴らしい読み物です。
  • ダグラス・クロックフォードのジャバスクリプト -ブレンダン・エイチがジャバスクリプトの父なら、ダグラスはジャバスクリプトの率直な叔父です。彼は、JSON仕様、javascript聖書の著者であり、javascriptの癖と流星の上昇に関する多くの素晴らしい投稿です。
  • Brendan Eichのブログ-Brendanはjavascriptの作成者です。彼は自分のブログにあらゆる種類の馬鹿げたことを書いています。
  • James Hallidayの(@substack)ブログ -Substackはほぼ間違いなくコミュニティで最も重要なnode.js開発者です-約400(毎日成長)のnpmモジュールと、小さなUnixに似たモジュールの指針哲学があり、彼が書いたものはすべて価値があります読書。
  • Max Ogdenのブログ Max Ogdenはもう1つの多作なnode.js作成者であり、何かを教えてくれるブログ投稿を書くのに優れています。また、彼は猫のjavascriptの著者でもあります(私は他の人と信じています)。
  • 猫のJavascript-これは、猫の観点からjavascriptの基本を説明する短いチュートリアルです。あなたが初心者なら、これを読んでください。それは楽しいですし、多くの本がコミュニケーションに何週間かかるかを1時間で教えます。
  • Nicholas Zakasのブログ Nicholasは、Javascriptでのオブジェクト指向プログラミング保守可能なJavascriptWeb開発者向けのプロフェッショナルなJavascript、および高性能Javascriptの素晴らしいJavaScriptの書籍をいくつか執筆しています。彼は主にクライアントに焦点を当てていますが、多くのベストプラクティスとパフォーマンスのヒントを持っています。
  • Guillermo Rauchのブログ -Guillermoはもう1つの多機能なnode.js開発者で、Socket.ioとMongooseで主に有名です。彼のブログ(および彼の新しい本Smashing Node.jsは、両方とも素晴らしいリソースです。

私が考えていない、または知らない多くの素晴らしいリソースがあると確信しています。他の回答者はそのリストに気軽に追加すべきです。


3
JSがクライアント側の言語のみではなくなったこと、およびこれらすべてでJQueryがどのように適合するかについての発言に対して+1。
シヴァンドラゴン

1
すべての関数はオブジェクトですが、JavaScriptのほぼすべてのものに気をつけてください。$は、「クラスレベル」プロパティが固定された関数としてより適切に説明されます。たとえば、$.ajaxラッパーオブジェクトにDOMメソッドを作成するためのdom要素のセットを吐き出します。意味のある場合は常にdomオブジェクトのセットを自動ループし、ブラウザー間で共通の予測可能なAPIを共有します(IE <= 8の問題ではありません)。
エリックReppen

1
これは素晴らしい投稿ですが、1つの点で問題を取り上げたいと思います-「巨大なライブラリ... Zepto / Underscoreを使用」-まず、Underscoreは完全に異なるタイプのライブラリです-主に配列/オブジェクトを処理し、LoDashを使用します代わりに、高速です。第二に、ZeptoはjQueryが行うことをカバーしていないため、小さくなっています。これは、jQueryが修正するバグにつながる可能性があります。最後に、jQueryはもはやそれほど大きく/モノリシックではなく、一度gzip圧縮すると約30Kbであり、1つ少ないイメージを使用して保存できます。私にとって、開発効率はこれらのバイトに値するものです。
LocalPCGuy 14

1
@LocalPCGuyは間違いなくいくつかの良い点です。この投稿は(まったく!)2年前であり、それ以来、jsエコシステムの状況は確かに変化しています。例えば、私は個人的には、グローバルに名前空間化されたライブラリーの代わりにbrowserifyと小さなモジュールを使用しています。ただし、基本的な前提は依然として正しいと思います。つまり、多くの場合(ほとんどの場合)、キッチンシンクライブラリはほとんど必要ありません。ほとんどの開発者は、ライブラリを使用することを決定する前にライブラリのサイズコストを適切に正当化することを確認し、必要なものを具体的に指定するよりも簡単にするようにしました。
ジェシー14

1
すべてのものに反応する、私は正しい!?!?!/ sarcasm-@Andyの仕事に適したツールを選択してください。これは必ずしもReactではありません。Reactは良いことをしていると思いますが、それがJavaScriptの世界のすべての治療法であるふりをしないでください。
LocalPCGuy

17

利点はありますが、欠点を本当に上回るかどうかは議論の余地があります。

主なものは、帯域幅を節約し、応答を速くすることです。jQueryは、応答に〜30kbを追加します。一部のネットワーク(および一部の国)では、さらに数ミリ秒を意味する場合があります。ただし、一方で、Webサーバーを使用して簡単にキャッシュを設定できます(またはXionが言ったように、Googleのサイトから使用して、自分のサイトに影響を与えずにキャッシュされます)。

2つ目は、非常に単純な機能のみが必要な場合があり、jQueryをダウンロードして設定するだけで、必要なものを実装するよりも時間がかかる可能性があることです。

そして最後に、あなたはあなた自身のフレームワークをロールしたいかもしれません、それはほとんど悪い考えですが、一部の人々は彼らの理由を持っています。

ただし、学習曲線に脅かされているという理由だけでjQueryを破棄する場合は、再検討する必要があります。特にかなり穏やかなように。


特に帯域幅の部分について合意しました。JQuery 1.8.2には、最小化/難読化バージョンで92Kbがあります。ただし、これらはJQueryを使用しない非常に強力な理由ではないことにも同意しました。ありがとう!
シヴァンドラゴン

1
@ShivanDragon:gzipを忘れました。それははるかに小さくなります。
シーフマスター

@ThiefMaster:それは本当です、指摘してくれてありがとう。
シヴァンドラゴン

10
(Googleのような)CDNからjQueryを使用する場合、他のサイトにアクセスしてユーザーが事前にロードしておく可能性があります。したがって、平均(最大ではありませんが)応答時間への影響は小さくなります。
Xion

1
@Philなぜあなたもそれをまったく使わないのですか?!?!jQueryはこれまでになく、今後も必要になることはありません。それは純粋な悪魔の悪です(悪魔の一団の他の人たち:ReactJS、Underscore、LoDash、Modernizr、CommonJS、Angular、Google Analytics、特にAMDなど)。個人的には、ライブラリ全体を一度も含めたことがありません(ただし、ライブラリから必要な特定の機能を抽出して最適化することはめったにありません)。 (1/59秒)。
ジャックギ

14

私が知る限り、バニラjavascriptを使用することの利点は、JQueryMooToolsなどのライブラリと比較して2つだけです。

  • ライブラリには、帯域幅を消費するペイロードがあります。しかし、他の回答ですでに指摘されているように、gzipとキャッシングでこれを制限できます。jizzのサブセットのみが必要な場合は、SizzleJSで実行できます。MooTools では、Modernizrと同じ方法で必要な機能セットを選択するオプションがあります。
  • 図書館は大きく、学ぶには時間がかかります。繰り返しになりますが、これは開発者にとっては1回限りの投資です...そして、あなたの履歴書でjavascriptライブラリを知っているのは素晴らしいことです。
  • (ボーナス)ライブラリは特効薬ではないので、車輪を再発明したいなら、これは間違いなく進むべき方法です。

javascriptライブラリを使用したい理由を指摘する価値があります。

  • 開発をサポートするために独自のフレームワークを作成する必要はありません。物事の仕組みに興味がある場合は、オープンソースなのでコードをチェックアウトできます。
  • ライブラリはブラウザの互換性を解決します。DOMとjavascriptの両方には、ブラウザー間でいくつかの違いがあります。私を信じてください、あなたが修正を自分でハックする必要がある場合、これは大きな時間のシンクです。
  • JavaScriptライブラリを使用することは事実上のインターネット標準であり、それらのほとんどは今では十分に文書化されており、ほとんどのWeb開発者(javascriptを知っている)はそれらの使用方法を知っています。
  • ライブラリを使用するときに、javascriptを実際に放棄することはありません。Javascriptの種類、オブジェクト、クロージャーの動作方法などを理解する必要があります。
  • ほとんどのライブラリはモジュール化されており、プラグインを作成したり、requireAMDパターンを使用したりするのに長い時間はかかりません。
  • DOMから要素を選択するCSSは大きな助けです。
  • (ボーナス)CoffeeScriptでも使用できます。

私は、jQueryが大きくて怖いので、バニラjavascriptの使用に固執したWebショップで働いていました。主に孤独な「javascript開発者」の影響を受けたこの決定は、多くのブラウザのバグと開発の遅れの原因であり、彼のコードベースに入ろうとするのは無理な経験でした。独自のフレームワークを作成することは良いアイデアのように思えるかもしれませんが、新しい開発者を雇いたい場合、彼らはすぐに乗り出して支援することはできません。次に、考慮すべきバス係数の問題もあります。

以前私はそこで働いていたと言いましたが... :^)


10

私はたまたま両方の使用を混ぜています。この最大の理由は、一部のアプリケーション(Chrome拡張機能など)では、クロスブラウザーのサポートが必要ないためです。つまり、css3のような新しい機能を利用できます。これにより、jqueryを使用するよりも、移行などのコードを大幅に簡素化できます。

また、私は頻繁に何かカスタムをしています。他の人が言ったように、あなたは車輪を再発明するべきではないと言っています。しかし、いくつかのクレイジーな機能を実行するように求められたとき、私は自分自身で書くのがはるかに簡単であると感じることがよくあります。

また、jqueryのみで作業する開発者とも協力しました。そして、彼らは彼らが望むことをしたjqueryプラグインを見つけることができなかった場合よりもはるかに頻繁に機能に妥協したと言わなければなりません。

Web開発のある時点で、ライブラリにあらかじめパッケージ化されていないことを行うように求められます。そのため、その時点で、ベース言語が実際にどのように機能するかをよく理解してください。

TLDC:両方を使用してください。バニラだけを使用すると不利になります。バニラの内外を知らず、常にjqueryを使用すると主張する場合は不利になります。


3
純粋なバニラjsは行く方法です!
マルコ

ライアンは、jQueryが密かdocument.querySelectorAllに舞台裏で悪用していることを知りません。
ジャックギ

6

私が考えることができるのは、JQueryなしではできないと思うことは、JQueryプラグインを使用することです。その場合でも、プラグインに必要なものだけを提供する独自のJSライブラリを作成できます。

次のように考えてください。JQueryは、Javascriptで記述されたオープンソースのJavascriptライブラリです。あなたはソースを見て、それによってそれがすることをする方法を学ぶことができます。

プレーンな古いJavascriptを使用せずにJQueryを使用することはできません。おそらくを使用することはないdocument.getElementByIdでしょうが、関数と変数は標準のJavascriptの方法で定義します。標準forループを作成することもできます。

JQueryを使用する主な利点は、どの言語の他のサードパーティライブラリともほとんど同じです。アプリケーション固有のロジックを実装するために、それほど多くのコードを記述する必要はありません。

サイズに驚かないでください。CDNのバージョンは、最初のページヒットの後に、ユーザーのブラウザでキャッシュされます。〜33Kでダウンロードできます。


6

パフォーマンスが心配な場合は、 可能な限りバニラjsを使用するようにしてください。フレームワークは、帯域幅のオーバーヘッドだけでなく、処理のオーバーヘッドも追加します。また、jQueryには、かなり古いブラウザーとのブラウザー互換性が備わっています。

モバイルアプリまたはモバイルゲーム(またはその両方)を使用している場合は、パフォーマンスとリソースの効率化を最初に必要とします。

jQueryとプラグインは開発をスピードアップするかもしれませんが、特にサードパーティのjqueryプラグインに依存している場合は、内部で何をしているのかを知っておく必要があります。それらの多くは、コードの品質と効率の悪い例です。

jQueryは、ネイティブJavaScriptよりも2〜10倍遅い場合があります。また、インターフェイスを適切に設計せず、ネイティブよりもはるかに遅いjQueryセレクターに過度に依存することを開発者に容易に促すことができます。


+1、パフォーマンス上の理由から、ゲームを作成することがバニラJSを優先してJQueryを捨てる正当な理由であることに同意します。これは、ほとんどの言語でゲームを作成する場合にほとんど当てはまります。たとえば、Googleの人たちは、Androidドキュメントで、ゲームを作成するときにライブラリを捨てる(AndroidではJavaで)だけでなく、速度を優先して優れたコーディング慣行をさらに捨てることを推奨しています。
シヴァンドラゴン

...効率的なDOM操作についてjQueryを書いている人たちと同じくらい知っているなら、はい。
エリックReppen

@ErikReppenは、実際に「jQueryを作成する人々」の実際のソースコードを調査してください。最初の23行で見た恐怖から1か月近く盲目でした。
ジャックギ

JQでは2013
。– Erik Reppen
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.