जेएस चौखटे का अवलोकन। जावास्क्रिप्ट एमवीसी के जंगल के माध्यम से यात्रा करें। भाग 1

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

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

■ एमवीसी या बेहतर, एमवी * क्या है?

ये आधुनिक लाइब्रेरी डेवलपर्स को MVC (मॉडल-व्यू-कंट्रोलर) के रूप में ज्ञात डिज़ाइन पैटर्न की विविधताओं का उपयोग करके कोड को व्यवस्थित करने का एक सरल तरीका देती हैं। MVC अनुप्रयोग में कार्यों को 3 भागों में विभाजित करता है:

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

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

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

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

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

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

■ हमें JS MV फ्रेमवर्क की आवश्यकता कब है?

जब एक-पेज का आवेदन तैयार करना या एक जटिल उपयोगकर्ता इंटरफ़ेस बनाना, या बस HTTP अनुरोधों की संख्या को कम करना है, तो आप शायद बैकबोन या एम्बर जैसे एमवी * ढांचे की संरचना के कई हिस्सों का आविष्कार करेंगे।

काम की शुरुआत में, स्पैगेटी कोड से बचने के लिए किसी तरह के साइकिल तंत्र की पेशकश करने वाले एप्लिकेशन ढांचे को लिखना बहुत मुश्किल नहीं है। लेकिन यह कहना कि यह "किसी तरह का" लिखने से ज्यादा मुश्किल नहीं है, बैकबोन बहुत गलत होगा।

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

■ हमें एमवी * की आवश्यकता कहां होगी, और कहां नहीं?

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

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

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

■ विकल्प जारी करें: बहुत सारे विकल्प?

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

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

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

■ TodoMVC: सीखने और तुलना करने के लिए एक सामान्य ऐप

(अप्रैल में रूसी में एक नोट था: habrahabr.ru/post/142301 )

हम पिछले कुछ वर्षों में ऐसे एमवी * फ्रेमवर्क की संख्या में भारी उछाल देखते हैं।

Backbone.js , Ember.js , AngularJS , Spine , CanJS ... हर हफ्ते नए और काम के समाधानों की सूची बढ़ रही है; डेवलपर्स विकल्प के समुद्र में जल्दी से खो सकते हैं। उनके पास चुनने के लिए बहुत कुछ है। जटिल अनुप्रयोगों पर काम करने वाले दिमागों से कई मजबूत प्रतिस्पर्धात्मक समाधान हैं जिन्होंने पुस्तकालयों को प्रेरित किया है (जैसे कि येहुदा काट्ज़ और जेरेमी अशोकन )। प्रश्न: क्या उपयोग करें और कैसे चुनें?

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


इस सप्ताह (जुलाई 14, 2012) हम टोडोएमवीसी का एक नया संस्करण जारी कर रहे हैं, जिसका विवरण आवेदन अनुभाग में नीचे दिया गया है।

निकट भविष्य में, हम इस या उस ढांचे का उपयोग करने के लिए किस प्रकार के अनुप्रयोगों पर विचार करना चाहिए, इस पर मतभेद और सिफारिशों पर नोट्स प्रदान करके कार्य को और विकसित करना चाहते हैं।

■ एक फ्रेमवर्क चुनने के लिए हमारे प्रस्तावित मानदंड

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

ढांचा वास्तव में क्या सक्षम है?
फ्रेमवर्क के स्रोत कोड और सुविधाओं की आधिकारिक सूची को पढ़ने के लिए समय निकालें कि वे आपकी आवश्यकताओं को कैसे पूरा करते हैं। ऐसी परियोजनाएं होंगी जिन्हें स्रोत कोड में परिवर्तन या परिवर्धन की आवश्यकता हो सकती है, और यदि आप इसे अपने लिए संभव मानते हैं, तो कोड ने परीक्षा पास कर ली है।

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

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

