जावास्क्रिप्ट के माध्यम से क्लाइंट-साइड यूआई प्रतिपादन एक अच्छा विचार है?

Question

वेब विकास के लिए "क्लासिक" दृष्टिकोण कुछ समय के लिए एक पतला ग्राहक और मोटा सर्वर रहा है: सर्वर HTML उत्पन्न करता है और ब्राउज़र को केवल प्रस्तुत करने के लिए बाहर थूकता है। लेकिन मौजूदा ब्राउज़रों के साथ (और अच्छी पुस्तकालयों और ढांचे की उपलब्धता के कारण) जावास्क्रिप्ट अब काम करता है। वेब देव अब बहुत अधिक मान सकते हैं कि उनका जावास्क्रिप्ट कोड काम करेगा और परेशान होना बंद कर देगा।

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

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

Answer 1

मैं इस तरह के ऐप के निर्माण के पूंछ के अंत में हूं। यह ज़ेंड फ्रेमवर्क जेएसओएन-आरपीसी वेब सेवाओं के शीर्ष पर एक एक्स्टजेएस जीयूआई है, जो iGoogle- जैसे गैजेट पोर्टल को कार्यान्वित करता है।

लाभ:

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

नुकसान:

• आप रहते हैं और जावास्क्रिप्ट, जो बेकार है अगर आप इसे नफरत साँस लेने के लिए किया है। हमारे मामले में इसका मतलब डेवलपर टीम का एक बड़ा प्रशिक्षण था क्योंकि हम PHP-heavy थे।
• सब कुछ एक लंबे समय तक रहने वाले डोम में रहता है, इसलिए आपको मेमोरी प्रबंधन के साथ अपने पैर की उंगलियों पर रहना होगा और यह सुनिश्चित करना होगा कि सामान सही ढंग से साफ हो जाए। इसके अलावा, बहुत अधिक यूआई लोड करना आईई को जाता है "ओउ, ओउ, आप मेरे दिमाग को चोट पहुंचा रहे हैं"।
• यूआई उत्पन्न करने के बीच में एक विकल्प लाने के लिए कोई त्वरित क्वेरी नहीं चल रही है। क्लाइंट पर रहने की प्रोग्राम डिज़ाइन बाधाएं पहले चुनौतीपूर्ण हैं। आप इसका इस्तेमाल करते हैं, लेकिन यह एक बाधा है।
• उस जावास्क्रिप्ट का मतलब है कि आपके उपयोगकर्ताओं को तेज़ कनेक्शन और आधुनिक ब्राउज़र की आवश्यकता है।

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

अद्यतन (सितम्बर 2013):

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

क्योंकि @rwoo पूछा, कुछ चुनौतियों हम अभी भी है:

• ऑन-डिमांड js कोड की लोडिंग पता चला है अनुमान की तुलना में एक जटिल काम समस्या हो। इस भाग को अपने वास्तुकला में प्राप्त करना महत्वपूर्ण है।
• हमें सबवर्जन में प्री-प्रतिबद्ध हुक में स्वत: जेशिंट प्रमाणीकरण को एकीकृत करना पड़ा क्योंकि जेएस सिंटैक्स त्रुटियों के प्रति सहिष्णु है और जब तक उत्पाद ग्राहक तक नहीं पहुंच जाता तब तक आप अक्सर यह ध्यान नहीं देते हैं।
• क्योंकि डेटाबेस वेब सेवा अनुरोध के दूसरे छोर पर है, आपको सावधानीपूर्वक अपनी वेब सेवा एपीआई डिज़ाइन करना होगा या आप बहुत सारे एक्सएचआर अनुरोधों की प्रतीक्षा के कारण लुभावनी प्रदर्शन के साथ समाप्त हो जाएंगे। यह हल करने योग्य है, लेकिन चुनौतीपूर्ण है, और यह समय के साथ आसान नहीं होता है।
• सही ढांचे के साथ क्रॉस-ब्राउज़र मुद्दों को कम किया जाता है, वे पूरी तरह से दूर नहीं जाते हैं जिसका अर्थ है कि आपको सभी ब्राउज़रों, सभी संस्करणों में परीक्षण करने की आवश्यकता है। यह इतना काम है कि आपको सेलेनियम जैसे कुछ का उपयोग करके इसे स्वचालित करना होगा, और जैसा कि यह पता चला है कि सर्वर-साइड प्रस्तुत यूआई की तुलना में क्लाइंट-साइड प्रस्तुत यूआई के साथ करना मुश्किल है।

Answer 2

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

लेकिन जीडब्ल्यूटी जेनरेट जावास्क्रिप्ट का उपयोग करता है, हाथ से लिखित नहीं। हाथ से ऐसा करना दर्दनाक है।

Answer 3

ExtJS, YUI, dojo ... चौखटे कि मूल रूप से एक की तरह कार्यान्वयन क्षुधा में एक हाथ की पेशकश आप

का वर्णन कर रहे हैं

