हमारा विचार: उल्का बनाम डर्बी

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

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

यह सब कैसे शुरू हुआ

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

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

ब्रायन और मैंने एक साल पहले इस पर चर्चा की। उस समय मैंने Google खोज टीम में एक उत्पाद प्रबंधक के रूप में काम किया था, और वह कई खुले Node.js परियोजनाओं में शामिल थे, जिसमें Mongoose और everyauth शामिल थे । मुझे इस ढांचे को विकसित करने में दिलचस्पी थी, क्योंकि मुझे लगा कि मेरे द्वारा किए गए प्रदर्शन के साथ अनुप्रयोग बनाना सबसे अच्छा है, और ब्रायन ने महसूस किया कि Node.js समुदाय को उन डेवलपर्स के लिए एक आसान-उपयोग की रूपरेखा की आवश्यकता है जो रेल या पीएचपी पसंद करते हैं।

पवित्र कंघी बनानेवाले की रेती: ग्राहक सेवा और ग्राहक कोड

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

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

V8 में जावास्क्रिप्ट प्रदर्शन के पुनर्जन्म और Node.js के साथ जावास्क्रिप्ट सर्वर बनाने की सादगी के कारण, कई डेवलपर्स क्लाइंट और सर्वर पर एक साथ जावास्क्रिप्ट का उपयोग करने के विचार से प्रेरित थे। लेकिन, इस अद्भुत अवसर के बावजूद, केवल कुछ एप्लिकेशन साझा कोड का उपयोग करते हैं। यहां तक ​​कि एक भाषा के साथ, अभी भी कई समस्याएं हैं, जिनमें: देरी और कनेक्शन की स्थिरता में अंतर, सर्वर और ब्राउज़र में URL के साथ काम करने के तरीकों में अंतर, ब्राउज़र में DOM का अस्तित्व और क्लाइंट पर इसकी अनुपस्थिति, और अंत में, फ़ाइल सिस्टम तक सीधी पहुंच केवल सर्वर पर।

तो बात है!

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

जीपीएल बनाम एमआईटी

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

मैं वकील नहीं हूं, इसलिए मैं वह सब कुछ नहीं लेता, जो मैंने अभी कहा है। मैंने भविष्य में क्रिस्टल बॉल या ऐसा कुछ नहीं देखा। (हां, हमारे वकील ने एक बार मुझसे इसका उल्लेख करने के लिए कहा था।)

उल्का बनाम एनपीएम पैकेज सिस्टम

उल्का ने अपना पैकेज सिस्टम और पैकेज वितरण उपकरण बनाया है।

Node.js मॉड्यूल अच्छी तरह से परिभाषित कॉमनजेएस मानक का पालन करते हैं और इसमें एक अंतर्निहित मॉड्यूलर एपीआई है। हालाँकि, शुरू में पैकेज वितरण प्रणाली नहीं थी। शुरुआत में, Node.js में कई पैकेज प्रबंधक थे, लेकिन अधिकांश डेवलपर्स ने अब npm का उपयोग करने पर ध्यान केंद्रित किया है। यह इतना सार्वभौमिक है कि यह Node.js. के साथ वितरण में भी शामिल है

सच कहूं, तो यह मुख्य बात है जो मुझे उल्का के बारे में चिंतित करती है। ऐसा लगता है कि उल्का की कोशिश करने वाले लोगों ने कभी भी Node.js का उपयोग नहीं किया है और उन्हें npm के माध्यम से पैकेज वितरित करने के लाभों के बारे में पता नहीं है। I, और कई अन्य डेवलपर्स, npm.js की महत्वपूर्ण शक्ति को npm में देखते हैं, और इसे असंगत पैकेज सिस्टम द्वारा कमजोर देखकर बहुत दुख होगा।

कई अन्य Node.js परियोजनाओं के साथ, हम npm मॉड्यूल के रूप में डर्बी, रेसर और उनके प्लगइन्स वितरित करते हैं। और हम अपनी परियोजना को छोटे मॉड्यूल में तोड़ना जारी रखेंगे ताकि दूसरों के लिए उनका उपयोग करना आसान हो। आप डर्बी का उपयोग नहीं कर सकते हैं, लेकिन आपको HTML को पार्स करने की आवश्यकता है। हमें अपने टेम्प्लेट सिस्टम के काम करने के लिए एक सरल और तेज़ HTML पार्सर लिखने की आवश्यकता थी, और आप इसे अपने Node.js प्रोजेक्ट्स में उपयोग कर सकते हैं। कनेक्ट परियोजना का एक बड़ा उदाहरण है, जिसके आधार पर मॉड्यूल का एक समृद्ध पारिस्थितिकी तंत्र है और इसे एनपीएम के माध्यम से वितरित किया जाता है, और हम इस पथ का अनुसरण करने की भी उम्मीद करते हैं।

