JQuery पर शुद्ध जावास्क्रिप्ट का उपयोग करने के लाभ


86

जावास्क्रिप्ट का उपयोग करने के केवल JQuery के उपयोग से क्या फायदे हैं?

मुझे जावास्क्रिप्ट और JQuery कोडिंग के साथ सीमित अनुभव है। मैंने HTML पृष्ठों में प्रत्येक के बिट्स और स्निपेट जोड़े हैं, लेकिन मैंने ज्यादातर सर्वर-साइड सामान को अन्य भाषाओं में कोडित किया है। मैंने देखा है कि जब आप सैद्धांतिक रूप से दोनों दृष्टिकोणों में से किसी एक का उपयोग कर सकते हैं (और निश्चित रूप से आप उन्हें एक ही परियोजना में मिश्रण भी कर सकते हैं) तो हमेशा शुरुआत से ही JQuery का उपयोग करना शुरू करने की प्रवृत्ति प्रतीत होती है कोई फर्क नहीं पड़ता कि परियोजना की मांग क्या है।

तो मैं बस सोच रहा हूं, क्या JQuery-only का उपयोग न करने के लिए केवल समय पर पुराने जावास्क्रिप्ट का उपयोग करने के लिए कोई समयनिष्ठ लाभ हैं?

मुझे पता है कि यह एक गैर-प्रश्न जैसा लगता है क्योंकि इसके बारे में कहा जा सकता है कि "इसका कोई निश्चित उत्तर नहीं है" या "इस पर हमेशा के लिए बहस की जा सकती है", लेकिन मैं वास्तव में समय के पाबंद जवाब की उम्मीद कर रहा हूँ जैसे कि "आप इसमें ऐसा कर सकते हैं" एक दृष्टिकोण और आप इसे दूसरे के साथ नहीं कर सकते।


स्क्रव टीपी की टिप्पणी के अनुसार, मैं केवल डोम हैंडलिंग भाग की बात नहीं कर रहा हूं। मेरा सवाल यह है: JQuery एक पुस्तकालय है। जावास्क्रिप्ट के लिए। इस लाइब्रेरी के बारे में मुझे जो कुछ अजीब लगता है वह यह है कि अन्य भाषाओं के लिए अन्य पुस्तकालयों के विपरीत यह है कि जेक्यारी के मामले में ऐसा लगता है कि इसे विशेष रूप से उपयोग करने में सक्षम होना चाहिए और सीधे जावास्क्रिप्ट को छूने की आवश्यकता नहीं है। यह हाइबरनेट और एसक्यूएल कहने के लिए विरोध के रूप में है, जहां भले ही इस मामले में पुस्तकालय (या बल्कि रूपरेखा, लेकिन मुझे लगता है कि सादृश्य अभी भी लागू होता है) ए लॉट के पहलुओं पर संभाल लेता है, आपको अभी भी एसक्यूएल का उपयोग करते समय मिलता है। कम से कम कुछ फ्रिंज मामलों के लिए। हालांकि JQuery और जावास्क्रिप्ट मामले में, आप केवल JQuery का उपयोग करके जावास्क्रिप्ट के साथ कुछ भी कर सकते हैं (या कम से कम यह मुझे कैसा लगता है)।


Stargazer712 की टिप्पणी के अनुसार: हाँ, मैं आपसे सहमत हूँ, यहाँ सवाल यह है, जैसा कि आपने इसे "जावास्क्रिप्ट का उपयोग करने के तरीके के बारे में बताया"। यही मैं वास्तव में पूछने के लिए प्रयासरत था, लेकिन मैंने कुछ बुरे फॉर्मूले बनाए हैं। यहाँ एक और सादृश्य है: स्प्रिंग अभिव्यक्ति भाषा। यह एक जावा पुस्तकालय है। आप इसे जावा के बिना उपयोग नहीं कर सकते, यह जावा पर आधारित है, और इसके माध्यम से आप अभी भी जावा का उपयोग करते हैं। लेकिन व्यवहार में आप क्या कर सकते हैं इस लाइब्रेरी को एक जावा प्रोजेक्ट में जोड़ सकते हैं, और फिर स्प्रिंग ईएल की अभिव्यक्ति भाषा का उपयोग करके अपने सभी कोड को लिख सकते हैं जो प्रभावी रूप से आपके कोड को जावा से बिल्कुल नहीं मिलता है, और यह भी प्रतिमान स्थानांतरण है (उदाहरण के लिए अब आपके पास नहीं है इसका उपयोग करते समय मजबूत प्रकार का प्रवर्तन)। जबकि मैं समझता हूं कि JQuery सिर्फ एक JS लाइब्रेरी है, मेरे लिए ऐसा लगता है कि व्यवहार में इसका प्रभाव उसी प्रकार है जैसे कि स्प्रिंग EL का जावा के साथ होता है, अर्थात आप केवल एक प्रोजेक्ट के माध्यम से एपीआई का उपयोग कर सकते हैं और जावास्क्रिप्ट के एपीआई से बच सकते हैं। और मैं सोच रहा था कि क्या यह एक अच्छी बात है, क्या नुकसान हो सकता है आदि।

