बहुत अधिक जावास्क्रिप्ट का उपयोग करने का नकारात्मक हिस्सा क्या है?

Question

मैं जानना चाहता हूं कि वेब पेज में बहुत अधिक जावास्क्रिप्ट कोड का उपयोग करके कुछ डाउनसाइड्स क्या हैं?

उदाहरण के लिए, मैं अपने ड्रॉपडाउन मेनू, टैब और accordion के लिए एक jQuery ढांचे का उपयोग करूंगा। और मेरे कैलेंडर के लिए अन्य जावाScripts (भले ही उपलब्ध कैलेंडर उपलब्ध है जो jQuery का उपयोग करता है) और अन्य सामग्री के लिए अन्य जावास्क्रिप्ट? प्रभाव क्या है? (मेरी राय जावास्क्रिप्ट का विरोधी है और लोड करने के लिए भारी है)

मुझे कई डेवलपर्स पता हैं जो 2 से अधिक जावास्क्रिप्ट ढांचे में स्वामी हैं। मेरा सवाल है: एक परियोजना विकसित करते समय आप उस परियोजना के लिए जावास्क्रिप्ट ढांचे को कैसे चुनते हैं? आप उस परियोजना के लिए MooTools या jQuery का उपयोग क्यों करेंगे? (मुझे पता है कि पसंद का मामला है), लेकिन क्या कोई अन्य कारण है? Mootools की तरह यह अच्छा है ... या jQuery इसके लिए अच्छा है ..

मैं आपको राय सुनना चाहता हूं।

Answer 1

वेबसाइट में कई जावाकैम का उपयोग करके कुछ नकारात्मक क्या हैं?

• HTTP भूमि के ऊपर
• कम रख-रखाव की

तुम क्यों MooTools या jQuery कि इस परियोजना के लिए प्रयोग करेंगे?

यह व्यक्तिगत स्वाद का मामला नहीं है। अधिक जानकारी के लिए this question देखें।

विशिष्ट चीजों के लिए वहां विशिष्ट ढांचे हैं - उदाहरण के लिए Ext JS लें, जो किसी साइट की ज़रूरतों को पूरा करने की कोशिश करता है। यह jQuery नहीं करता है।

Answer 2

यह ब्राउज़र (और बैक एंड) पर निर्भर करेगा और यह कई स्क्रिप्ट पर कैसे प्रदर्शन/स्केल करेगा। समाधान विकसित करते समय दर्शकों की आवश्यकताओं के बारे में पहले सोचें। क्या वे सुपर फास्ट फाइबर ऑप्टिक लिंक या जीपीआरएस लिंक वाले छोटे फोन पर क्वाड कोर राक्षसों को चलाने जा रहे हैं। फिर तय करें कि कौन सी तकनीकें उन आवश्यकताओं को भरेंगी।

पहले तकनीक से शुरू न करें।

Answer 3

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

प्रदर्शन अलग-अलग, कई ढांचे का मतलब कम रखरखाव कोड भी है, क्योंकि रखरखावकर्ताओं को उनके साथ काम करने में सक्षम होने के लिए प्रत्येक ढांचे से परिचित होना चाहिए।

शायद कुछ अपवाद हैं, जैसे कि सामान्य रूपरेखा का उपयोग jQuery जैसे सामान्य फ्रेमवर्क जैसे राफेल की तरह, लेकिन आमतौर पर प्लगइन द्वारा हल किया जाता है।

Answer 4

अपने प्रश्न से, मुद्दों के एक जोड़े दिमाग में आते हैं:

• थोड़ा स्क्रिप्ट फ़ाइलें का एक बहुत हो रही है एक प्रदर्शन समस्या हो सकती है। यदि आप कई अलग-अलग स्क्रिप्ट का उपयोग करने जा रहे हैं, तो उन्हें एक स्क्रिप्ट फ़ाइल में संयोजित करें (और minify इसे और gzip संपीड़न के साथ सेवा दें)। अनौपचारिक प्रोटोटाइप & script.aculo.us विकी (प्रकटीकरण: मैंने ज्यादातर उस टिप को लिखा है, लेकिन स्मार्ट लोगों से बहुत सारे इनपुट के साथ) पर tip related to this है। यह भी देखें कि क्या आप सीडीएन का लाभ उठा सकते हैं (उदाहरण के लिए, अधिकांश ढांचे अब the Google CDN के माध्यम से उपलब्ध हैं)।
• एक ही साइट पर कई अलग-अलग ढांचे (jQuery, प्रोटोटाइप, म्यूटूल, वाईयूआई इत्यादि) होने के कारण एक कौशल समस्या बन सकती है - साइट पर काम करने वाले किसी भी व्यक्ति को विभिन्न अलग-अलग ढांचे में कौशल की आवश्यकता होगी।
• कुछ ढांचे एक दूसरे के साथ असंगत हैं (उदाहरण के लिए, मुझे संदेह है कि प्रोटोटाइप और म्यूटूल वर्तमान में एक पृष्ठ पर सह-अस्तित्व में हैं; jQuery और प्रोटोटाइप jQuery के "कोई संघर्ष नहीं" मोड के माध्यम से कर सकते हैं)।

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

