क्यों मैं अभी भी jQuery का उपयोग की कहानी

जब यह jQuery की बात आती है, तो कई लोग कहते हैं, “बस नियमित जावास्क्रिप्ट का उपयोग करें। आपको एक jQuery लाइब्रेरी की आवश्यकता नहीं है। " मैं क्या कह सकता हूं? मुझे कई चीजों की आवश्यकता नहीं है, लेकिन इसके बावजूद, जब वे होते हैं तो यह अच्छा होता है। तो jQuery है। मुझे इस लाइब्रेरी की आवश्यकता नहीं है, लेकिन इसे हाथ में लेना निश्चित रूप से अच्छा है।

साइटें जैसे आपको jQuery की आवश्यकता नहीं है (YMNJQ) इस विचार को बढ़ावा दे रहे हैं कि jQuery से छुटकारा पाना बहुत आसान है। लेकिन इस साइट पर बहुत पहले उदाहरण का उपयोग करने के लिए एक अच्छा कारण jQuery दर्शाता है। वहां, कोड की एक साधारण jQuery लाइन को नियमित JS की 10 लाइनों के साथ बदल दिया जाता है!

अधिकांश जावास्क्रिप्ट एपीआई, विशेष रूप से जो डोम के साथ काम करने पर ध्यान केंद्रित करते हैं, मेरी सौंदर्य इंद्रियों को रोकते हैं। यह है, इसे हल्के ढंग से रखना, उनके प्रति मेरा दृष्टिकोण। सीधे बात करते हुए, मुझे लगता है कि ये एपीआई पूरी तरह से बुरे सपने हैं। उदाहरण के लिए, el.insertAdjacentElement('afterend', other) निश्चित रूप से काम करता है। लेकिन बहुत अच्छा लग रहा है $(el).after(other) । हालांकि मुझे वास्तव में $() फ़ंक्शन का लुक पसंद नहीं आया, यह हमारे साथ DOM के साथ काम करने के लिए मानक API की तुलना में अतुलनीय रूप से बेहतर है। मुझे पता है कि $() बजाय $() आप jQuery(sel) या window.jq = jQuery जैसी किसी चीज़ का उपयोग कर सकते हैं। लेकिन मैं वायुहीन अंतरिक्ष में कार्यक्रम नहीं करता हूं। इसलिए, मैं मानक तकनीकों का उपयोग करना पसंद करता हूं। मुझे नहीं पता कि यह अच्छा है या बुरा, लेकिन jQuery का उपयोग करने के लिए मानक $() निर्माण है।

डोम का उपयोग करके किसी अन्य तत्व का पड़ोसी तत्व प्राप्त करने का तरीका जल्दी से याद करने की कोशिश करें। इसके लिए मुझे क्या उपयोग करना चाहिए - nextSibling या nextElementSibling क्या अंतर है? और कौन से ब्राउज़र इस या उस विधि का समर्थन करते हैं? जब आप इसे याद रखने और एमडीएन को देखने की कोशिश कर रहे हैं, तो अपने आप को जांचते हुए, मैं, jQuery का उपयोग करके, बस next() या prev() लिखें।

जावास्क्रिप्ट एपीआई में कार्यान्वित कई सामान्य संचालन करना असुविधाजनक है। मैं यहां इस तरह के ऑपरेशन की पूरी सूची दे सकता हूं, लेकिन मेरे लिए यह पूरी तरह से YMNJQ पेज पर था।

जेएस टूल्स का उपयोग करके विभिन्न सरल समस्याओं को हल करने के लिए, सहायक कार्यों की आवश्यकता होती है। और YMNJQ वेबसाइट पर, फिर से, आप कई उदाहरण पा सकते हैं। JQuery का उपयोग करना आपके प्रोजेक्ट कोड में ऐसे सहायक कार्यों को शामिल करने का एक मानक तरीका है। उसी समय, प्रोग्रामर को हर बार ज़रूरत नहीं होती है कि उसे अपनी बांह पर लगे स्टैक ओवरफ्लो के पहले उत्तर से कोड के टुकड़े हड़पने के लिए कुछ इस तरह की आवश्यकता हो।

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

क्या मुझे हमेशा jQuery का उपयोग करना चाहिए? नहीं, बिल्कुल नहीं। किसी भी अतिरिक्त निर्भरता परियोजना की जटिलता में वृद्धि और इसके कोड की मात्रा में वृद्धि है। लेकिन jQuery एक बड़ी लाइब्रेरी नहीं है। मानक असेंबली, छोटा और संपीड़ित, 30 Kb लेता है। अजाक्स के बिना कस्टम असेंबली और शायद ही कभी इस्तेमाल की जाने वाली विशेषताएं 23 Kb हैं। और असेंबली, जो querySelector बजाय querySelector का उपयोग करता है, केवल 17 Kb लेता है। कई समस्याओं को हल करने के लिए, मैं 30 Kb की मानक विधानसभा, और 17 Kb की अनुकूलित विधानसभा से काफी खुश हूं।