क्या ढांचा लचीला या प्रबंधन के लिए कठिन है?
पता है कि विभिन्न "चरित्र" के पुस्तकालय हैं। कसकर प्रबंधित ढांचे आप निश्चित रूपरेखा के भीतर कार्यक्रम करना चाहते हैं। वे एप्लिकेशन के डिज़ाइन को सीमित करते हैं और डेवलपर्स पर कम ध्यान देते हैं जो स्वतंत्र रूप से यह पता लगाते हैं कि यह कैसे काम करना चाहिए।

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

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

फ्रेमवर्क की गुंजाइश क्या है, संक्षिप्त करने, संपीड़ित करने, मॉड्यूलर करने की क्षमता?

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

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

डोजो और जावास्क्रिप्ट चौखटे की जटिलता

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

प्रश्न : क्या दूजो पुस्तकालय यह सब हल कर सकता है? जो लोग अधिक संरचित और गैर-तुच्छ अनुप्रयोग बनाना चाहते हैं, उनके लिए यह पसंदीदा समाधान क्यों नहीं बन गया?

O ।: कुछ साल पहले, जब जावास्क्रिप्ट वातावरण पृष्ठ पर सरल अजाक्स और प्रभावों को जोड़ने से विकसित हुआ, तो Dojo ने वेब पर जटिल अनुप्रयोगों के निर्माण के लिए "टूल" दृष्टिकोण की वकालत की।

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

जावास्क्रिप्ट पुस्तकालयों में "दावा" नहीं होना चाहिए कि प्रारंभिक चरण से डोजो ने उद्यम-स्तर के अनुप्रयोग विकास के पूर्ण चक्र पर अपने प्रयासों को कैसे केंद्रित किया। MVC का अभी एक ही फोकस है, यह एक सेट से "एक उपकरण" है।

Dojo एक प्रमुख टूलबॉक्स क्यों नहीं है? उसका लक्ष्य कभी भी एकमात्र विकल्प नहीं था। लक्ष्य उन औजारों का एक खुला सेट प्रदान करना था जो परियोजनाओं के भीतर और कुछ अन्य परियोजनाओं के साथ पोर्टेबिलिटी के साथ काम कर सकें। दोजो की धीमी होने के कारण आलोचना की गई थी और इसे लेने के बाद भी, धीमे होने के लिए उनकी आलोचना की गई थी। शॉर्टकट से छुटकारा पाने की कोशिश एक मुश्किल काम है। उपकरणों के एक समृद्ध सेट की सुविधाओं का दस्तावेजीकरण करना मुश्किल है। Dojo 1.8 में 175 उप-पैकेज और 1,400 से अधिक मॉड्यूल हैं।

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

प्रश्न : डेवलपर्स को डोजो क्यों चुनना चाहिए और भविष्य की परियोजना के लिए आपके पास क्या विचारों की सूची है? कहा जाता है कि 1.8 के बाद एक और लक्ष्य होगा।

O ।: Dojo 1.8 में, डोजोक्स / mvc पैकेज परिपक्वता की ओर एक और कदम बढ़ाता है। पैकेज पर बहुत समय, प्रयास, परीक्षण और सामुदायिक ध्यान दिया गया था। वह एक एमवीसी मॉडल प्रदान करने में माहिर हैं जो डोजो के बाकी हिस्सों का लाभ उठाता है। डेस्कटॉप और मोबाइल उपकरणों के लिए समृद्ध अनुप्रयोगों के निर्माण के लिए डोजोक्स / ऐप एप्लिकेशन पैकेज के साथ, यह क्लाइंट पक्ष के लिए एक एकीकृत प्रणाली बनाता है।

और यह विशिष्ट Dojo दृष्टिकोण में अनुप्रयोगों के निर्माण के लिए व्यवहार्य तरीकों में से एक है।

1.8 में, न केवल एमवीसी सबमॉड्यूल अधिक परिपक्व हो गया है, यह एक मजबूत ढांचे पर आधारित है। यह न केवल आपके व्यू घटकों को बनाने के लिए एक मार्कअप भाषा देता है, आपके मॉडल को व्यक्त करता है या एक नियंत्रक डिज़ाइन करता है। यह केवल डेटा स्रोत के लिए किसी अन्य मॉड्यूल को जोड़ने से बहुत अधिक है। चूंकि यह Dojo के बाकी हिस्सों से जुड़ा है, इसलिए आप अपनी ज़रूरत के अनुसार कनेक्ट कर सकते हैं।