(और हाँ, हर किसी के उत्तर को पढ़ने के बाद मुझे समझ में आता है कि:

ए। मेरा सवाल कुछ हद तक गैर-कामुक है

ख। यहां तक ​​कि अगर प्रश्न पूरी तरह से सटीक थे, तो इसका उत्तर बहुत अधिक होगा "नहीं, आप केवल JQuery- केवल हर समय उपयोग नहीं कर सकते)


25
यह कहना सही नहीं है "केवल JQuery का उपयोग करें" _ JQuery एक जावास्क्रिप्ट पुस्तकालय है।
सुपरएम

4
लूप्स के लिए या नहीं, कोई चर नहीं, कोई कार्य नहीं? वह सब जावास्क्रिप्ट है।
सुपर

2
'सादे पुराने जावास्क्रिप्ट' से आपका मतलब जावास्क्रिप्ट डोम एपीआई है। आप इसे जांचना चाहते हैं और भ्रम से बचने के लिए प्रश्न को संपादित कर सकते हैं।
स्क्रव टीपी

4
क्या क्रॉस ब्राउज़र संगतता पर्याप्त कारण नहीं है?
साइमन व्हाइटहेड

10
"यह (jquery) ऐसा लगता है कि इसे विशेष रूप से उपयोग करने में सक्षम होना चाहिए और सीधे जावास्क्रिप्ट को छूने की आवश्यकता नहीं है"। यह सिर्फ तथ्यात्मक रूप से गलत है। jQuery केवल जावास्क्रिप्ट फ़ंक्शंस का एक संग्रह है (यद्यपि "$" जैसे अजीब नामों के साथ)। JQuery को समझने के महत्वपूर्ण हिस्सों में से एक यह अहसास है। इसके बस अतिरिक्त कार्य जो डोम हेरफेर और लूपिंग को संभालते हैं।
ग्राहम

जवाबों:


113

सबसे पहले - केवल jQuery का उपयोग करना असंभव है, सभी jQuery अपने वैश्विक दायरे में $ ऑब्जेक्ट जोड़ते हैं, जिसमें विधियों का एक गुच्छा होता है। प्रोटोटाइप जैसी अधिक हेरफेर करने वाली लाइब्रेरी भी जावास्क्रिप्ट का विकल्प नहीं हैं , वे सामान्य समस्याओं को हल करने के लिए एक टूलबेल्ट हैं।

आपके टूलबेल में jQuery जोड़ने का मुख्य लाभ होगा:

  • ब्राउज़र अनुकूलता - कुछ ऐसा .attr () करना देशी विकल्पों की तुलना में बहुत आसान है, और ब्राउज़रों में नहीं टूटेगा।
  • आमतौर पर जटिल परिचालनों का सरलीकरण - यदि आप एक एक्सएचआर विधि का एक अच्छा लिखित क्रॉस ब्राउज़र संगत संस्करण देखना चाहते हैं, तो $ .ajax के लिए स्रोत पर एक नज़र डालें - अकेले इस विधि के लिए यह लगभग jQ के ओवरहेड के लायक है।
  • DOM सिलेक्शन - इवेंट्स को बाइंड करने और DOM एलिमेंट्स को सिलेक्ट करने जैसी सिंपल चीजें कॉम्प्लेक्स हो सकती हैं और प्रति ब्राउजर में अंतर हो सकता है। बहुत सारे ज्ञान के बिना, वे भी आसानी से खराब लिखे जा सकते हैं और आपके पृष्ठ को धीमा कर सकते हैं।
  • भविष्य की सुविधाओं तक पहुंच - .indexOf और .bind जैसी चीजें देशी जावास्क्रिप्ट हैं, लेकिन अभी तक कई ब्राउज़रों द्वारा समर्थित नहीं हैं। हालांकि, इन विधियों के jQuery संस्करणों का उपयोग करने से आप उन्हें क्रॉस ब्राउज़र का समर्थन करने की अनुमति देंगे।

जावास्क्रिप्ट अब केवल एक क्लाइंट साइड भाषा नहीं है, और क्योंकि jQuery बहुत डोम निर्भर है, इसलिए सर्वर पर जाना एक भयानक उम्मीदवार है। मैं यह समझने में कुछ समय लगाने की सलाह देता हूं कि आप jQuery का उपयोग क्यों कर रहे हैं (यह सवाल पूछना एक महान पहला कदम है!), और मूल्यांकन करते समय कि यह आवश्यक है। jQuery खतरनाक हो सकता है, मुख्य खतरों में से कुछ हैं:

  • कोड की गुणवत्ता - jQuery में एक विशाल समुदाय और कम सीखने की अवस्था है। यह खराब तरीके से लिखे गए ओपन सोर्स प्लगइन्स के लिए एक आदर्श तूफान है।
  • अक्षमता - jQuery को अक्षम रूप से लिखना आसान है। उदाहरण के लिए, लूप के बजाय jQuery के प्रत्येक का उपयोग करना अनावश्यक है और कुछ मामलों में प्रदर्शन प्रभाव हो सकता है। JSPerf में इस सामान के बारे में अच्छी जानकारी के बहुत सारे
  • ब्लोट - jQuery एक विशाल पुस्तकालय है। अधिकांश समय, आप इसकी विशेषताओं के एक छोटे उपसमुच्चय का उपयोग करेंगे, और पूरे पुस्तकालय को पकड़ लेंगे। कुछ महान विकल्प हैं जो आपको सुविधाओं के सबसेट देंगे, जैसे कि zepto.js, और underscore.js - आपकी स्थिति के आधार पर, आप अपनी आवश्यकताओं के लिए सही पुस्तकालय चुनकर कुछ बाइट्स बचा सकते हैं।

अंततः, jQuery एक अविश्वसनीय रूप से उपयोगी और सहायक पुस्तकालय है, जब इसे ठीक से उपयोग किया जाता है। हालाँकि, यह जावास्क्रिप्ट का विकल्प नहीं है । यह एक पुस्तकालय है, जैसे कि zepto.js , YUI , Dojo , MooTools , और प्रोटोटाइप - जिनमें से एक आपके वर्तमान प्रोजेक्ट के लिए एक बेहतर विकल्प हो सकता है।

जावास्क्रिप्ट एक गलत भाषा है, और केवल हाल ही में ज्यादातर लोगों द्वारा एक स्क्रिप्टिंग भाषा से अधिक के रूप में माना जा रहा है। मैं वास्तव में इसे और अधिक पढ़ने की सलाह देता हूं, यहां कुछ अच्छी जगहों को शुरू करना है:

संपादित करें 07/2014 - मैंने देखा कि इस पोस्ट पर अभी भी ध्यान आ रहा है, इसलिए मैंने लिंक का एक गुच्छा जोड़ा। ये किसी विशेष क्रम में नहीं हैं, लेकिन सहायक होने चाहिए।

  • बेन अल्मन का ब्लॉग - यहाँ बहुत सारी अच्छी प्रथाएँ हैं। मैं उन सभी से सहमत नहीं हूं, लेकिन मैं हर समय उनके ब्लॉग से नई चीजें सीखता हूं।
  • कोड अकादमी - मूल जावास्क्रिप्ट और jQuery प्रशिक्षण। कभी-कभी मूल बातें वापस जाने से मदद मिलती है।
  • जावास्क्रिप्ट गार्डन - जावास्क्रिप्ट की अधिक मुश्किल या गलतफहमी सुविधाओं के बारे में एक पोस्ट। कृपया इसे समय-समय पर पढ़ें, जब तक कि सब कुछ समझ में न आए।
  • Bocoup - ये प्रशिक्षण वर्ग हैं। यदि आप एक के पास हैं, तो उस पर जाएं। सबसे अच्छा जेएस वक्ताओं और शिक्षकों में से कई ये सिखाते हैं।
  • पॉल आयरिश का ब्लॉग - सख्ती से जेएस नहीं, लेकिन यहां बहुत सारी सर्वोत्तम प्रथाओं को लिखा गया है। उसे और बेन के ट्विटर फ़ीड दोनों का अनुसरण करने के लिए महान हैं।
  • जावास्क्रिप्ट: द गुड पार्ट्स - जिसे अक्सर 'द जावास्क्रिप्ट ग्लास' कहा जाता है, डगलस क्रॉकफोर्ड की यह किताब जावास्क्रिप्ट को समझने की शुरुआत करने के लिए एक अद्भुत जगह है।
  • इसहाक श्लिटर का ब्लॉग - इसहाक npm का निर्माता है, और नोड कोर पर काम करता है। वह जावास्क्रिप्ट समुदाय के बारे में कोड सम्मेलनों के बारे में बहुत कुछ लिखता है, लेकिन अगर आप वास्तव में js में आ रहे हैं तो यह एक बहुत अच्छा पढ़ा है।
  • डगलस क्रॉफोर्ड की जावास्क्रिप्ट - यदि ब्रेंडन ईच जावास्क्रिप्ट के पिता हैं, तो डगलस जावास्क्रिप्ट के मुखर चाचा हैं। वह JSON युक्ति, जावास्क्रिप्ट बाइबिल के लेखक हैं, और जावास्क्रिप्ट के quirks और उल्कापिंड वृद्धि पर बहुत सारे अद्भुत पोस्ट हैं।
  • ब्रेंडन आइच का ब्लॉग - ब्रेंडन जावास्क्रिप्ट का निर्माता है - वह अपने ब्लॉग पर सभी प्रकार के मूर्खतापूर्ण सामानों के बारे में लिखते हैं, और जबकि एक व्यक्ति के रूप में उनके दोष हैं, उनकी जावास्क्रिप्ट पोस्ट मूल्यवान हैं।
  • जेम्स हैलीडे (@substack) ब्लॉग - सबस्टैक यकीनन समुदाय में सबसे महत्वपूर्ण नोड है। डेवलपर - लगभग 400 (और हर दिन बढ़ रहा है) npm मॉड्यूल और छोटे, यूनिक्स जैसे मॉड्यूल का एक मार्गदर्शक दर्शन, जो कुछ भी वह लिखता है वह सब लायक है पढ़ने।
  • मैक्स ऑग्डेन का ब्लॉग मैक्स ऑग्डन एक और विपुल नोड लेखक है। और यह ब्लॉग पोस्ट लिखने में उत्कृष्ट है जो आपको कुछ सिखाता है। वह बिल्लियों के लिए जावास्क्रिप्ट के लेखक (दूसरों के साथ मेरा मानना ​​है) भी है।
  • बिल्लियों के लिए जावास्क्रिप्ट - यह एक छोटा ट्यूटोरियल है जो आपको बिल्ली के परिप्रेक्ष्य से जावास्क्रिप्ट की मूल बातें के माध्यम से ले जाता है। यदि आप एक शुरुआत कर रहे हैं, इस के माध्यम से पढ़ें। यह मजेदार है, और एक घंटे में सिखाता है कि कई पुस्तकों को संवाद करने में कितने सप्ताह लगते हैं।
  • निकोलस ज़कस का ब्लॉग निकोलस कुछ शानदार जावास्क्रिप्ट किताबों का लेखक है: ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग इन जावास्क्रिप्ट , मेनटेनटेबल जावास्क्रिप्ट , वेब डेवलपर्स के लिए प्रोफेशनल जावास्क्रिप्ट , और हाई परफॉर्मेंस जावास्क्रिप्ट । वह मुख्य रूप से ग्राहक पर ध्यान केंद्रित करता है, लेकिन उसके पास सर्वोत्तम प्रथाओं और प्रदर्शन युक्तियों का एक टन है।
  • गुइलेर्मो राउच का ब्लॉग - गुइलर्मो एक और विपुल नोड है।जेएस देव है, जो ज्यादातर सॉकेट के लिए प्रसिद्ध है। उनका ब्लॉग (और उनकी नई किताब, स्मैशिंग नोड ) दोनों महान संसाधन हैं।

मुझे यकीन है कि बहुत अधिक महान संसाधन हैं जिनके बारे में मैं नहीं सोच रहा हूं या नहीं जानता हूं, अन्य उत्तरदाताओं को उस सूची में जोड़ने के लिए स्वतंत्र महसूस करना चाहिए।


3
जेएस पर टिप्पणी के लिए +1 अब केवल क्लाइंट-साइड भाषा नहीं है और इस सब में JQuery कैसे फिट बैठता है।
शिवन ड्रैगन

1
ध्यान दें कि सभी फ़ंक्शंस ऑब्जेक्ट हैं, लेकिन जावास्क्रिप्ट में सब कुछ के पास लानत है। $ को "क्लास-लेवल" गुणों के साथ एक फ़ंक्शन के रूप में वर्णित किया गया है, जिस पर इसे पिन किया गया है जैसे ( $.ajax) कि डोम तत्वों के रैपर ऑब्जेक्ट सेट करता है जिसका मतलब है कि डोम तरीके को सामान्य रूप से पीटीए बनाने के लिए उन्हें अधिक संक्षिप्त करके, तरीकों के होने से बहुत कम है। डोम ऑब्जेक्ट्स के सेट पर ऑटो-लूप जब भी यह समझ में आता है, और ब्राउज़रों के बीच एक आम, पूर्वानुमानित एपीआई साझा करना (जो कि एक मुद्दा IE <= 8 से कम है)।
एरिक रेपेन

1
यह एक महान पोस्ट है, लेकिन मैं एक बिंदु के साथ मुद्दा लेना चाहता हूं - "विशाल पुस्तकालय ... Zepto / Underscore का उपयोग करें" - पहला, अंडरस्कोर एक पूरी तरह से अलग प्रकार का पुस्तकालय है - मुख्य रूप से सरणियों / वस्तुओं से निपटने के लिए - प्लस लोशन का उपयोग करें इसके बजाय, यह तेज है। दूसरा, Zepto छोटा है क्योंकि यह उन चीजों को कवर नहीं करता है जो jQuery करता है। कि कीड़े jQuery के लिए तय हो सकता है। अंत में, jQuery नहीं है कि विशाल / monolythic अब, यह एक बार gzipped के बारे में 30Kb है, और आप 1 कम छवि का उपयोग करके बचा सकते हैं। मेरे लिए, देव दक्षता प्राप्त उन बाइट्स के लायक है।
लोकलपीसीग्यि

1
@LocalPCGuy निश्चित रूप से कुछ अच्छे अंक। यह पोस्ट (ठीक-ठीक! 2 साल पहले) थी, और तब से निश्चित रूप से js पारिस्थितिकी तंत्र में चीजें बदल गई हैं। उदाहरण के लिए, मैं व्यक्तिगत रूप से किसी भी विश्व स्तर पर नामांकित पुस्तकालय के बजाय ब्राउज़र और छोटे मॉड्यूल का उपयोग करता हूं। हालांकि, मुझे लगता है कि मूल आधार अभी भी सही है, जो कि कई (अधिकांश?) मामलों के लिए है, एक रसोई सिंक पुस्तकालय शायद ही कभी आवश्यक है। मैं यह सुनिश्चित करने के लिए अधिकांश देवों के सामने रखूंगा कि वे पुस्तकालयों के आकार की लागत को उचित रूप से उपयोग करने का निर्णय लेने से पहले इसका औचित्य सिद्ध करें क्योंकि यह आपकी आवश्यकता के बारे में विशिष्ट होने की तुलना में आसान है।
जेसी

1
सभी चीजों पर प्रतिक्रिया करें, क्या मैं सही हूँ?!?!? / व्यंग्य - कैसे काम के लिए सही उपकरण उठाओ @ और, और यह हमेशा प्रतिक्रिया नहीं है। मुझे लगता है कि रिएक्ट कुछ अच्छी चीजें कर रहा है, लेकिन यह दिखावा नहीं करता है कि यह जावास्क्रिप्ट दुनिया के लिए एक इलाज है।
लोकलपीसीग्युई

17

वहाँ फायदे हैं, लेकिन यह बहस का मुद्दा है कि क्या वे वास्तव में कमियां हैं।

मुख्य एक यह है कि आप बैंडविड्थ बचाते हैं और तेजी से प्रतिक्रियाएं प्राप्त करते हैं। jQuery आपकी प्रतिक्रिया में एक और ~ 30kb जोड़ता है। कुछ नेटवर्क पर (और कुछ देशों में), इसका मतलब कुछ और मिलीसेकंड हो सकता है। दूसरी ओर, हालाँकि, आप अपने वेब सर्वर (या जैसा कि Xion ने कहा है, का उपयोग करके आसानी से इसके लिए कैशिंग सेट कर सकते हैं, इसलिए इसे Google की साइट से उपयोग करें ताकि यह आपके स्वयं पर प्रभाव न डाले, और अभी भी कैश नहीं किया जाएगा)।

दूसरी बात यह है कि आपको केवल कुछ बहुत ही सरल कार्यक्षमता की आवश्यकता हो सकती है, और केवल डाउनलोड करने और स्थापित करने के लिए jQuery को लागू करने से अधिक समय लग सकता है जो आपको चाहिए।

और अंत में, आप अपने स्वयं के ढांचे को रोल करना चाह सकते हैं, जो कि ज्यादातर एक बुरा विचार है, लेकिन कुछ लोगों के पास इसके कारण हैं।

यदि आप jQuery को केवल इसलिए छोड़ देते हैं क्योंकि आप सीखने की अवस्था से भयभीत हैं, तो आपको पुनर्विचार करना चाहिए। विशेष रूप से यह बल्कि कोमल के रूप में।


सहमत, विशेष रूप से बैंडविड्थ भाग के बारे में। JQuery 1.8.2 में कम से कम / obfuscated संस्करण में 92Kb है। इस बात से भी सहमत थे कि ये बहुत मजबूत कारण नहीं हैं कि JQuery का उपयोग न करें। धन्यवाद!
शिवन ड्रैगन

1
@ शिवनद्रगन: आप गज़िप भूल गए। जो इसे बहुत छोटा बनाता है ।
ThiefMaster

@ThiefMaster: यह सच है, इसे इंगित करने के लिए धन्यवाद।
शिवन ड्रैगन

10
यदि आप CDN (जैसे Google एक) से jQuery का उपयोग करते हैं, तो संभावना है कि उपयोगकर्ता इसे अन्य साइटों पर जाने से पहले से लोड करेंगे। इसलिए आपके औसत (अधिकतम नहीं) प्रतिक्रिया समय पर प्रभाव छोटा होगा।
सियोन

1
@Phil तुम भी इसका इस्तेमाल क्यों करते हो?!?!? jQuery कभी नहीं किया गया है और कभी भी ज़रूरत नहीं होगी। यह शुद्ध शैतानी बुराई है (शेष शैतानी गिरोह के साथ: ReactJS, Underscore, LoDash, Modernizr, CommonJS, Angular, Google Analytics, विशेष रूप से AMD, आदि)। व्यक्तिगत रूप से, मैंने कभी भी एक पूरी लाइब्रेरी को शामिल नहीं किया है (हालांकि मुझे शायद ही कभी पुस्तकालयों से आवश्यक विशिष्ट कार्यों को निकालना और अनुकूलित करना है), मैं कभी भी एक पूरी लाइब्रेरी शामिल नहीं करूँगा, और लगभग हर वेबपेज पर मैं 11 फ्रेम से कम समय में डायल अप इंटरनेट पर भार बनाता हूं। (1/59 सेकंड का)।
जैक गिफिन

14

जहां तक ​​मुझे पता है कि वास्तव में वैनिला जावास्क्रिप्ट बनाम एक पुस्तकालय जैसे कि जिवा , म्यूओल्स , आदि का उपयोग करने के केवल दो फायदे हैं ।

  • पुस्तकालयों में एक पेलोड होता है जो बैंडविड्थ खाता है। लेकिन जैसा कि लोगों ने पहले ही दूसरे उत्तरों में बताया है कि आप इसे गिपिंग और कैशिंग के साथ सीमित कर सकते हैं। यदि आप केवल jQuery का एक सबसेट चाहते हैं, तो आप SizzleJS के साथ कर सकते हैं और MooTools के साथ आपके पास उस सुविधा सेट का चयन करने का विकल्प है जिसे आप उसी तरह से चाहते हैं जैसा कि मॉर्डनिजर करता है
  • पुस्तकालय बड़े हैं और सीखने में कुछ समय लगता है। फिर, यह डेवलपर्स के लिए एक बार का निवेश है ... और जावास्क्रिप्ट लाइब्रेरी को जानने के लिए आपके रिज्यूम पर अच्छा लगता है।
  • (बोनस) पुस्तकालय एक चांदी की गोली नहीं हैं इसलिए यदि आप पहिया को मजबूत करना पसंद करते हैं तो यह निश्चित रूप से जाने का रास्ता है।

यह इंगित करने योग्य है कि आप जावास्क्रिप्ट लाइब्रेरी का उपयोग क्यों करना चाहते हैं, जिसके लिए बहुत सारे हैं:

  • आपको अपने विकास का समर्थन करने के लिए अपने स्वयं के ढांचे को लिखने की आवश्यकता नहीं है। यदि आप उत्सुक हैं कि चीजें कैसे काम करती हैं तो आप कोड की जांच कर सकते हैं क्योंकि यह खुला स्रोत है।
  • लायब्रेरीज़ ब्राउज़र संगतता को हल करती है। DOM और जावास्क्रिप्ट दोनों में ब्राउज़र के बीच कुछ अंतर है। मेरा विश्वास करो, यह एक बड़ा समय सिंक है अगर आपको खुद को फिक्स करना है।
  • यह जावास्क्रिप्ट पुस्तकालयों का उपयोग करने के लिए इंटरनेट का वास्तविक मानक है, उनमें से ज्यादातर अब तक अच्छी तरह से प्रलेखित हैं और अधिकांश वेब डेवलपर्स (जो जावास्क्रिप्ट को जानते हैं) जानते हैं कि उनका उपयोग कैसे करना है।
  • पुस्तकालय का उपयोग करते समय आप वास्तव में जावास्क्रिप्ट नहीं देते हैं। आपको अभी भी जावास्क्रिप्ट को इसके प्रकार, ऑब्जेक्ट, काम बंद करने आदि के साथ जानना होगा ।
  • अधिकांश पुस्तकालयों को संशोधित किया जाता है और प्लगइन्स लिखने या आवश्यकता और एएमडी पैटर्न का उपयोग करने में लंबा समय नहीं लगता है ।
  • DOM से CSS सेलेक्ट करने वाले एलिमेंट्स एक बहुत बड़ी मदद है।
  • (बोनस) आप उन्हें कॉफीस्क्रिप्ट के साथ भी उपयोग कर सकते हैं ।

मैं एक वेब शॉप पर काम करता था जो वैनिला जावास्क्रिप्ट का उपयोग करने पर अड़ी थी क्योंकि jQuery बड़ा और डरावना था। यह निर्णय, जो ज्यादातर एक "javascript डेवलपर" से प्रभावित था, कई ब्राउज़र बग्स और धीमे विकास का स्रोत था और अपने कोडबेस में आने की कोशिश करना एक बाल खींचने वाला अनुभव था। अपनी खुद की रूपरेखा लिखना एक अच्छे विचार की तरह लग सकता है, लेकिन अगर आप नए डेवलपर्स को रखना चाहते हैं तो वे जल्दी से आशा नहीं कर सकते हैं और मदद नहीं कर सकते हैं । फिर विचार करने के लिए बस कारक का मुद्दा भी है ।

जैसा कि मैंने कहा कि मैं वहाँ काम करता था ... अन्य जगहों पर हरियाली वाले चरागाह थे। : ^)


