Node.js के बारे में इतना अनोखा क्या है? [बन्द है]


48

हाल ही में Node.js. की बहुत प्रशंसा हुई है मैं एक डेवलपर नहीं हूं जिसे नेटवर्क एप्लिकेशन के लिए बहुत अधिक जोखिम मिला है। नोड्स.जेएस की मेरी नंगी समझ से, इसकी ताकत यह है: हमारे पास एक ही धागा है जो कई कनेक्शनों को संभालता है, एक घटना-आधारित वास्तुकला प्रदान करता है।

हालाँकि, उदाहरण के लिए, जावा में, मैं NIO / AIO (जो मेरी नंगी समझ से गैर-अवरुद्ध API है) का उपयोग करके केवल एक धागा बना सकता हूं, और उस धागे का उपयोग करके कई कनेक्शनों को संभाल सकता हूं, और मैं डेटा को लागू करने के लिए एक घटना-आधारित वास्तुकला प्रदान करता हूं। तर्क संभालना (कुछ कॉलबैक आदि प्रदान करके यह मुश्किल नहीं होना चाहिए)?

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


3
मुझे आश्चर्य है कि यह क्यों अस्वीकृत है ... मुझे लगता है कि यह सवाल एक प्रोग्रामिंग चर्चा अधिक है, इसलिए मैंने स्टैकओवरफ्लो में नहीं डाला। मैंने भी इसी तरह के विषयों को खोजने की कोशिश की, लेकिन मुझे केवल Nodes.js की ताकत के बारे में जानकारी मिली, लेकिन मेरी समस्या यह है कि मैं वास्तव में यह नहीं समझता कि "ताकत" इतनी अनोखी क्यों है (जो मुझे अभी तक नहीं मिली)
एड्रियन शुम

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

6
जावास्क्रिप्ट कॉलबैक के रूप में केवल अलौकिक बनने के लिए प्रवण हैं - और इस तरह के स्पेगेटी जावा में डिबग और रिफैक्टर के लिए जावास्क्रिप्ट आईएमओ की तुलना में कहीं अधिक आसान है।
फंकीब्रॉन

5
@ एड्रियनशम: इसका स्लैशडॉट इफ़ेक्ट, जो कुछ भी समूह की मानसिकता के साथ फिट नहीं बैठता है, उसे डाउनवोट किया जाएगा - जैसे माइक्रोसॉफ्ट ऑन / स्तुति।
gbjbaanb

3
मैं किसी को भी प्रचार का उल्लेख नहीं देखकर आश्चर्यचकित हूं।
deadalnix

जवाबों:


33

जबकि यह अवधारणा वास्तव में कई भाषाओं में लागू की जा सकती है (और जैसा कि dodgy_coder ने उल्लेख किया है, इसे कम से कम रूबी और पायथन में लागू किया गया है), यह आपके राज्य के रूप में बहुत तुच्छ नहीं है।

सच है, जावा में गैर-अवरुद्ध आईओ एपीआई हैं। तो आप गैर-अवरुद्ध तरीके से कच्ची डिस्क / नेटवर्क IO कर सकते हैं। हालाँकि हर API जो किसी न किसी तरह से IO को लपेटता या संभालता है , उसे गैर-अवरुद्ध तरीके से भी लागू किया जाना चाहिए। हर XML पार्सर, हर डेटाबेस ड्राइवर, हर फ़ाइल-प्रारूप कनवर्टर को गैर-अवरुद्ध IO का समर्थन करने के लिए लिखा जाना चाहिए। क्योंकि अगर इस पैटर्न में एक भी लाइब्रेरी ब्लॉक हो रही है, तो यह आपके सर्वर परफॉर्मेंस को स्टोन-एज वैल्यू में ले आता है।

Node.js के पास वह लाइब्रेरी इन्फ्रास्ट्रक्चर है, क्योंकि इसे हमेशा इस तरह से डिज़ाइन किया गया था: लोकप्रिय होने के लिए प्रयासरत प्रत्येक लाइब्रेरी को एक एसिंक्रोनस API प्रदान करना होगा या इसका उपयोग नहीं किया जाएगा।


