इनलाइन जावास्क्रिप्ट अच्छा है या बुरा?

16

मैंने वर्तमान में वर्डप्रेस से वाईआईआई फ्रेमवर्क पर स्विच किया है और एक बाहरी डेवलपर मेरी साइट का पुनर्निर्माण कर रहा है।

एक बात जो मैंने नोटिस की है कि हर बार जब वह AJAX / jQuery को Yii तरीके से आमंत्रित करता है, तो यह वेब पेज में ~~जावास्क्रिप्ट इनलाइन सम्मिलित करता है~~ । हालाँकि ऐसा लगता है कि जावास्क्रिप्ट कोड पाद लेख के नीचे रखा गया है, फिर भी यह इनलाइन है।

सामान्य तौर पर, ऐसा लगता है कि जावास्क्रिप्ट कोड अधिक बार वेबपेज के अंदर डाला जा रहा है। मुझे हमेशा लगता है कि जावास्क्रिप्ट स्क्रिप्ट को जितना संभव हो सके, जावास्क्रिप्ट फ़ाइलों में रखा जाना चाहिए। क्या यह आने वाला "नया" ट्रेंड है? या क्या मुझे अभी भी जावास्क्रिप्ट कोड को अलग-अलग फाइलों में रखने की कोशिश करनी चाहिए?

html javascript

— स्टीवन
स्रोत

वेब पेज में जावास्क्रिप्ट इनलाइन डालने से वास्तव में आपका क्या मतलब है ?

— सलमान एक

3

दूसरों के लिए जो इस प्रश्न को <a onClick="function(){/* do stuff */} ">Click Here</a>

— खोजते

1

@ user1066946 t.co/j1RpJgwoku :-)

— कोस

1

@ user1066946 मुझे वास्तव में कोणीय का उपयोग करना पसंद है, मैंने अभी देखा कि "सिमेंटिक वेब" ने एक सर्कल बनाया है (डोम के बगल में कुछ गोंद कोड रखने के संदर्भ में)

— कोस

1

"हालांकि ऐसा लगता है कि जावास्क्रिप्ट कोड पाद लेख के नीचे रखा गया है, यह अभी भी इनलाइन है।" - ऐसा लगता है जैसे आप "इनलाइन" जावास्क्रिप्ट (जिसे TecBrat संदर्भित करता है) के बजाय एम्बेडेड जावास्क्रिप्ट का उल्लेख कर रहे हैं ।

— MrWhite

13

इनलाइन जावास्क्रिप्ट पेज के लिए डाउनलोड समय बढ़ाता है, जो अच्छा नहीं है। किसी .jsफ़ाइल पर कॉल के साथ , कम से कम ये समानांतर कॉल हो सकते हैं और सामग्री डाउनलोड समय कम हो जाता है। हाँ, ऐसे समय होते हैं जहाँ जावास्क्रिप्ट को सीधे HTML कोड में रखना ठीक होता है, लेकिन आप अक्सर इसे जितना संभव हो उतना ऑफ-लोड करते हैं।

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

— closetnoc
स्रोत

7

डेटा की समान मात्रा को डाउनलोड करने के लिए संभवतः समान होस्ट को डाउनलोड करने के लिए दूसरा कनेक्शन सक्रिय स्ट्रीम के भीतर की तुलना में तेज़ है? आमतौर पर अगर आप कहते हैं, एक होस्ट के लिए एक फाइल पर 50Kbps, दूसरा सत्र शुरू करने से इसमें कटौती हो सकती है ताकि दोनों अब 25Kbps हो। जब तक मेजबान किसी कारण से प्रति कनेक्शन थ्रॉटलिंग नहीं करता है।

— एक्रीक्योर

यद्यपि बाहरी फ़ाइलों के लिए एक कोन है। अगर ठीक से नहीं किया है, तो आप DOMblocking कोड बनाने के लिए, यानी doc.ready ट्रिगर जो प्रभावित करता है, धीमी है माना गति। लेकिन अगर ठीक से किया जाए, तो बाहरी रास्ता तय करना है

— मार्टिज़न

4

.jsफ़ाइलें कैशिंग के लिए बेहतर हैं, यह समझ में नहीं आता है कि एक ही होस्ट के दो कनेक्शन जादुई रूप से आपकी डाउनलोड गति को बड़ा बना देंगे।

बैंडविड्थ को विभाजित करने का विचार, जबकि मैं आपके तर्क को समझता हूं और यह पूरी तरह से गलत नहीं है, थोड़ा भ्रामक है। HTML कम समय ले रहा है और बाद में कोई भी कॉल वास्तव में प्रतीक्षा कर सकता है।

— 15

3