10

मैं दोनों का उपयोग थोड़ा सा मिश्रण करने के लिए होता हूं। इसका सबसे बड़ा कारण यह है कि कुछ अनुप्रयोगों के लिए (क्रोम एक्सटेंशन के बारे में सोचें) आपको क्रॉस ब्राउज़र समर्थन की आवश्यकता नहीं है। जिसका अर्थ है कि मैं css3 जैसी नई प्रगति का लाभ उठा सकता हूं, जो संक्रमण जैसी चीजों के साथ आपके कोड को jquery के उपयोग के एक टन को सरल बना सकता है।

इसके अलावा मैं अक्सर कुछ कस्टम कर रहा हूँ। हर तरह से दूसरों ने कहा कि आपको पहिया का फिर से आविष्कार नहीं करना चाहिए। लेकिन जब आपके द्वारा कुछ पागल कार्यक्षमता करने के लिए कहा जाता है, तो मैं अक्सर इसे लिखने के लिए खुद को लिखने की कोशिश करना आसान बनाता हूं और कुछ jquery प्लगइन को बंद कर देता हूं जो एक करीबी मैच नहीं है।

मैंने ऐसे डेवलपर्स के साथ भी काम किया है जो बिना जेकरी के साथ काम करते हैं। और मुझे यह कहना होगा कि उन्होंने कार्यक्षमता पर कहीं अधिक बार समझौता किया है, तब नहीं जब उन्हें एक jquery प्लगइन नहीं मिला जो कि वे चाहते थे।

