क्यों नहीं पूरी वेबसाइट AJAX'ify?

Question

क्या कोई ठोस तर्क है कि क्यों साइटों को अजाक्स कार्यक्षमता के साथ विकसित नहीं किया जाना चाहिए जो प्रत्येक भाग के प्रमुख हिस्सों को लोड करता है (यह मानते हुए कि हेडर, नेविगेशन आदि जैसे तत्व हैं जो समान रहते हैं)?

निश्चित रूप से यह कम संसाधन-गहन होगा क्योंकि सर्वर को प्रत्येक पृष्ठ पर दिखाई देने वाली सामग्री की सेवा नहीं करनी होगी, जिससे मेजबान और अंतिम-उपयोगकर्ता दोनों को लाभ होगा।

ध्यान में रखते हुए प्रश्न का उत्तर दें:

• साइट जावास्क्रिप्ट व्यवहार हर उदाहरण में शान से नीचा दिखाती है

• मेरे प्रश्न के लिए मैं उन नई साइटों के बारे में बात कर रहा हूँ जहाँ इस व्यवहार को बंद करने के बजाय कार्यान्वित किया जा सकता है, इसलिए यह तकनीकी रूप से किसी भी पैसे का खर्च नहीं करता है - हम इसे लागू करने के लिए तैयार उत्पाद पर नहीं लौट रहे हैं।

Comments

gmail एक "वेबसाइट" का एक उदाहरण है जो लगभग पूरी तरह से AJAX है। पूरी तरह से AJAX की वेबसाइट पारंपरिक वेबसाइटों के बजाय वेब ऐप्स के लिए बेहतर काम करती है।

— रेयान

it doesn't technically cost any moneyसिवाय इसके। एक AJAXified है जो नियमित ब्राउज़िंग अनुभव के लिए तुलनीय है, आपको ब्राउज़र निर्मित सुविधाओं को फिर से लागू करना होगा जो स्वचालित रूप से नियमित साइटों के साथ उपलब्ध हैं, जैसे कि बैक बटन, ब्राउज़र इतिहास, कैशिंग, आदि। बहुत कम से कम, आप ' हाइपरलिंक्स फंक्शंस को फिर से लागू करने के लिए क्लिक इवेंट हैंडलर (सहित: विज़िट किए गए और सक्रिय मार्कर) शामिल करने होंगे।

— रेयान

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

— Evik James

Answer 1

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

संपादित करें

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

Comments

बहुत सच ... दुआ पल। जबरदस्त हंसी। किसी भी विचार के रूप में क्यों कई प्रमुख वेबसाइटों सहज सामग्री वितरित करने के माध्यम से उपयोगकर्ता के अनुभव में वृद्धि नहीं करते हैं?

— बेनामी

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

— जॉन कोंडे

+1 कि "वास्तव में बुरा विचार" लिंक और पूरी तरह से AJAX'd वेबसाइटों के चरम खतरों के बारे में इसकी सावधानीपूर्वक कहानी।

— जोशाहेदुंड

Answer 2

पहली चीजें पहले

गुण

• AJAX आपको एक सामान्य "आधार" पृष्ठ का उपयोग करने की अनुमति दे सकता है और केवल सामग्री क्षेत्रों को लोड कर सकता है, जो उपयोगकर्ताओं के लिए लोड समय में कटौती कर सकता है, क्योंकि पृष्ठ का एक बड़ा हिस्सा पहले से ही लोड है।
• कुछ नेत्र कैंडी को अंदर और बाहर सामग्री क्षेत्र को लुप्त करने की अनुमति दे सकते हैं।

विपक्ष

• पेज डाउनलोड होने पर अच्छा नहीं खेलता है।
• विकलांगता उपकरणों के साथ खिलवाड़ कर सकते हैं।
• जब तक कि एक गैर-जावास्क्रिप्ट संस्करण के रूप में अच्छी तरह से नियोजित नहीं किया जाता है तब तक जावास्क्रिप्ट बंद किए गए दर्शक सामग्री का उपयोग नहीं कर पाएंगे।
• बहुत अधिक काम (क्या यह वास्तव में कहा जाना चाहिए?)।

अब आपके प्रश्न के लिए

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

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

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

Answer 3

की जाँच करें http://gawker.com/ - इस साइट लगभग पूरी तरह से इस तथ्य के बाद लोड होता है। वे http://mydomain.com/#!some_sectionयह निर्धारित करने के लिए "हैशबैंग्स" ( ) का उपयोग करते हैं कि किस सामग्री पृष्ठ को लोड किया जाना चाहिए, मुख्य नेविगेशन स्थिर रहता है।

इस्तेमाल किए गए अवधारणा गॉकर पर एक संक्षिप्त ट्यूटोरियल के लिए http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/ देखें ।