यदि आप समय के लिए झूठ बोल रहे हैं, तो आप बैंडविड्थ को देखना गलत हैं। लोडिंग समय पर प्रोफाइलर को देखें: आम तौर पर कनेक्शन समय वास्तविक डेटा विनिमय समय की तुलना में 10-100x बड़ा होता है। इसका मतलब है कि FRAGMENTATION एक वास्तविक समस्या है, और वास्तव में छोटे js के लिए बाहरी, समर्पित, फ़ाइल का उपयोग करना सबसे खराब हो सकता है। इनलाइन ब्राउज़र पर बेहतर है जो वास्तविक समानांतरकरण नहीं करता है

— लेस्टो

29

मेरी मुद्रा रूपांतरण साइट पर, अधिकांश सत्र एकल पृष्ठ दृश्य हैं। ऐसा इसलिए है क्योंकि उपयोगकर्ता अपनी मुद्रा गणना सीधे लैंडिंग पृष्ठ पर कर सकते हैं (सभी गणना जावास्क्रिप्ट के साथ क्लाइंट साइड को संभाला जाता है।)

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

मेरी साइट विशिष्ट नहीं है। अधिकांश साइटों में प्रति सत्र कई पृष्ठ होते हैं और बड़ी छवियां जो मेरी तकनीक को कम लागू करती हैं। इस प्रश्न का कोई एक सही समाधान नहीं है; यह साइट पर निर्भर करता है। आपको अपने उपयोगकर्ताओं के विशिष्ट व्यवहार के आधार पर इसे स्वयं मापने की आवश्यकता है ।

— स्टीफन ओस्टरमिलर
स्रोत

12

यह जरूरी नहीं है कि आपकी HTML फ़ाइल में JavaScript हो लेकिन आपको इस पर एक निर्णय लेना चाहिए।

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

हालाँकि, यदि आपके पास जावास्क्रिप्ट की एक छोटी राशि है, तो इसे एक बाहरी फ़ाइल में डालने की बचत इस तथ्य से नकारात्मक हो सकती है कि आपको इसे पुनः प्राप्त करने के लिए अतिरिक्त HTTP अनुरोध करने की आवश्यकता है। इस उदाहरण में जावास्क्रिप्ट को अपने पेज पर रखना अधिक कुशल होगा।

फिर, यदि जावास्क्रिप्ट के इसी छोटे स्निपेट को कई पृष्ठों पर उपयोग किया जाता है तो कैशिंग का लाभ उठाने के लिए इसे बाहरी फाइल में रखना फायदेमंद होगा।

अंततः आपको अतिरिक्त HTTP अनुरोध करने के ओवरहेड के खिलाफ जावास्क्रिप्ट का आकार तौलना चाहिए। अधिकांश भाग के लिए, एक 'औसत' साइट के लिए, यह शायद एक बाहरी फ़ाइल में डालने से बहुत अंतर नहीं होगा।

— foamcow
स्रोत

4

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

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

संपादित करें : वास्तव में, मैं सबसे महत्वपूर्ण तर्क के बारे में भूल गया। Yii (साथ ही अधिकांश अन्य पेशेवर PHP चौखटे) MVC डिजाइन पैटर्न (वास्तव में: वास्तुशिल्प पैटर्न) पर निर्मित है । और उसी पैटर्न का उपयोग सामने वाले में किया जा सकता है: HTML कोड मॉडल (डेटा) है, CSS दृश्य (डेकोरेटर) है और जावास्क्रिप्ट नियंत्रक है। उन सभी ने अलग-अलग फाइलों में डाल दिया , .jsऔर .cssफाइलें - सर्वश्रेष्ठ परिदृश्य में खनन, अस्पष्ट और gzipped।

जब आप अपने Yii एप्लिकेशन का निर्माण करते हैं, तो आप MVC पैटर्न को तोड़ सकते हैं और एक ही फाइल में सब कुछ रख सकते हैं। सवाल है - क्या यह ऐसा करने के लायक है, क्या लाभ हैं (कोई नहीं?) और यह आपको कहां ले जाएगा? आप एक ही तर्क का उपयोग कर सकते हैं, जब पूछ रहे हैं, क्या जेएस कोड इनलाइन रखना है या नहीं?

— trejder
स्रोत

ठीक है। डेवलपर को सब कुछ के लिए 3 पार्टी विजेट का उपयोग करने लगता है; स्वतः पूर्ण, ajax छवि अपलोड आदि। यह सब इनलाइन js जोड़ता है।

— स्टीवन

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

— trejder

Yii में तृतीय पक्ष एक्सटेंशन और विजेट का उपयोग करना एक महान विचार है (आपको फिर से पहिया का आविष्कार नहीं करना है)। लेकिन, Yii एप्लिकेशन या एक्सटेंशन में इनलाइन जेएस कोड का उपयोग करना वास्तव में एक बुरा रवैया है। इसलिए या तो अपने डेवलपर को बेहतर कोड लिखने के लिए मजबूर करें / बेहतर एक्सटेंशन और विजेट्स का उपयोग करें या ... बेहतर डेवलपर प्राप्त करें! :]