वेब डेवलपमेंट के कुछ बिंदु पर आपको लाइब्रेरी में प्री-पैकेज्ड नहीं कुछ करने के लिए कहा जाएगा। तो उस बिंदु पर आप बेहतर सुनिश्चित करते हैं कि आप समझते हैं कि आधार भाषा वास्तव में कैसे कार्य करती है।

तो TLDC : दोनों का उपयोग करें, आप सिर्फ वेनिला का उपयोग कर नुकसान में हैं और यदि आप वेनिला को अंदर और बाहर नहीं जानते हैं और हमेशा jquery का उपयोग करने पर जोर देते हैं तो आप नुकसान में हैं।


3
शुद्ध वेनिला js जाने का रास्ता है!
11

लिटिल रेयान को पता है कि jQuery चुपके document.querySelectorAllसे पर्दे के पीछे रहता है।
जैक ग्रिफिन

6

केवल एक चीज जो मैं सोच सकता हूं कि आप JQuery के बिना नहीं कर सकते JQuery प्लगइन्स का उपयोग करना होगा; फिर भी, आप अपनी खुद की JS लाइब्रेरी लिख सकते हैं जो कि प्लगइन की जरूरत है।

इसके बारे में इस तरह से सोचें: JQuery जावास्क्रिप्ट में लिखित एक ओपन-सोर्स जावास्क्रिप्ट लाइब्रेरी है; आप स्रोत को देख सकते हैं, और इस तरह कुछ भी करना सीख सकते हैं।