अन्य पुस्तकालयों के साथ संगतता

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

उल्का आमतौर पर सर्वर निर्माण को अपने तरीके से प्रबंधित करता है। यह उल्कापिंड अनुप्रयोगों को उनके सर्वर में असामान्य रूप से सरल बनाने और तैनात करने की प्रक्रिया को आसान बनाता है, लेकिन साथ ही नियमित रूप से Node.js सर्वर पर एक मॉड्यूल के रूप में उल्का के उपयोग को बहुत जटिल करता है।

इसके विपरीत, डर्बी एक नियमित npm मॉड्यूल है जिसे किसी भी Node.js सर्वर में जोड़ा जा सकता है। यदि आप 8900 एनपीएम मॉड्यूल (अब 39 हजार - लगभग प्रति।) में से एक का उपयोग करना चाहते हैं, तो बस उन्हें अपने पैकेज में जोड़ें। फ़ाइल को npm install और npm install ।

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

रेसर (डर्बी में रियल-टाइम इंजन प्रबंधन मॉडल) एक अलग मॉड्यूल है, और इसे डर्बी के स्वतंत्र रूप से इस्तेमाल किया जा सकता है। आप राउटर के किसी भी UI स्तर में घुसपैठ कर सकते हैं और मॉडल को अपडेट करते समय कहे जाने वाले तरीकों को नियंत्रित कर सकते हैं। रेसर लोकप्रिय मॉड्यूल सॉकेट.आईओ पर आधारित है, जिसे आवश्यक होने पर सीधे एक्सेस किया जा सकता है।

डर्बी कर्नेल कई लोकप्रिय पुस्तकालयों का भी उपयोग करता है, विशेष रूप से एक्सप्रेसिंग और ब्राउजर के लिए एक्सप्रेस , जो ब्राउज़र के लिए स्वचालित रूप से सबसे अधिक नोड.जेएस मॉड्यूल पैक करता है।

MongoDB API बनाम रेसर विधि

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

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

संघर्ष का संकल्प

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

डेटा वेयरहाउस इंटरचेंजबिलिटी

हमारे "पथ" और "तरीके" अधिकांश डेटा वेयरहाउस की क्षमताओं का उपयोग करने के लिए पर्याप्त लचीले हैं, एक से दूसरे में स्विच करते हैं और यहां तक ​​कि एक ही समय में उनमें से कई का उपयोग करते हैं। स्रोत कोड को संशोधित करने की आवश्यकता के बिना Riak, Postgres, CouchDb या किसी अन्य सेवा के बीच स्विच करना।

PubSub दक्षता (डेटा में परिवर्तन / डेटा परिवर्तन की सदस्यता लें)

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

एक्सटेंशन एपीआई

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

सर्वर पेज पीढ़ी और सामान्य मार्ग

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

इसका मतलब है कि आपको बहुत तेज़ पेज लोड हो रहा है। यहां तक ​​कि साधारण एप्लिकेशन के लिए जो क्लाइंट पर एक पेज जनरेट करता है, पेज को लोड और रेंडर करने में 1 - 2 सेकंड का समय लगता है। सरल डर्बी अनुप्रयोगों में, 200 एमएस के बाद ऑनलोड घटना चालू हो जाती है। अनुप्रयोग जितना अधिक जटिल हो जाता है, सर्वर पुनर्जनन के कारण गति में अधिक वृद्धि देखी जाती है।

Google, अमेज़ॅन और फेसबुक जैसी कई बड़ी कंपनियां पृष्ठ लोड समय के अनुकूलन के लिए भारी संसाधन समर्पित करती हैं, क्योंकि यह सीधे रूपांतरण और राजस्व को प्रभावित करता है। मैं उस दिन लगभग मर गया जब जीमेल ने एक लोड संकेतक के साथ एक प्रगति बार जोड़ा। ऐसा कभी न करें।