हम (मेरे कार्यस्थल पर) कई कई बड़े & छोटे पैमाने पर क्षुधा के लिए सफलतापूर्वक इस्तेमाल किया दृष्टिकोण ... सामान्य आधारित में ExtJS पर हमारे एप्लिकेशन के सबसे + jQuery, डोजो पर कुछ मामलों (Zend Framework (यदि आप पीएचपी दुनिया के बारे में बिल्कुल भी परवाह) डोजो तत्वों के साथ काम एकीकरण प्रदान)

यह दुरुपयोग नहीं किया गया है और प्रयोग किया जाता में बस इसका उपयोग करने या शीतलन कारक को टक्कर देने के लिए - यह एक शानदार उपकरण है।

उचित डिजाइन के साथ यह न तो भारी है और न ही एक दृष्टिकोण के रूप में धीमा है।

Answer 4

मैंने इसे हाथ से किया है। यह एक दर्द था, लेकिन कुछ उल्टा है। यह केवल समृद्ध इंटरनेट ऐप्स के लिए उपयुक्त है जहां फॉलबैक कम समझ में आता है। मुझे लगता है कि हम जावास्क्रिप्ट की आवश्यकता वाले अधिक से अधिक ऐप्स देखेंगे, खासकर Cappuccino Atlas जैसे ढांचे के बाद।

Answer 5

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

Answer 6

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

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

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

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

मेरा 2 सेंट।

Answer 7

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

अधिकांश भाग के लिए आधुनिक टूलकिट्स ने अधिकांश ब्राउज़र क्विर्क को लगभग समाप्त कर दिया है। यद्यपि आप निश्चित रूप से कभी-कभी क्रॉस-ब्राउज़र प्रतिपादन समस्याओं में भाग ले सकते हैं, लेकिन यह लगभग किसी समस्या का बड़ा नहीं है क्योंकि यह होगा कि आपने स्वयं सभी जेएस लिखने की कोशिश की हो। आईई 6 में गति भी स्वीकार्य होनी चाहिए, हालांकि आप सामान्य रूप से सफारी, क्रोम या फ़ायरफ़ॉक्स के हाल के संस्करण में बेहतर प्रदर्शन करेंगे। (मुझे टिप्पणी करने के लिए आईई 7 या 8 के बारे में पर्याप्त जानकारी नहीं है)।

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

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

Answer 8

व्यावसायिक ऐप्स की आंतरिक रूप से खपत वाली लाइन के लिए जहां आप डेस्कटॉप को नियंत्रित कर सकते हैं, जावास्क्रिप्ट समझ में आता है।

बाहरी/सार्वजनिक सामना करने वाले ऐप्स के लिए जहां आपको पता नहीं है कि आपके उपभोक्ता किस ब्राउज़र का उपयोग कर रहे हैं, इसे मृत सरल रखें और जितना संभव हो उतना उपयोग करें।

जब आप कहते हैं कि जावास्क्रिप्ट अभी ढांचे के कारण काम करता है, तो यह बिल्कुल सही नहीं है। आईई 6 अभी भी व्यापक रूप से उपयोग में है, जैसा कि पुरानी सफारी है। यहां तक ​​कि कुछ हद तक एफएफ 2.x, और 1.x, उपभोक्ता बाजार का सभ्य हिस्सा है।

इसके साथ-साथ, हर किसी के पास हाई स्पीड इंटरनेट नहीं है, जो इन ढांचे के लिए बहुत अधिक आवश्यकता है। इसके अलावा, हालांकि अधिकांश पुस्तकालय आईई 7 के साथ काम करते हैं, यह ज्यादातर परिचालनों के लिए एक कुत्ता है।

लाइब्रेरी आकार के विषय पर, हमारे पास कई .NET नियंत्रण हैं जो क्लाइंट को 1 एमबी जावास्क्रिप्ट को इंजेक्ट करना चाहते हैं। दादी को भेजने की कोशिश कर रहा है।

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

Answer 9

YUI थियेटर एक वीडियो मुझे लगता है कि आपके सवाल का बेहद प्रासंगिक हो गया है - मैं दृढ़ता से देख रहा है यह

High-performance JavaScript: Why Everything You've Been Taught Is Wrong

शीर्षक थोड़ा भ्रामक है की सलाह देते हैं, लेकिन वह वास्तव में बहुत मुद्दों के बारे में बात करती है आप सामना कर रहा हूँ

Answer 10

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

बहुत से लोग पृष्ठ को लोड करने का दृष्टिकोण लेते हैं, और फिर जावास्क्रिप्ट/AJAX लोड करने का काम करते हैं। इसके परिणामस्वरूप क्लाइंट लोड होने के लिए प्रतीक्षा कर रहा है, और उसके बाद क्लाइंट डेटा लोड करने की प्रतीक्षा कर रहा है।

सर्वर को प्रारंभिक डेटा लोड करने और सभी यूआई तत्वों को पॉप्युलेट करने के लिए बस इतना बेहतर है।