आप सादे पुराने जावास्क्रिप्ट का उपयोग किए बिना JQuery का उपयोग नहीं कर सकते। आप शायद उपयोग नहीं करेंगे document.getElementById, लेकिन आप अभी भी मानक जावास्क्रिप्ट तरीके में कार्यों और चर को परिभाषित करेंगे; आप एक मानक forलूप भी लिख सकते हैं ।

JQuery का उपयोग करने का मुख्य लाभ किसी भी भाषा में किसी भी तीसरे पक्ष के पुस्तकालय के रूप में बहुत अधिक है: आपको अपने आवेदन के लिए तर्क को लागू करने के लिए उतना कोड नहीं लिखना होगा।

आकार को आपको डराने न दें। CDN संस्करण एक ~ 33k डाउनलोड जिसके बाद प्रथम पृष्ठ हिट उपयोगकर्ता के ब्राउज़र द्वारा संचित किया जाएगा है।


6

यदि आप प्रदर्शन के बारे में चिंतित हैं, तो आपको जब भी संभव हो, वेनिला जेएस का उपयोग करने का प्रयास करना चाहिए । चौखटे न केवल बैंडविड्थ ओवरहेड जोड़ते हैं, बल्कि ओवरहेड प्रसंस्करण भी करते हैं। और jQuery सुंदर पुराने ब्राउज़रों के लिए ब्राउज़र संगतता के साथ आता है।