18
हां। दूसरे शब्दों में: Node.js की सबसे महत्वपूर्ण ताकत ECMAScript की सबसे महत्वपूर्ण कमजोरी है: अविश्वसनीय रूप से भद्दा ECMAScript शब्द लाइब्रेरी। चूंकि Node.js डेवलपर्स को वैसे भी हर एक पहिए को फिर से मजबूत करना था, इसलिए उन्हें इसे सही तरीके से फिर से बनाने का मौका मिला।
जोर्ग डब्ल्यू मित्तग

4
खैर, जहां तक ​​मुझे पता है कि ECMAScript को हमेशा एक एम्बेडेड भाषा के रूप में डिज़ाइन किया गया था, इसलिए किसी भी प्रकार के OS- स्तर API की आवश्यकता नहीं थी (यहां तक ​​कि नेटवर्क IO ज्यादातर सार था)। यह कमी वास्तव में Node.js. के लिए एक फायदा था
जोकिम सउर

"हर पुस्तकालय जो लोकप्रिय बनने का प्रयास करता है, उसे एक अतुल्यकालिक एपीआई प्रदान करना होगा या इसका उपयोग नहीं किया जाएगा" मुझे लगता है कि ठीक वही है जिसकी मुझे तलाश है। क्या इस बात पर ध्यान देने के लिए कोई संसाधन है कि अतुल्यकालिक आपी को, उदाहरण के लिए, XML पार्सिंग और DB एक्सेस, Node.js में कैसे प्रदान किया जाता है?
एड्रियन शम

1
सामान्य रूप से @ AdrianShum, इवेंट संचालित प्रोग्रामिंग उदाहरणों के लिए देखें। कई भाषाओं में विशिष्ट कार्यान्वयन पाए जा सकते हैं। Node.js मॉड्यूल के अलावा, आप अजगर, में मुड़ उदाहरणों पर गौर कर सकता है twistedmatrix.com/trac/wiki , पर्ल, में पीओई उदाहरण poe.perl.org , और रूबी EventMachine, है github.com/eventmachine/eventmachine
mghicks

19

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

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


5
बहुत कम तकनीकों में वास्तव में अद्वितीय विशेषताएं हैं, विशिष्टता उनके सभी विशेषताओं के विशेष संयोजन से आती है
jk।

1
सहमत, पुस्तकालयों की यहाँ एक सूची है जो सभी प्रमुख भाषाओं में इसका समर्थन करती है ... रिएक्टर पैटर्न विकिपीडिया पर
dodgy_coder

10

मेरे द्वारा दिए गए तीन मुख्य कारण हैं:

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

  2. क्लाइंट और सर्वर के लिए सिंगल कोड आधार। इसके कई फायदे हैं: सर्वर से क्लाइंट के लिए व्यावसायिक तर्क को स्थानांतरित करने में सक्षम होने से डेटासेंटर की लागत को अनुकूलित करने में मदद करें; व्यापार तर्क / डेटा सत्यापन का पुन: उपयोग करने में मदद; डेवलपर कौशल की जटिलता को कम करें जो उत्पाद का समर्थन करने के लिए मौजूद होना चाहिए (बनाम पायथन और जावास्क्रिप्ट)।

  3. प्रवेश के लिए कम बाधा। कई मायनों में जवास्किर बेसिक, पास्कल और पर्ल ऑफ यस्टर-ईयर की तरह है। कोड लिखना शुरू करना सुपर आसान है और इसे प्राप्त करने के लिए बहुत सारे डोमेन ज्ञान की आवश्यकता नहीं होती है। यह अधिक jr डेवलपर्स में लाने में सक्षम होने और किसी प्रोजेक्ट पर रैंप पर आने से आपकी विकास लागत को कम करने में भी मदद करता है। [निश्चित रूप से आपको विचारधाराओं से आगे निकलने की जरूरत है जो मानते हैं कि प्रोग्रामिंग भाषाओं को कम कामकाजी डेवलपर्स को मात देने के लिए मुश्किल होना चाहिए]


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

मैं @ErikReppen से सहमत हूं; पूरी तरह से जूनियर देवों (भाषा की परवाह किए बिना) की एक आर्किटेक्चर टीम पूरी तरह से बढ़ई की तरह डिजाइन और घर बनाने की तरह है जो कुर्सियां, टेबल और डॉग हाउस बनाने में अच्छे हैं।
वाइल्डकार्ड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.