यहाँ आप देख सकते हैं कि बूटस्ट्रैप से jQuery को हटाने और नियमित JS पर स्विच करने में कितना प्रयास किया गया है।

डेवलपर्स ने अपने स्वयं के सहायक कार्यों को लिखा है। उन्हें IE समर्थन को छोड़ना पड़ा, क्योंकि इस तरह के समर्थन को लागू करना बहुत मुश्किल था। उन्होंने एपीआई को असंगत बना दिया ("हमने सब कुछ तोड़ दिया") और इस सब पर डेढ़ साल बिताए। मैं यह नहीं कह सकता कि जो हुआ, वह जितना हुआ उससे कहीं बेहतर है।

मैं बूटस्ट्रैप को नियमित जेएस में अनुवाद करने के कारणों को समझता हूं। उदाहरण के लिए, डेवलपर्स बूटस्ट्रैप का उपयोग Vue.js या कुछ इसी तरह करना चाहते हैं। और Vue.js और एक परियोजना में jQuery पहले से ही एक सा है। मैं वेब पर अनावश्यक कोड की मात्रा को कम करने का एक बड़ा समर्थक हूं (और यहां इस बारे में कुछ सामग्री है)। लेकिन यहां मैं स्थिति को एक व्यावहारिक और यथार्थवादी दृष्टिकोण से देखने का प्रस्ताव करता हूं। क्या बूटस्ट्रैप में 17 KB jQuery कोड का समावेश है - क्या यह इतना बुरा है? जब मैं कहता हूं कि मध्यम या न्यूयॉर्क टाइम्स जैसी साइटों को देखने के लिए आपको जावास्क्रिप्ट कोड की मेगाबाइट से अधिक डाउनलोड करने की आवश्यकता है, तो इस स्थिति से बचाने के लिए, वे मुझसे पूछते हैं कि क्या मैं किसी 56-किलोबाइट मॉडेम लाइन पर बैठा हूं। मेगाबाइट जेएस ठीक है। क्या 17Kb jQuery वास्तव में भारी है?
JQuery का उपयोग नहीं करने के लिए अच्छे कारण हैं। उदाहरण के लिए, jQuery की जरूरत नहीं है यदि आप कोड लिख रहे हैं जिसे आप दूसरों के साथ साझा करना चाहते हैं, या यदि आप कुछ छोटे फ़ंक्शन बना रहे हैं। लेकिन क्यों सिर्फ इतना अंदर बाहर बारी के रूप में jQuery का उपयोग नहीं? यदि आप सिर्फ $() लिख सकते हैं तो यह सब प्रयास क्यों? मुझे नहीं लगता कि jQuery का उपयोग हर जगह और हमेशा किया जाना चाहिए, लेकिन मुझे नहीं लगता कि jQuery की कट्टर अस्वीकृति सही है।

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

कई पाठकों को आश्चर्य हो सकता है कि इस सामग्री के संदर्भ में मैं क्या कह सकता हूं, Vue.js, प्रतिक्रिया और अन्य आधुनिक रूपरेखाओं के बारे में कह सकते हैं। लेकिन इस लेख का लक्ष्य समुदाय को "ग्रैंडियोस जनरल फ्रंटेंड डेवलपमेंट थ्योरी" की पेशकश करने के बजाय, सादे जावास्क्रिप्ट और jQuery को मैप करना है।

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

क्या इसका मतलब यह है कि आधुनिक वेब फ्रेमवर्क और शक्तिशाली पुस्तकालय हमेशा खराब होते हैं? नहीं, यह नहीं है। बहुत कम हमेशा बुरे या अच्छे कहे जाने के योग्य है। लेकिन फ्रेमवर्क का उपयोग करने का मतलब कुछ समझौता करना है (यह, निश्चित रूप से, jQuery के लिए सच है)।

सामान्य तौर पर, मैं वेब को दस्तावेजों को देखने के लिए एक वातावरण के रूप में देखता हूं, और ऑपरेटिंग सिस्टम की तरह कुछ नहीं। और "दस्तावेज़ दृष्टिकोण" न केवल नियमित साइटों के लिए, बल्कि कई "वेब एप्लिकेशन" (जो भी आप इसे कहते हैं) के लिए अच्छा है।

प्रिय पाठकों! क्या आप jQuery का उपयोग करते हैं?