— trejder

ठीक है, प्रतिक्रिया के लिए धन्यवाद। Stackoverflow के अलावा, मुझे एक अच्छा Yii समुदाय कहाँ मिल सकता है?

— स्टीवन

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

— trejder

3

यह वास्तव में आपके द्वारा विकसित किए जा रहे वेबपेज के उद्देश्य पर निर्भर करता है:

मैं इनलाइन जावास्क्रिप्ट की एक छोटी राशि का उपयोग करता हूं, जबकि मैं बाहरी जावास्क्रिप्ट फ़ाइलों के लिए जाना पसंद करता हूं यदि यह बड़ा है।

किसी भी तरह से, जब पृष्ठ जावास्क्रिप्ट लोड करता है, तो इसे पहले निष्पादित करना होगा। सबसे अच्छा अभ्यास बाहरी जावास्क्रिप्ट का उपयोग करना है ताकि यह आपके पृष्ठ की सामग्री को लंबा न करे। यह डिबगिंग को आसान भी बनाता है।

— अभिजीत भट्टू
स्रोत

2

उत्तर वास्तव में इस बात पर निर्भर करता है कि क्या किया जा रहा है।

यदि आप वेबसाइट पर उपयोग होने वाले जावास्क्रिप्ट को इनलाइन करते हैं (उदाहरण के लिए एक विजेट जो वेबसाइट के सभी पृष्ठों पर हेडर के अंदर दिखाता है) तो इसे "आम" जावास्क्रिप्ट फ़ाइल में स्थानांतरित करना उचित होगा।

वास्तव में, मैं जावास्क्रिप्ट को एक सामान्य जावास्क्रिप्ट फ़ाइल में ले जाऊंगा, भले ही यह एक ही पृष्ठ पर उपयोग किया गया हो। मैं जावास्क्रिप्ट फ़ाइलों के लिए मजबूत कैशिंग और संपीड़न हेडर भेजने के लिए सर्वर को कॉन्फ़िगर करेगा; जो पेज के आकार को कम करता है, लेकिन जावास्क्रिप्ट फ़ाइल के आकार को बहुत अधिक नहीं बढ़ाता है।

दूसरी ओर, यदि जावास्क्रिप्ट केवल विन्यास विकल्प / आरंभीकरण का एक गुच्छा है जैसे:

$(function () {
    myplugin({
        images: ["img1", "img2", "img3"]
    });
});

जहां किसी कारण से बाहरी जावास्क्रिप्ट फ़ाइल में कोड को स्थानांतरित करना संभव नहीं था (उदाहरण के लिए जब छवि पैरामीटर डेटाबेस से आ रहे हैं) मैं इसे इनलाइन में रखूंगा। ऐसा कहने के बाद, मैं थर्ड पार्टी प्लगइन्स चुनूँगा जो "विनीत" हैं (या उन्हें ऐसे रूपांतरित करें)।

— सलमान ए
स्रोत

2

ये जवाब निशान को याद करते हैं। इनलाइन कैचिंग पर एक नजर ।

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

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

एक WYSIWYG संपादक का उपयोग करके कुछ सीएमएस सॉफ़्टवेयर में एक पृष्ठ लिखने वाले एंड-यूज़र के मामले पर विचार करें। जब वे आपके स्रोत तक नहीं पहुँचते हैं, तो यह उपयोगकर्ता पृष्ठ पर नई कार्यक्षमता कैसे जोड़ सकता है। सर्वर पर .js फ़ाइलें? वे HTML टैब पर स्विच करते हैं और जावास्क्रिप्ट का उपयोग करते हैं।

सभी इनलाइन जावास्क्रिप्ट खराब नहीं है; कभी-कभी onclick भी ठीक है। एक सामान्य सिफारिश के रूप में, जावास्क्रिप्ट लिखने से बचें और आप अच्छी आदतों के निर्माण के लिए अपने रास्ते पर होंगे।

संदर्भ:

— नाशपाती की मदिरा
स्रोत

0

आम तौर पर इनलाइन जेएस कोड खराब है, जैसा कि दूसरों ने मुझसे पहले कहा था।

लेकिन मैं एक ऐसे केस के बारे में सोचता हूं जहां इनलाइन JS बेहतर है ।

एक सीएमएस के बारे में सोचें जो जेएस संचालित गैलरी को सम्मिलित करता है। गैलरी शायद jQuery में किया। यह एक आईडी विशेषता द्वारा पहचाना जाता है, जो न केवल पृष्ठ पर अद्वितीय है, बल्कि पूरे साइट पर अद्वितीय है। इस स्थिति में - मुझे लगता है कि इनलाइन JS बेहतर होगा, क्योंकि JS कोड का उपयोग केवल एक पेज पर किया जाता है और आपके पास कोई HTTP ओवरहेड नहीं है

— yunzen
स्रोत