हमने Marionette.js पर स्विच क्यों किया

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

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

अब, यदि आप इसके बारे में सोचते हैं, तो उन दिनों यह विकसित करना आसान था, इस तथ्य के कारण कि सभी उपयोगकर्ता हार्डवेयर द्वारा समान रूप से सीमित थे।

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

वेब इंटरफ़ेस विकास

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

यूआई वास्तुकला एक बहुत ही कठिन डिजाइन समस्या है, और भले ही बड़ी कंपनियों ने इसके समाधान के लिए वर्षों में लाखों डॉलर का निवेश किया हो, फिर भी हमें ऐसा करने के लिए "वन राइट वे" नहीं है। बहुत सारे जावास्क्रिप्ट "एमवीसी" ढांचे (यह सर्वर एमवीसी ढांचे के रूप में लगभग एक शब्द के रूप में बुरा है) पिछले वर्षों में दिखाई दिए हैं और वेब पर पिछले 50 वर्षों के यूआई वास्तुकला के विचारों को लागू करने के तरीके में मौलिक रूप से भिन्न हैं।

एक ढांचा चुनना

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

हमारी स्थिति

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

Ember.js

Ember.js के बारे में येहुदा काट्ज़ (wycats) द्वारा प्रलेखन और बात के आधार पर, यह मूल रूप से क्लाइंट की तरफ से करने की कोशिश है।
एम्बर अब उपलब्ध सबसे महत्वाकांक्षी ढांचा है और इसकी ताकत स्पष्ट है। यह आपको कुछ मामलों में एक विकल्प से वंचित करता है, और यह काफी सुविधाजनक हो सकता है। विशेष रूप से, मैं रूटिंग (राज्य प्रबंधक / राज्य प्रबंधक) के लिए उनके दृष्टिकोण को पसंद करता हूं, मुझे लगता है कि यह अन्य कार्यान्वयनों की तुलना में बहुत बेहतर है।

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

मेरे लिए आखिरी तिनका था जो आपकी वास्तुकला पर एम्बर का नियंत्रण था। हमारे पास अपनी पसंद बनाने के लिए पर्याप्त कौशल है, इसलिए मेरा मानना ​​है कि हम पर इतने प्रतिबंधों के साथ काम करना एक बुरा विकल्प है।

Angular.js

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

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

onclick="foo();" 

और

 ng-click="foo();" 

Xcode जैसे वातावरण में, मुझे देखने की इस शैली में कोई समस्या नहीं है, क्योंकि "दृश्य" मेरे लिए कोड नहीं है, बल्कि एक डिज़ाइन सतह है। लेकिन जब से हम वेब को अलग तरह से बना रहे हैं, मैं इसे एक खराब विकास दिशा मानता हूं।

मैं इसे एक कमजोरी भी नहीं मानूंगा, बल्कि दृष्टिकोणों में अंतर होगा। मुझे लगता है कि कोणीय की कमजोरी यह है: एक बोझिल एपीआई, यह तथ्य कि वेब मानक कोणीय से अलग दिशा में जाते हैं, और यह कि सार काफी नाजुक हैं। जब यह काम करता है, और कहाँ / कैसे वापस आना है, इसकी गहरी समझ की आवश्यकता होने पर, विनियमित कोणीय दुनिया के बाहर होना काफी आसान है।

मेरे लिए निर्णायक माइनस मेरा खुद का निर्देशन करना कितना मुश्किल था, जिसे मैं पूरे ढांचे की सबसे मूल्यवान विशेषता मानता हूं। मेरे करियर के दौरान, एकमात्र प्लेटफ़ॉर्म जिसने त्रासदी के स्तर पर संपर्क किया है, जब वह विस्तार करने की कोशिश कर रहा है। ASP.net WebForms में सर्वर नियंत्रण है। यह एक हल करने योग्य समस्या है, और मुझे लगता है कि अगर हम अब उस बिंदु पर थे जहां पर कोणीय दूसरे या तीसरे संस्करण में पहुंच गया, तो यह मेरी पसंद होगी।

Knockout.js

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

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

नॉकआउट की कमजोरी यह है कि यदि आपको क्लाइंट तर्क की एक महत्वपूर्ण राशि की आवश्यकता है, तो यह इसके समाधान का हिस्सा बन जाएगा।

Backbone.js

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

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

बैकबोन की कमजोरी यह है कि यह वास्तव में अपने आप में बहुत कुछ नहीं करता है, और यदि आप यह नहीं जानते कि आप क्या करते हैं, तो आप खुद ही एक बुरी सेवा करते हैं। यह "जावास्क्रिप्ट-नेस" भी एक बाधा हो सकता है, क्योंकि कई "वेब डेवलपर्स" को वेब तकनीक का ज्ञान है, और यदि आप उनमें से एक हैं, तो आप आसानी से बैकबोन के साथ खो सकते हैं।

Backbone.Marionette

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

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

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

UI जटिल है और कोई सिल्वर बुलेट नहीं है

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

मूल लेखक मैट ब्रिग्स।