इसके अलावा, सर्वर पर पृष्ठों की पीढ़ी एसईओ के लिए महत्वपूर्ण है, और उन ब्राउज़रों और पाठकों तक पहुंच प्रदान करता है जिनके पास जावास्क्रिप्ट समर्थन की कमी है।

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

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

उल्का में यह सुविधा नहीं है, हालांकि वे हाल ही में अपने टेम्पलेट इंजन को फिर से लिखते हैं और इसे जोड़ सकते हैं ।

मॉडल और दृश्य डेटा को जोड़ना

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

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

डोम घटना संचालकों

यहां अंतर बहुत छोटे हैं - उल्का खाका में सीएसएस चयनकर्ताओं का उपयोग करता है, और डर्बी ईवेंट विशेषताओं को बांधने के लिए HTML विशेषताओं का उपयोग करता है। jQuery और Backbone ने CSS चयनकर्ताओं को लोकप्रिय बनाया है; नॉकआउट और कोणीय HTML विशेषताओं का उपयोग करते हैं।

हम HTML मार्कअप पसंद करते हैं, क्योंकि यह पता लगाना कठिन है कि आवश्यक तत्वों के लिए कौन सी CSS चयनकर्ता जिम्मेदार है, और अक्सर ऐसा होता है कि HTML संरचना बदल जाती है, सीएसएस चयनकर्ताओं को सावधानीपूर्वक नष्ट कर देती है। मार्कअप के साथ, यह कम संभावना है कि फ़ंक्शन नाम गलती से बदल जाएंगे और एक अपवाद फेंक दिया जाएगा कि आवश्यक फ़ंक्शन नहीं मिला।

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

रेशे

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

मुद्दा बहस का मुद्दा है, फिलहाल हम इससे अलग खड़े होना पसंद करते हैं। Npm मॉड्यूल का एक बहुत छोटा प्रतिशत इस शैली में लिखा गया है, और हम कॉलबैक के साथ Node.js में एक अधिक पारंपरिक दृष्टिकोण का पालन करते हैं।

संक्षेप में कहना

आप दोनों रूपरेखाओं के साथ लगभग एक ही परिणाम प्राप्त कर सकते हैं। दोनों विकासशील कार्यक्रमों के लिए शक्तिशाली उपकरण हैं जो परंपरागत वेब रूपरेखा जैसे रेल या पीएचपी का उपयोग करना मुश्किल होगा।

डर्बी संघर्ष का पता लगाने, ऑफ़लाइन ग्राहकों के लिए समर्थन और बेहद तेज पृष्ठ पीढ़ी जैसी प्रौद्योगिकियों पर अधिक ध्यान केंद्रित करती है। हम अन्य मॉड्यूल के साथ संगतता पर भी ध्यान केंद्रित कर रहे हैं जो Node.js पारिस्थितिकी तंत्र में मौजूद हैं और खुले लाइसेंस प्राप्त हैं।

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

अनुवादक से : समीक्षा लिखने के बाद से, उत्पाद संक्षेप में, बड़े पैमाने पर बदल गए हैं:
1. उल्का भी अब एमआईटी के तहत लाइसेंस प्राप्त है
2. एनपीएम-मॉड्यूल का उपयोग करना संभव हो गया, हालांकि सीधे आवेदन में नहीं - पहले उन्हें मेटाटोर-पैकेज से एक आवरण में लपेटने की आवश्यकता होती है
3. सामान्य प्रमाणीकरण, प्रमाणीकरण उल्का में दिखाई दिया
4. सर्वर-साइड पेज जनरेशन के संबंध में, यह सुविधा स्पार्क (एक मध्यवर्ती DOM जेनरेशन मॉड्यूल, Meteor में हैंडलबार के नीचे स्थित है) में एम्बेडेड है, लेकिन अभी तक इसे लागू नहीं किया गया है। मकड़ी के मॉड्यूल को जोड़ने से पृष्ठों का अनुक्रमण संभव है - यह Google और यैंडेक्स दोनों के साथ काम करता है।

अगर कोई बता सकता है कि उल्का या डर्बी में और क्या बदलाव आया है - कृपया टिप्पणी करें।

अनुवाद के दौरान प्रयुक्त PS: DERBY VS METEOR पर विचार