Dojo 2.0 में, हम एक नए स्तर पर मॉड्यूलरिटी लेने की कोशिश करेंगे, जिससे एक और दूसरे को लेना और भी आसान हो जाए। हम आइसोर्फिज्म की अवधारणा का भी पता लगाएंगे ताकि यह उस उपयोगकर्ता के लिए कोई फर्क न पड़े जहां कोड क्लाइंट या सर्वर पर निष्पादित किया जाता है, और अंततः, यह डेवलपर के लिए पारदर्शी होना चाहिए।

■ TodoMVC संग्रह

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

Backbone.js जेरेमी एशकेन और येहुदा काट्ज़ के लेखक द्वारा की गई टिप्पणियों के बाद, टोडोएमवीसी अब आधिकारिक एप्लिकेशन विनिर्देश, जैसे नेविगेशन (या राज्य प्रबंधन) पर किए गए प्रासंगिक कार्यान्वयन प्रदान करता है। (?)

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

हमारे अनुप्रयोगों में शामिल हैं:

• Backbone.js
• Ember.js
• AngularJS
• Spine.js
• नॉकआउटJS (MVVM)
• डोजो
• YUI
• Batman.js
• समापन
• Agility.js
• Knockback.js

AMD संस्करणों में रुचि रखने वालों के लिए:

• Backbone.js + आवश्यकताएँ (AMD का उपयोग करके)
• Ember.js + आवश्यकताएँ (AMD का उपयोग करके)

हमारे लैब्स में शामिल हैं:

• CanJS
• Maria.js
• cujo.js
• उल्का
• सॉकेटस्ट्रीम + jQuery
• Ext.js
• Sammy.js
• JavaScriptMVC
• Google वेब टूलकिट
• TroopJS
• Stapes.js
• soma.js
• DUEL
• फिदेल
• जैतून
• PlastronJS
• डी जाँ
• rAppid.js
• तोड़ दिया
• o_O
• मज़ा
• AngularJS + आवश्यकताएँ (AMD का उपयोग करके)

रिमार्क । हमने अपने टूडो एप्लिकेशन का एक संस्करण शुद्ध जावास्क्रिप्ट में बनाया , और दूसरा, सबसे पहले, jQuery के दृष्टिकोण का उपयोग करते हुए। जैसा कि आप देख सकते हैं, ये एप्लिकेशन कार्यात्मक रूप से MVC फ्रेमवर्क के साथ लिखे गए के बराबर हैं, लेकिन कार्यों का कोई पृथक्करण नहीं है, और वॉल्यूम बढ़ने पर कोड को पढ़ना और बनाए रखना अधिक कठिन हो जाता है।

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

(यहां आपको सबसे दिलचस्प जगह पर रुकना होगा - पाठ का आकार बढ़ता है - अनुमेय भाषणों को रोकने के लिए। ब्रेक के तुरंत बाद, हमारे समय का सबसे अपेक्षित सवाल पूछा जाएगा: मुझे किस फ्रेमवर्क का उपयोग करना चाहिए? 9 स्वादिष्ट सिंगल-ब्लॉक मैक्सिमम वाक्यांश "मुझे चाहिए ...", के साथ लिपटा। एडी उस्मानी के व्यंजनों में माइंड-ब्लोइंग सॉस "यूज़ ...!"
इसके अलावा, अंतिम भाग में:
■ आपको किस रूपरेखा का उपयोग कब करना चाहिए?
■ डेवलपर्स सबसे लोकप्रिय फ्रेमवर्क के बारे में क्या सोचते हैं? (पेशेवरों और विपक्ष)
■ प्रयोग करने से डरो मत
■ एमवी से परे जाना *
■ निष्कर्ष।

: Rich JavaScript Applications – the Seven Frameworks (Throne of JS, 2012) , Steven Sanderson, 1th Aug 2012. Backbone, Meteor, Ember, AngularJS, Knockout, Spine, Batman, CanJS — «Throne of JS, 2012».

(: 2- .)