पेशेवरों और विपक्ष हैं, आपको खोज इंजन ( http://code.google.com/web/ajaxcrawling/docs/getting-started.html देखें ) पर विचार करना होगा, जावास्क्रिप्ट अक्षम लोगों, और बहुत परीक्षण करना।

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

Answer 4

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

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

Comments

क्या आप सुझाव दे रहे हैं कि अजाक्स के बिना फेसबुक या जीमेल संभव होगा? वे शुरुआती वेब मेल और माइस्पेस की तरह होंगे।

— Evik James

अजाक्स विफलताओं के लिए, एक अच्छा प्रोग्रामर ऐसे आयोजनों के लिए खोज लिख सकता है। यह अनुरोध को पुनः प्राप्त करने या कुछ गलत होने पर बस प्रदर्शित करने के लिए एक संकेत हो सकता है।

— जोमर सेविजो

Answer 5

व्यवहार में यह एक 'पूरी तरह से AJAX' वेबसाइट का निर्माण करने के लिए बहुत काम है, विशेष रूप से प्रमुख वेबसाइटों के लिए जो बहुत जटिल हैं। यह प्रयास करने वाली कुछ वेबसाइटें Google और Facebook हैं, लेकिन यहां तक ​​कि वे इसे पूरी तरह से नहीं करते हैं।

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

Comments

मुझे लगता है कि "आगे और पीछे" की अवधारणाओं को पदावनत किया जा रहा है। लोग इस पर पकड़ रहे हैं कि वेब एक नदी की तरह बहता है और एक मूर्त पुस्तक की तरह नहीं है।

— Evik James

Answer 6

हाँ, यह होना चाहिए, लेकिन यह दूसरी तरह से होना चाहिए।

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

बेशक आपको पहले यह पता लगाने की आवश्यकता है कि क्या जावास्क्रिप्ट सक्षम है (कुकी द्वारा) और केवल इस विधि का उपयोग करें यदि यह सक्षम है।

तो आपको सामान्य पूर्ण HTTP मार्ग और फिर एक वेबसोकेट मार्ग की आवश्यकता है। यह कोड दोहराव की आवश्यकता है जब तक आप एक उपकरण का उपयोग न करें

अधिकांश लोग "सोचते हैं" कि यह सिर्फ अतिरिक्त प्रयास के लायक नहीं है। और कभी-कभी ऐसा नहीं है।

एक तरफ के रूप में बहुत से लोग पृष्ठों को गलत आंकते हैं। वे वास्तव में तय करते हैं कि आपको एक गैर-जावास्क्रिप्ट संस्करण की आवश्यकता नहीं है और आपको इन सभी अजीब हैश बैंग यूआरएल और टूटे हुए आगे / पीछे बटन की आवश्यकता है। ठीक से ajax करना HTML5 इतिहास (IE9 यह नहीं है) की आवश्यकता है। आपकी वेबसाइट के संस्करणों को पूरा करने के लिए भी डेवलपर की आवश्यकता होती है।

Answer 7

चूंकि आपने कहा था कि यह जावास्क्रिप्ट के साथ आगंतुकों के लिए इनायत से नीचा दिखाना होगा, मैं केवल दो वास्तविक मुद्दों (और एक संभव मुद्दा) को देख सकता हूं जो सामने आ सकते हैं।

पहुँच के लिए बुरा

स्क्रीन पाठकों और अन्य सहायक तकनीकों को अक्सर गतिशील DOM परिवर्तनों द्वारा फेंक दिया जाता है। वे पृष्ठ को रैखिक रूप से संसाधित करते हैं और पढ़ते हैं, और लोड होने के बाद पृष्ठ की सामग्री को बदलना सही तरीके से नियंत्रित नहीं किया जा सकता है।

इसके आसपास पाने के लिए तकनीकें हो सकती हैं, लेकिन मैंने इस पर बहुत गौर नहीं किया है।

बढ़ी हुई जटिलता

इस तरह की साइट को बनाए रखना मुश्किल हो सकता है। एक उदाहरण के लिए: यदि आपने एक नया लेआउट बनाया है और उस सामग्री क्षेत्र की आईडी बदल दी है जिसे आप अपने AJAX लिंक के साथ बदल रहे थे, तो यह आपकी नेविगेशन योजना को बहुत खराब तरीके से तोड़ सकता है।

इस तरह का AJAX व्यवहार आपके द्वारा किए जा रहे किसी भी ट्रैफ़िक विश्लेषण को जटिल बना देगा; Google Analytics इन AJAX लोड को मैन्युअल कॉल के बिना ठीक से पंजीकृत नहीं करेगा pageTracker._trackPageview('this_page');।

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

संभव: आरंभिक भेंट पर धीमा पृष्ठ लोड

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

बाद में क्लिक किया गया प्रत्येक लिंक तेज़ होगा, लेकिन उपयोगकर्ता द्वारा विज़िट किया गया पहला पृष्ठ प्राप्त करना वास्तव में एक स्थिर संस्करण से अधिक समय लेगा।

इसका कारण मैंने इसे एक संभावित मुद्दे के रूप में लेबल किया है कि आप हमेशा पहले पृष्ठ को सांख्यिकीय रूप से भेज सकते हैं (क्योंकि आपके पास पहले से ही एक स्थिर संस्करण के रूप में स्थैतिक संस्करण होगा) और फिर बाद के लिंक के लिए AJAX का उपयोग करें।

---

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

Answer 8

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

उदाहरण के लिए: मान लें कि आपके पास 200 लोग हैं जो एक पृष्ठ को दूसरे तक पहुंचाने की कोशिश कर रहे हैं। आपके अजाक्स कॉल के लिए लगभग 7 डेटाबेस प्रश्न हैं; वह 1400 डेटाबेस एक सेकंड कॉल करता है, जो एक वेबसाइट को काट सकता है।

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

यह वेबसाइट निर्माण के लिए एक SOA दृष्टिकोण है।

Comments

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

— DisgruntledGoat

@DisgruntledGoat मैंने कभी नहीं कहा कि आप AJAX का उपयोग नहीं कर सकते हैं, और यह सवाल AJAX का उपयोग करने के बारे में नहीं है या नहीं; इसके बारे में आप एक पृष्ठ पर सब कुछ के लिए AJAX का उपयोग क्यों नहीं करना चाहते हैं। मैंने अपने उत्तर को यह दर्शाने के लिए अद्यतन किया है कि मैं मूल सामग्री का क्या मतलब है।

— पॉल