यदि आप मोबाइल ऐप या गेम (या दोनों संयुक्त) पर काम कर रहे हैं, तो आपको पहले प्रदर्शन और रीसोर्स इफिसिएन्सी की आवश्यकता है।

jQuery और प्लगइन्स आपके विकास को गति दे सकते हैं, लेकिन विशेष रूप से यदि आप 3rd पार्टी jquery प्लगइन्स पर भरोसा करते हैं तो आपको पता होना चाहिए कि वे अंदर क्या कर रहे हैं। उनमें से बहुत सारे कोड गुणवत्ता और दक्षता के बुरे उदाहरण हैं।

देशी जावास्क्रिप्ट की तुलना में jQuery 2 से 10 गुना धीमा हो सकता है। और यह आसानी से डेवलपर्स को अपने इंटरफ़ेस को ठीक से डिज़ाइन नहीं करने के लिए प्रोत्साहित कर सकता है और jQuery के चयनकर्ताओं पर बहुत अधिक निर्भर करता है जो मूल की तुलना में बहुत धीमी हैं।


+1, मैं आपसे सहमत हूं कि खेल बनाने का एक अच्छा कारण है प्रदर्शन के कारणों के कारण, जेनिला को वेनिला जेएस के पक्ष में खाई करना। जब यह उनके साथ एक खेल बनाने की बात आती है तो यह अधिकांश भाषाओं के लिए बहुत अधिक सच है। उदाहरण के लिए, Google लोग अपने एंड्रॉइड डॉक्स में सलाह देते हैं कि गेम बनाते समय (पुस्तकालयों में, एंड्रॉइड के लिए) पुस्तकालयों को न केवल खोदें, बल्कि गति के पक्ष में कुछ अच्छे कोडिंग अभ्यासों को भी खोदें।
शिवन ड्रैगन

... यदि आप कुशल डोम हेरफेर के बारे में ज्यादा जानते हैं जैसे कि jQuery लिखने वाले लोग, हाँ।
एरिक रेपेने

@ ErikReppen कृपया वास्तव में "jQuery लिखने वाले लोगों" से वास्तविक स्रोत कोड की जांच करें। मुझे लगभग 23 महीने तक सिर्फ 23 लाइनों में देखा गया था।
जैक गिफिन

2013 के बाद से JQ में बहुत कुछ बदल गया है।
एरिक रेपेन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.