Answer 5

मैं कई पुस्तकालयों का उपयोग करने के कुछ संभावित कमियां देखते हैं कहेंगे:

1. आरंभिक लोड समय: यदि आप अपने फ़ाइल आकार के बारे में सा सावधान रहने की जरूरत है। उदाहरण के लिए, यदि उस कैलेंडर में आप उपयोग कर रहे हैं तो एक अलग अलग लाइब्रेरी को कार्य करने के लिए आवश्यक है, तो आपको प्रश्न होना चाहिए कि आप केवल jQuery संस्करण का उपयोग क्यों नहीं कर रहे हैं।
2. ग्राहक प्रदर्शन: आप ग्राहक के कंप्यूटर पर प्रसंस्करण का एक बहुत उतारने कर रहे हैं, और पुराने मशीनों/ब्राउज़रों विशेष रूप से गहन पटकथा के साथ संघर्ष होगा। यह आपके लक्षित दर्शकों को जानने का एक प्रश्न है - यदि आप राक्षस पीसी के के साथ तकनीक पर लक्ष्य रखते हैं तो आपको भारी स्क्रिप्टिंग के साथ दूर होने की अधिक संभावना है।
3. संघर्ष: जैसा कि आप कहते हैं, विभिन्न पुस्तकालयों में कार्यों के बीच संघर्ष हो सकता है। इसके आसपास तरीके हैं, लेकिन खुद को पहली जगह क्यों समस्या दें?

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

Answer 6

एक पहलू यह है कि इसमें लोड करने में समय लग सकता है। यदि आपके पास अपनी लिपियों को शामिल या लिंक की गई फाइलें हैं, तो इसमें लोड समय और अधिक HTTP अनुरोध होते हैं।

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

और अंत में, यदि उपयोगकर्ता के पास जावास्क्रिप्ट नहीं है, या यह बंद हो गया है? क्या यह आपकी साइट को पूरी तरह से तोड़ देगा?

Answer 7

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

Answer 8

• ऐसी स्थिति पर विचार करें जिसमें 99% लक्षित उपभोक्ता के पास ब्राउज़र में जावास्क्रिप्ट सक्षम नहीं है और आप अपनी वेबसाइट में भारी जावास्क्रिप्ट कोड लिखते हैं।
• एक बहुत कम प्राथमिकता जो नीचे अपनी वेबसाइट के प्रदर्शन को धीमा कर सकता है के साथ क्लाइंट मशीन पर भी जावास्क्रिप्ट चलाता है।

और एक और एक

• अपने जावास्क्रिप्ट कोड के सभी जावास्क्रिप्ट एक व्याख्या की भाषा

Answer 9

JavaScript फ़ाइलों का एक बहुत का उपयोग करते हुए एक समस्या नहीं होना चाहिए के रूप में सामने आ रहा हो जाता है तो आप हमेशा कर सकते हैं के बाद से HTTP अनुरोधों को कम करने के लिए उन्हें सभी को एक साथ मिलाएं। निश्चित रूप से उस जावास्क्रिप्ट को निष्पादित करने के लिए यह ब्राउज़र का समय लेता है। ऐसे मौके भी हैं कि उन सभी जेएस पुस्तकालयों/प्लगइन्स या डीओएम के बीच संघर्ष होंगे।

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

दूसरी ओर से

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

Answer 10

नेटवर्क भूमि के ऊपर। मैं खुद स्क्रिप्ट के बारे में बात नहीं कर रहा हूं, लेकिन वे क्या कर रहे हैं:

कई प्लग-इन तीसरे पक्ष की वेबसाइटों से सामग्री खींचने के लिए फ्रेम बनाते हैं: बटन जैसे बटन, टिप्पणियां, ट्विटर फ़ीड, Google और विभिन्न प्रकार के विज्ञापन , आदि। और इसके अलावा इन प्लगइन्स भी अपनी स्क्रिप्ट सामग्री लोड और चला सकते हैं।

यहां तक ​​कि अगर आप 8 कोर है, वेबसाइट की सामग्री में कम से कम 30 सेकंड प्लगइन्स उनकी सामग्री लोड के रूप में लिए चारों ओर उतर रहा है (हर पेज दौरे पर!)। यही कारण है कि मैंने जावास्क्रिप्ट को अच्छे से ब्लॉक करने के लिए ब्राउज़र प्लगइन्स इंस्टॉल किए। लेकिन अगर मैं उन्हें सक्षम करता हूं तो भी यह सामान्य है कि वे कम से कम 20-30 डोमेन से स्क्रिप्ट खींचते हैं, और साइट को पूरी तरह कार्यात्मक बनाने के लिए मुझे पृष्ठ पर 4-5 बार सभी स्क्रिप्ट सक्षम करने की आवश्यकता है। कृपया इस तरह की स्थितियों को बनाने से बचें।